# The Machine Payments Protocol (MPP), explained

> The Machine Payments Protocol (MPP) is an open standard, co-authored by Stripe and Tempo, that lets AI agents and software pay for services inline with an HTTP request. Its sessions mechanism collapses any number of micropayments into exactly two on-chain transactions — an open and a settle — making high-frequency machine payments economically viable.

5 min read · Updated 2026-06-09 · Topic: use-cases

Canonical: https://tempo.dataos.so/articles/machine-payments-protocol-mpp

The Machine Payments Protocol (**MPP**) is an open standard for **machine-to-machine payments** — a specification that lets any software client pay for any service inline with an HTTP request, without accounts, API keys, or billing setup. Co-authored by **Stripe and Tempo**, MPP launched with the Tempo mainnet on **March 18, 2026**. Its sessions mechanism is the answer to a problem that simpler payment-over-HTTP designs leave unsolved: what happens when a machine needs to make thousands of small payments per hour?

## The core idea: payment as authentication

Every API that charges for access currently requires some form of prior relationship: sign up, enter a credit card, receive an API key, and embed that key in every request. MPP replaces that with a **payment-as-credential** model borrowed from the HTTP specification itself.

When a client requests a resource from an MPP-enabled server, the server can respond with `402 Payment Required` and a payment challenge: here is the price, here is the accepted stablecoin. The client pays — by signing a voucher or submitting a stablecoin transaction — and resends the request with payment credentials. The server verifies and delivers. No account. No prior relationship. No human in the loop.

This is how **OAuth** works for identity — you prove who you are by presenting a credential the server can verify — but applied to payments. MPP is, in this sense, OAuth for payments: a cryptographic proof that the client has already paid, attached inline to the request.

## MPP Sessions: collapsing micropayments to two transactions

The straightforward version of payment-over-HTTP has a cost problem. If each API call triggers an on-chain transaction, a pipeline making 10,000 calls at $0.001 each also generates 10,000 blockchain transactions. On any chain with non-zero per-transaction fees, that overhead can exceed the value being transacted.

MPP Sessions solve this with a voucher architecture.

### The two-transaction model

| Transaction | What it does |
|---|---|
| **Open** | Client deposits funds into an on-chain escrow contract on Tempo, opening the session |
| **Settle (close)** | Server submits the final voucher on-chain; unused funds return automatically to the client |

Those are the only two on-chain transactions, regardless of how many service calls the agent makes in between.

### Vouchers: the off-chain layer

Between open and settle, every payment is an **off-chain signed message** called a voucher:

1. For each unit of service consumed, the client signs a voucher with a **cumulative amount** — the running total of everything spent so far in the session.
2. Each new voucher supersedes the previous one (the amount only increases).
3. The server verifies the cryptographic signature in microseconds. No blockchain call required.
4. The server holds the most recent voucher as its claim on the escrowed funds.

When the session ends — when the agent's task is complete, a time limit expires, or the client signals closure — the server submits its best voucher on-chain. The escrow contract pays out the cumulative amount, and any remainder returns to the client's wallet.

The Tempo blog, announcing MPP Sessions in April 2026, states this model allows the underlying payment rails to "scale to **1 million TPS and beyond**." That figure describes the off-chain voucher layer, not the base chain's block throughput — the point being that off-chain voucher signing has no practical throughput ceiling, while the two mandatory on-chain transactions anchor the session to a verifiable settlement.

## Why Tempo is the native chain for MPP

MPP's sessions model has specific requirements of its settlement chain:

- **Fast finality:** The open and settle transactions need to confirm quickly — if opening a session takes minutes, the protocol is unusable. Tempo's **Simplex BFT** consensus delivers **deterministic sub-second finality** (~500ms block time). Once a block confirms on Tempo, it cannot be re-organised.
- **Predictable low cost:** If the two required on-chain transactions cost dollars, sessions only make sense for large amounts. Tempo targets fees **under $0.001**, making the open/settle pair negligible even for small sessions.
- **No gas token:** Tempo has no native token. Gas is paid in the **stablecoin itself** (TIP-20 standard). An agent holding only USDC can open a session, make payments, and settle — without acquiring a separate volatile asset just to use the network.
- **Payment Lanes:** Tempo reserves protocol-level blockspace specifically for TIP-20 transfers, preventing session operations from being crowded out during congestion.
- **Channel escrow precompile:** The escrow mechanism for MPP Sessions is built directly into Tempo's protocol layer (added in the T4 network upgrade), not a third-party smart contract.

## The Payments Directory

MPP launched with a **Payments Directory** at **mpp.dev** that listed over 100 services at mainnet launch, spanning categories including:

- AI model providers
- Developer infrastructure
- Compute platforms
- Data services

Named members in the directory include Alchemy and Dune Analytics.

## SDK support

Three SDK implementations are published as of mid-2026:

| SDK | Repository | Language |
|---|---|---|
| **mpp-rs** | github.com/tempoxyz/mpp-rs | Rust |
| **pympp** | — | Python |
| **wallet** | github.com/tempoxyz/wallet | Rust (CLI + HTTP client) |

## Payment methods

MPP accepts:
- **TIP-20 stablecoins on Tempo** (primary — USDC, USDT, and other TIP-20 tokens)
- **Cards via Stripe**
- **Bitcoin via Lightning Network**

The Stripe integration means an MPP-enabled API can accept a conventional card payment from a human client via the same protocol interface an AI agent uses with stablecoins.

## Adoption

**RedotPay**, a crypto payments platform with 7.5 million users across 100+ countries and over $10 billion in annualized volume, integrated MPP in May 2026 — the first major consumer-facing integration. **Stripe**, as co-author, uses MPP in its stablecoin settlement stack. Both integrations were confirmed at or after Tempo's mainnet launch.

## The bottom line

MPP is the answer to a specific engineering problem: how do you make per-use micropayments economically rational when the service might be called thousands of times per hour? The sessions model — one open, unlimited off-chain vouchers, one settle — makes the on-chain cost a fixed cost per task rather than a variable cost per call. For a head-to-head comparison with Coinbase's x402, see [x402 vs MPP](/articles/x402-vs-mpp-machine-payments). For the broader context of why machine payments are emerging now, see [What are agentic payments](/articles/what-are-agentic-payments).

## FAQ

**What is MPP in simple terms?**

MPP is a payment protocol for machines. It lets an AI agent or any software client pay for an API or service inline with its HTTP request — no account, no signup, no human approval needed. The payment is a stablecoin transfer on the Tempo blockchain.

**What are MPP Sessions?**

MPP Sessions collapse many individual micropayments into two on-chain transactions. The client opens a session by depositing funds into an escrow on Tempo. Each intermediate payment is an off-chain signed voucher. When the session ends, the server submits the final voucher on-chain and unused funds return to the client.

**Who co-authored MPP?**

MPP is co-authored by Stripe and Tempo. The spec is open at github.com/tempoxyz/mpp-specs.

**What chains does MPP run on?**

MPP is native to the Tempo blockchain for stablecoin settlement. It also supports cards via Stripe and Bitcoin via the Lightning Network.

**How is MPP different from a subscription or API key?**

A subscription bills a flat fee regardless of usage and requires an account. An API key requires signup and often a credit card on file. MPP charges only for what the agent actually consumes, settles in real time, and requires no prior relationship between client and server.

## Sources

1. [Tempo — MPP Sessions](https://tempo.xyz/blog/mpp-sessions)
2. [Tempo — Mainnet launch](https://tempo.xyz/blog/mainnet)
3. [Tempo docs — Machine payments](https://docs.tempo.xyz/learn/tempo/machine-payments)
4. [MPP spec repository](https://github.com/tempoxyz/mpp-specs)
5. [Tempo — RedotPay integrates MPP](https://tempo.xyz/blog/redotpay-integrates-mpp-to-bring-agentic-payments-to-its-users)

---
Neutral, sourced explainer from tempowiki. Index: https://tempo.dataos.so/llms.txt