x402 and MPP — The Full Picture of Machine-to-Machine Payment Rails

What Are x402 and MPP?

x402 is an open payment protocol developed by Coinbase and now governed under the Linux Foundation. It leverages the HTTP "402 Payment Required" status code to enable AI agents to make instant stablecoin (USDC) payments when accessing web resources. No account registration or API key is needed — the proof of payment itself serves as the access credential.

MPP (Machine Payments Protocol) is a session-based payment protocol co-developed by Stripe and Tempo Labs. It is designed for high-frequency scenarios where AI agents make thousands of API calls per second, efficiently processing micropayments through off-chain streaming settlement.

Both protocols provide infrastructure for AI agents to autonomously pay for services, but they differ fundamentally in design philosophy and target use cases. Let's examine these differences in detail.

Two Approaches to Machine-to-Machine Payment Rails

An AI agent executing thousands of API calls per hour, paying $0.01 for each. Two protocols are rapidly taking shape as the infrastructure to make this "machine-to-machine payment" reality work. x402, incubated by Coinbase and transferred to the Linux Foundation, and MPP (Machine Payments Protocol), co-developed by Stripe and Tempo Labs.

Both use the HTTP 402 Payment Required status code as a trigger, but their design philosophies diverge fundamentally from that point. x402 pursues stateless per-request settlement, while MPP targets session-based streaming payments. This difference is not merely an implementation detail; it directly maps to which domain of the "machine economy" each protocol serves.

The payment infrastructure for agentic commerce has fundamentally different requirements from traditional card payments. Sub-cent micropayments, millisecond-level latency, and autonomous settlement without human intervention. x402 and MPP each address these requirements from different angles.

x402 — Weaving Payments into HTTP

A 30-Year-Old Status Code Comes to Life

The HTTP specification reserved "402 Payment Required" in 1997. With the note "reserved for future use," it lay dormant for nearly three decades until Coinbase's engineering team activated it in May 2025.

The x402 payment flow completes in four steps. When an agent sends an HTTP request to a paid resource, the server returns an HTTP 402 response with payment terms (price, token, chain, recipient wallet). The agent's wallet signs a USDC transaction, resubmits the request with proof of payment in the PAYMENT-SIGNATURE header. The server verifies settlement through a facilitator and delivers the resource.

The core of this design is that proof of payment itself becomes the access credential. No account registration, no API key required. The moment payment completes, access rights emerge. As WorkOS's comparative analysis puts it, "the payment receipt is the credential."

What Changed in V2

x402 V2, released in December 2025, addressed V1's biggest weakness. In V1, every API call required a separate on-chain transaction, making it impractical for high-frequency workloads.

V2 brought three critical improvements. First, wallet-based sessions. Once authenticated, clients can skip the full payment handshake within a session, reducing both latency and on-chain costs. Second, a plugin-driven SDK redesign. The modular architecture allows registering chains, assets, and payment schemes without modifying internal code, making it easy to extend to Base, Solana, Polygon, and legacy rails like ACH, SEPA, and card networks. Third, multi-facilitator support. The SDK automatically selects the optimal facilitator from multiple options, eliminating single points of failure.

As a result, x402 has processed over 100 million payments since its May 2025 launch.

MPP — "Streaming" Payments Through Sessions

The Reality of Thousands of API Calls per Second

Where x402 is optimized for per-request payments, MPP envisions a different landscape. AI agents polling data feeds every second, automations spinning up headless browsers continuously, streaming workloads receiving LLM inference results incrementally. In these high-frequency scenarios, writing to the blockchain for each call is untenable in both cost and speed.

Launched on March 18, 2026 by Stripe and Tempo Labs, MPP addresses this challenge with the concept of sessions. Agents pre-deposit a spending limit into escrow and continuously stream cryptographically signed vouchers (off-chain payment receipts) within the session. The server accumulates vouchers and settles them on-chain in batch at session close.

"

We aimed for the most elegant, minimal protocol that anyone can extend without permission.

Source: Matt Huang (Paradigm co-founder)

The Role of the Tempo Chain

The settlement layer powering MPP's streaming payments is the purpose-built L1 blockchain from Tempo Labs.

What fundamentally distinguishes Tempo from conventional blockchains is that it has no native gas token. Fees are paid in stablecoins. This eliminates the need for agents to hold and manage volatile tokens like ETH or SOL, ensuring predictability as a payment layer.

Tempo also implements transaction-level account abstraction. Human users grant agents cryptographically bound delegations (specifying the token, cumulative cap, and expiration), and agents autonomously spend within those bounds. Processing tens of thousands of transactions per second with sub-second finality, it functions as the backend for streaming payments.

Bridging to Fiat

Another distinguishing feature of MPP is its protocol-level support for hybrid stablecoin-fiat payments. Servers can present multiple payment options simultaneously in the HTTP 402 response, and agents choose from stablecoins on Tempo, card payments via Stripe SPT, Lightning Network, and more.

This design allows MPP to settle in fiat for merchants that do not accept stablecoins, while offering on-chain settlement for crypto-native services. As Crossmint's comparative analysis notes, "MPP delegates payment rail selection to the agent," minimizing the integration burden on merchants.

The Technical Core: Stateless vs. Session-Based

How exactly do x402 and MPP differ technically? The most fundamental distinction lies in their state management model.

x402 is stateless. Each request contains an independent payment, with no relation to preceding or subsequent requests. Faithful to RESTful architectural principles, the server retains no client state. This design delivers simplicity and permissionlessness. For servers, adding a single middleware line enables payment acceptance. For agents, a wallet is all that is needed to access any resource.

MPP is sessional. A persistent payment channel opens between agent and server, with micropayments streaming through that channel. This design delivers efficiency and flexibility. According to QuickNode's technical analysis, MPP distinguishes between two billing intents at the protocol level: charge (per-request) and session (metered), allowing optimal payment patterns per use case.

What emerges from this comparison is that both protocols are solving different parts of the same problem. x402 optimizes for long-tail payment access, while MPP optimizes for high-frequency payment efficiency.

x402 Foundation — The Shift to Open Governance

On April 2, 2026, the Linux Foundation announced the establishment of the x402 Foundation. The organization is designed to develop Coinbase-incubated x402 as a vendor-neutral open standard.

The lineup of participants is telling. Cloudflare and Stripe are co-founding members, joined by AWS, Google, Microsoft, Visa, Mastercard, American Express, Shopify, Adyen, Circle, Solana Foundation, and 22 organizations in total.

The key point here is that Stripe participates in both. Stripe is the co-developer of MPP and a co-founding member of the x402 Foundation. Reading Stripe's agentic commerce strategy, the approach is clear: treating MPP and x402 not as competitors but as different layers of payment infrastructure. MPP operates on Stripe's commercial payment stack, while x402 handles permissionless payments on the open network. This division is being institutionalized under the Linux Foundation's neutral governance structure.

A Google Cloud representative commented: "The shift toward agentic commerce requires cloud infrastructure as open as the protocols it supports."

Implementation Status — What the Numbers Tell Us

No matter how sophisticated a protocol's design, what matters is real traction.

As of March 2026, x402 records approximately 131,000 daily transactions at about $28,000 in processing volume. Average payment per transaction is $0.20. Cumulatively, it has reached 119 million transactions on Base and 35 million on Solana, annualizing to roughly $600 million in volume. However, as CoinDesk's analysis points out, roughly half of transactions are infrastructure tests or self-trades, and real demand-driven traction remains limited.

MPP launched on March 18, 2026, with over 100 services integrated at launch. Implementation partners like Browserbase and PostalForm are operational, but meaningful transaction volume data has not yet been published.

Both protocols share the reality of "infrastructure leading, with demand catching up." However, while x402 has nearly a year of performance data, MPP holds Stripe's existing merchant base as a powerful distribution channel, suggesting potentially different growth trajectories ahead.

Positioning Within the Payment Protocol Stack

x402 and MPP serve as the "payment execution layer" within the agentic commerce payment stack. Understanding this positioning requires looking at their relationship with upper layers.

Google's AP2 (Agent Payments Protocol) is an authorization framework for agent payments through cryptographically signed Mandates. AP2 defines "who, what, and how much" authorization, while x402 and MPP handle actual payment execution. As Crossmint's comparison shows, production environments are designed for multiple protocol elements to function together.

So which should developers choose? WorkOS's recommendation is clear. For permissionless APIs and indie developer services, x402. No vendor registration required; a wallet and middleware are all it takes to accept payments. For those already on Stripe who want to accept agent traffic, MPP. It enables machine-to-machine payments at the configuration level without rebuilding the existing payment stack.

In many cases, the ultimate answer will be "both." As Stripe's participation in the x402 Foundation suggests, the two protocols are moving toward coexistence as different layers of the same infrastructure.

Conclusion

x402 and MPP tackle the same domain of machine-to-machine payments with different architectures. x402 embeds stateless payments into the HTTP protocol layer, while MPP addresses high-frequency workloads with session-based streaming. The x402 Foundation's establishment and Stripe's dual participation institutionally confirm their complementary relationship. While the infrastructure for the machine economy is still in its early stages, the fundamental structure of payment rails is taking shape.