When a server needs to tell a client "pay first, then I'll respond," the HTTP specification has a status code for that: 402 Payment Required. Defined in 1991 and left unused for three decades, it is now the foundation for two competing machine payment protocols — x402 from Coinbase and MPP from Stripe and Tempo. Both aim to become the default way that AI agents, APIs, and automated software pay for digital services. They share a philosophy but diverge sharply in architecture.
At a glance
| Dimension | x402 | MPP |
|---|---|---|
| Launched | May 2025 (open-sourced) | March 18, 2026 (Tempo mainnet) |
| Co-authors | Coinbase; x402 Foundation (Linux Foundation, Apr 2026) | Stripe + Tempo |
| Settlement model | Per-request on-chain transaction | Sessions: 2 on-chain txns per session, unlimited off-chain vouchers between |
| Primary chains | Base, Solana; also Polygon, Arbitrum, World | Tempo (native); cards via Stripe; BTC via Lightning |
| Protocol fees | Zero | Zero |
| Token standard | ERC-20 (Permit2 / EIP-3009) | TIP-20 stablecoins on Tempo |
| SDK languages | TypeScript, Go, Python | Rust, Python, CLI/HTTP |
| Governance | Linux Foundation (neutral) | Open spec at github.com/tempoxyz/mpp-specs |
| Payments directory | Coinbase Developer Platform | mpp.dev (100+ services at launch) |
| Adoption (Jun 2026) | 119M+ transactions on Base, 35M on Solana; ~$600M annualized volume | RedotPay (7.5M users, $10B+ annualized volume); Stripe settlement stack |
How x402 works
x402 revives HTTP 402 as a per-request payment gate. The flow is:
- Client requests a resource.
- Server responds
402 Payment Requiredwith aPAYMENT-REQUIREDheader encoding price, accepted token, and chain (CAIP-2 identifier). - Client constructs a signed payment via the
PAYMENT-SIGNATUREheader and resends the request. - A facilitator service — operated by Coinbase or self-hosted — verifies the payment on-chain and delivers the resource.
Every request that requires payment triggers a new on-chain transaction. The facilitator eliminates the need for the server to run its own blockchain node. Coinbase offers a free facilitator tier for up to 1,000 transactions per month.
Strengths of x402: Stateless simplicity. Each request is self-contained. A service can adopt x402 without maintaining any session state, and clients need no prior relationship with the server. The broad chain support (Base, Solana, and others) means services can pick their preferred settlement network.
Limitations of x402: At high frequency, on-chain costs accumulate. A data pipeline making 10,000 API calls at $0.001 each still needs 10,000 on-chain transactions (or a batching workaround). On Base, transaction costs are low but non-zero; at very high call rates, the cumulative fee load matters.
How MPP works
MPP shares the same HTTP 402 handshake but layers a Sessions mechanism on top to address the high-frequency cost problem.
An MPP Session has three phases:
- Open: The client submits one on-chain transaction to deposit funds into a channel escrow contract on Tempo.
- Transact (off-chain): For each service call, the client signs an off-chain voucher — a cryptographically verified message incrementing the cumulative amount owed. The server verifies the signature in microseconds. No blockchain is touched.
- Settle: When the session ends, the server submits the final voucher on-chain. Unused funds return to the client automatically.
The result: exactly 2 on-chain transactions per session, regardless of how many intermediate calls occur. Tempo's blog states the sessions model allows the underlying rails to scale to "1 million TPS and beyond." The claim refers to the off-chain voucher layer, not the base chain throughput.
Strengths of MPP: Eliminates per-call on-chain cost for high-frequency workloads. The voucher mechanism is cryptographically sound — each voucher supersedes the previous one, so the server always holds a valid claim. Sub-second finality on Tempo means open and settle confirm instantly.
Limitations of MPP: Requires Tempo infrastructure for settlement. Sessions add state that both client and server must manage. Lower-frequency use cases (one or two API calls) gain little over a simple per-request model.
Which to choose
The protocols serve different frequency profiles more than they compete head-to-head:
- Low-frequency, multi-chain access: x402. A service charging for occasional API access, wanting to accept payment on Base or Solana, gets x402's simplicity without session overhead.
- High-frequency micropayments on Tempo: MPP Sessions. An AI agent making thousands of calls per hour to model providers, data APIs, or compute services benefits directly from collapsing those charges into two on-chain transactions.
- Card and Lightning support: MPP, via Stripe and Lightning Network integrations that x402 does not natively offer.
- Broadest chain support: x402, which runs on multiple EVM chains and Solana.
The two protocols are not mutually exclusive. A service could expose both endpoints, letting the client negotiate. The x402 spec's move to the Linux Foundation and MPP's open spec repository both signal that the underlying HTTP 402 handshake is converging toward a shared baseline, even as the settlement layers differ.
The bottom line
x402 and MPP agree on the fundamental proposition: machine payments should be HTTP-native, stablecoin-denominated, and require no accounts or subscriptions. They diverge on how to handle the volume and cost profile of real AI agent workloads. x402's simplicity and broad chain support make it the lower-friction starting point; MPP's sessions model is the answer for workloads where per-call on-chain cost would dominate. For a deeper look at MPP's architecture, see The Machine Payments Protocol, explained. For the broader context of why agentic payments exist, see What are agentic payments.