x402 vs MPP: How Machine Payment Protocols Work and Which to Choose

HTTP status code 402 - "Payment Required" - has existed since 1996. The HTTP/1.1 specification reserved it for future use, with no implementation details. For 30 years, it sat unused while every attempt at web-native micropayments failed. DigiCash, Flooz, Beenz, and dozens of others collapsed because transaction fees exceeded the payments themselves, no stablecoin existed to eliminate currency volatility, and no software agent could sign a payment autonomously.

Three things changed. Stablecoins now settle over $30 billion daily. Layer 2 chains like Base process transactions for fractions of a cent. AI agents can hold keys and authorize payments without human intervention.

Two protocols have now given HTTP 402 real specifications: x402 (Coinbase, May 2025) and MPP (Stripe + Tempo, March 2026). For developers building on blockchain infrastructure, these protocols determine how your services get paid and how your agents pay for the services they consume. This comparison breaks down the architecture, trade-offs, and infrastructure requirements of each.

How x402 Works

x402 was created by Coinbase and launched in May 2025. By September 2025, Cloudflare joined as co-governor through the x402 Foundation, which now includes Google, Visa, AWS, Circle, Anthropic, and Vercel as members. The protocol adds a single payment step to the standard HTTP request-response cycle.

The flow works like this: a client requests a paid resource, and the server returns HTTP 402 with a PAYMENT-REQUIRED header specifying the price, accepted tokens, and network. The client signs a payment using EIP-3009 (for USDC and EURC) or Permit2 (for other ERC-20 tokens) and retries the request with a PAYMENT-SIGNATURE header. A facilitator verifies and settles the payment on-chain, then the server returns the resource with HTTP 200.

Three roles define the architecture: the client (human or AI agent), the resource server (the API being paid for), and the facilitator (handles on-chain settlement and pays gas). The facilitator makes x402 gasless for the client. You sign a payment authorization, not a transaction, and the facilitator submits the on-chain transaction and absorbs the gas cost.

x402 supports Base (119M+ transactions to date), Solana (35M+ transactions), Polygon, Ethereum, Arbitrum, Optimism, and Avalanche. It only accepts stablecoins: USDC and EURC natively via EIP-3009, with other ERC-20 tokens supported through Permit2.

The V2 specification, released in December 2025, standardized CAIP-2 network identifiers and introduced multi-facilitator support, allowing resource servers to accept payments through multiple settlement providers.

The protocol charges zero protocol fees. You pay only network gas fees. At current scale, x402 processes roughly $600M in annualized volume across 94,000+ buyers and 22,000+ sellers. The specification is MIT licensed with 5,800+ GitHub stars.

How MPP Works

MPP (Machine Payments Protocol) was co-authored by Tempo Labs and Stripe, launching on March 18, 2026 alongside Tempo's mainnet. Where x402 introduced custom HTTP headers, MPP uses the standard HTTP authentication framework defined in RFC 9110. Servers challenge with WWW-Authenticate: Payment and clients respond with Authorization: Payment.

An IETF Internet-Draft (draft-ryan-httpauth-payment-01) has been submitted as an individual contribution. It has not been adopted by a working group yet, but the submission shows intent toward formal standardization.

MPP's defining feature is its two billing models. The charge intent handles one-time payments per request, functionally equivalent to x402's payment flow. The session intent is where MPP diverges: a client deposits funds into escrow on Tempo, then signs off-chain vouchers at machine speed for each subsequent request. The server accumulates vouchers and batch-settles periodically on-chain.

This enables payments below $0.0001 per request with sub-100ms latency per payment step. QuickNode's early MPP implementation prices this concretely: charge intent costs $0.001/request while session intent costs $0.00001/request - a 100x reduction for high-frequency workloads.

The protocol is payment-method agnostic. A single 402 response can advertise multiple accepted payment methods: Tempo stablecoins, Stripe credit cards, Lightning Network (via Lightspark), or custom payment rails. A single API endpoint accepts both crypto and fiat payments without separate integration paths.

For charge intents, no facilitator is required - the client pays directly. MPP is also backward compatible with x402 charge flows, so existing x402 integrations can adopt MPP incrementally.

SDKs ship in TypeScript (mppx), Python (pympp), and Rust (mpp-rs). At launch, 100+ services accept MPP payments, including Alchemy, Dune, OpenAI, Anthropic, and Google Gemini.

Tempo's L1 provides the settlement layer: 0.6-second deterministic finality, sub-$0.001 fees, and 16,000 RPS capacity running Simplex BFT consensus via Commonware. The project is led by Matt Huang (Paradigm co-founder) with $500M raised at a $5B valuation. The MPP spec is CC0 (public domain), and tooling is Apache 2.0/MIT licensed.

Side-by-Side Comparison

Design Philosophy: Minimization vs. Maximization

x402 is a protocol minimization exercise. It adds exactly one capability to HTTP: embed a signed payment in a request. No accounts, no sessions, no fiat rails, no state. Every request is independent, and a single payment settles a single API call.

The specification fits in a few pages because it intentionally excludes everything not essential to "pay for this HTTP resource."

This constraint is also its strength. x402 is simple to implement, simple to audit, and simple to reason about. A developer can integrate x402 into an Express server in under 50 lines of code. There are no session management edge cases, no escrow states to handle, no fiat webhook integrations to debug.

MPP takes the opposite approach: protocol maximization. It builds a complete payment abstraction within the HTTP authentication framework. Multiple intent types cover different billing patterns, session-based vouchers handle streaming payments, and pluggable payment methods accept crypto, fiat, and Lightning through a single interface. The IETF submission aims for formal standardization.

The trade-off is complexity. MPP session management requires tracking escrow deposits, voucher accumulation, and batch settlement timing. Multi-method support means handling Stripe webhooks alongside on-chain confirmation.

For services that need these capabilities - a data streaming API processing 10,000 requests per second, or an enterprise API that must accept both credit cards and USDC - there is no simpler alternative.

Infrastructure Implications

Both x402 and MPP depend on RPC endpoints for settlement verification. A failed RPC call during payment settlement means a failed payment, which means a failed API response to your user or agent. The infrastructure requirements differ by protocol.

x402 and Multi-Chain RPC Dependencies

x402 settles primarily on Base and Solana, which together account for 154M+ total transactions. Solana now commands roughly 49% of x402 market share due to its $0.00025 average transaction fee and 400ms finality. Running x402 in production means your Base RPC must be reliable. When a facilitator submits a payment on-chain, it verifies settlement before the resource server returns data. Latency on your Base endpoint directly affects the 1-2 second payment round-trip the end user experiences.

x402 supports 7 chains, and each chain you accept payment on adds another RPC dependency. If you accept USDC on Base, Polygon, and Arbitrum, you need reliable endpoints for all three. A provider outage on any single chain breaks your payment flow for every client paying on that chain.

Dwellir supports Base, Polygon, Arbitrum, Ethereum, Optimism, and Avalanche with 1:1 pricing (one request equals one request). x402 settlement verification calls include methods like eth_getTransactionReceipt and eth_call that compute-unit-based providers bill at elevated rates per call.

MPP and Tempo RPC Requirements

MPP settles crypto payments on Tempo, which launched on March 18, 2026. Tempo is a new chain with limited provider coverage compared to established networks like Base or Ethereum. Fewer providers means less redundancy, and fewer providers have had time to optimize their Tempo infrastructure.

Tempo's 0.6-second deterministic finality speeds up settlement, but blocks arrive every 500-600ms. Your RPC endpoint needs to keep pace with that block production rate, especially if you monitor payment events via WebSocket subscriptions. For a detailed breakdown of Tempo provider options, see Top 8 Tempo RPC Providers 2026.

Dwellir's Tempo RPC endpoints include WebSocket support and archive node access on all paid plans - both relevant for MPP session monitoring and payment reconciliation.

Session Model vs. Per-Request Settlement

x402 settles every payment on-chain, generating one transaction per API call. For an API handling 1,000 paid requests per minute, that is 1,000 on-chain transactions per minute and 1,000 settlement verification RPC calls.

MPP session intents flip this model. The client deposits once into escrow, then signs off-chain vouchers for each request. The server batch-settles periodically - every 100 requests or every 60 seconds, depending on configuration. This reduces on-chain transactions (and RPC calls for settlement verification) by 10-100x, but introduces persistent state management for sessions, voucher tracking, and batch settlement triggers.

Real-World Adoption Patterns

For RPC providers, this space is already moving. QuickNode offers x402-based pay-per-call access at 1M credits for $10 USDC, eliminating API key management entirely. CoinGecko sells x402 data API access at $0.01 per request. Both show machine payment protocols replacing traditional API key and subscription billing for blockchain data services.

MPP's MCP transport support extends this further. AI agents using Model Context Protocol tool calls can pay for services inline - an agent calling an MCP-compatible blockchain data tool pays per query without any pre-configured API key or subscription. For infrastructure providers building MCP-compatible endpoints, MPP support opens a new access model.

The Broader Protocol Landscape

x402 and MPP are two of four agentic payment protocols that emerged between May 2025 and March 2026. Each addresses a different layer of the machine-to-machine commerce stack.

x402 (Coinbase + Cloudflare) and MPP (Stripe + Tempo) handle API-level micropayments - paying for individual HTTP resources or streaming data. ACP (Agent Commerce Protocol, OpenAI + Stripe) handles structured e-commerce checkout flows where an agent browses products, adds items to a cart, and completes a purchase with human approval.

AP2 (Agent Payment and Procurement Protocol, Google + 60 partners) provides authorization and verifiable credentials - proving an agent is authorized to spend up to a given budget on behalf of a specific organization.

These protocols are complementary layers, not direct competitors. A production agent might use AP2 for identity and authorization, ACP for purchasing cloud compute or physical goods, and x402 or MPP for paying per-API-call for blockchain data.

For a deeper look at how these protocols fit together, see ERC-8183 Agentic Commerce Explained and What AI Agents Need from Blockchain Infrastructure.

Which Should You Choose?

The right protocol depends on your payment patterns, your chain preferences, and whether you need fiat support.

Choose x402 if:

• You need permissionless, zero-account API access with no registration flow
• Your payments are crypto-native (USDC or EURC on EVM chains or Solana)
• You want the simplest possible integration - one signed payment per request
• You are building on Base, Solana, or Polygon where x402 has the deepest adoption
• You value production-proven scale: 154M+ settled transactions and $600M annualized volume

Choose MPP if:

• You need to accept both fiat (Stripe credit cards) and crypto payments through one protocol
• High-frequency billing makes per-request on-chain settlement impractical - the session model batches hundreds of micropayments into a single settlement
• You are building on or integrating with Tempo's payments infrastructure
• You need MCP transport for AI agent tool payments
• IETF standardization matters to your compliance or procurement requirements

Use both:

MPP is backward compatible with x402 charge flows. An API can accept x402 payments today and add MPP session support later without breaking existing integrations. You can also use different protocols for different endpoints based on access patterns - x402 for simple per-call endpoints, MPP sessions for streaming data feeds.

Getting Your Infrastructure Ready

Both protocols turn your RPC provider into a payment dependency. When an x402 facilitator verifies settlement on Base, or an MPP session settles a batch on Tempo, a failed or slow RPC response does not delay data - it fails the payment. Your users or agents receive an error instead of the resource they paid for.

If you are implementing x402, you need reliable RPC on every chain you accept payment on. Dwellir's Base endpoints handle the settlement verification calls that make up the majority of x402 volume. If you are implementing MPP, Dwellir's Tempo endpoints provide the WebSocket connections and archive access that session monitoring requires.

For a deeper look at x402 specifically, see What Is x402 Protocol on the Dwellir blog.

Whether you are building x402 payment verification on Base or MPP session settlement on Tempo, your RPC reliability directly determines your payment success rate. Contact the Dwellir team to discuss your infrastructure setup.