x402 and MPP Are Not the Same Thing

By René Menozzi

March 18, 2026 is a date worth marking in the agentic payments space. It is the day MPP, co-authored by Stripe and Tempo, launched publicly. It joins x402, which has been live since May 2025. Both protocols use the HTTP 402 status code as their foundation. Both are designed with AI agents as the primary users. Both claim to solve the same core problem: making it possible for software to pay for things autonomously, without human intervention in the payment step.

The surface similarity is enough to produce real confusion. Builders describe them as competing options for the same job, and the technical press covers them as if the question is simply which one will win. That framing misses something important. Most of these comparisons are outdated, comparing MPP against x402's original V1 launch. These protocols share a primitive and diverge sharply from there, in their philosophy, their architecture, and the kinds of problems each one is actually designed to solve.

This article explains what each protocol is, how each one works, and what the architectural difference between them means in practice, reflecting the realities of both MPP's launch and x402's V2 update.

The primitive they share, and why it matters

HTTP, the protocol that runs the web, communicates through status codes. A 200 means the request succeeded. A 404 means the resource was not found. A 403 means access is forbidden. These are well-understood conventions that every HTTP client and server speaks natively.

There is also 402: Payment Required. It was defined in the original HTTP/1.1 specification in 1999, explicitly reserved for future use by payment systems. For 25 years, nothing used it. Every web payment system built its own solution on top of HTTP rather than into it: checkout pages, API key systems, subscription flows, invoice portals. Payments were always a layer bolted on, not a layer built in.

The reason nothing used 402 for so long is that the infrastructure to make it work did not exist. Payments required human interaction: someone to enter a card number, approve a transfer, confirm an OTP. The model assumed a person on the other side of every transaction. AI agents change that assumption. An agent can receive a payment challenge, compute a response, and retry a request in milliseconds. The machine-readable nature of HTTP 402 becomes an asset when the client is software.

Both x402 and MPP recognized this and built on the same foundation. A server responds to an unpaid request with a 402 status and a machine-readable description of what it wants to be paid. The client reads that description, handles the payment, and retries. The resource is delivered. Both protocols use this cycle. What they add on top of it is where they diverge.

What x402 actually is

x402 was created by Coinbase and launched in May 2025, with Cloudflare as a co-founder of the x402 Foundation. The design philosophy is minimalist and crypto-native. Coinbase's position was that AI agents would eventually need to transact the same way software sends data: directly, programmatically, without intermediaries. The protocol they built reflects that belief. The initial V1 release was strictly a per-request paradigm.

The core x402 request cycle is straightforward. A client makes an HTTP request to a resource. The server responds with a 402 status, specifying the price, the accepted token, the network, and the recipient address. The client constructs a signed payment authorization, a cryptographic signature that says "you may move this amount from my wallet." It retries the request with that signature attached as an HTTP header. The server verifies the signature, typically via a facilitator such as Coinbase's own service, and delivers the resource.

Three things historically defined x402's character. First, it is permissionless. Anyone can run a resource server or build a client without approval from Coinbase or any central authority. Second, it is crypto-native. Third, it was initially strictly per-request, requiring the full 402 cycle for every discrete call.

The V2 Reality (December 2025)

Much of the current discourse ignores that x402 V2 shipped in December 2025 and fundamentally narrowed the capability gap with MPP. The V2 update introduced several major primitives:

• Wallet-based Sessions (SIWx): Based on the CAIP-122 standard, clients can now authorize a session token once using Sign-In-With-X, skipping the full payment validation loop for repeated interactions. This directly addresses the per-request overhead limitations of V1.
• Fiat Support via Facilitators: While still crypto-native at its core, the V2 architecture explicitly supports facilitators translating between ACH, SEPA, and card networks to fit the same protocol request model.
• The Bazaar: A new discovery layer where facilitators automatically index available endpoints, letting agents easily query real-time pricing, routing, and metadata without relying on static catalogs.
• Multi-chain via CAIP: A unified payment architecture standardizing routing across chains (dynamic payTo logic for marketplaces) via a robust plugin-driven SDK.

To date, the protocol has processed over 100M payments. Google has integrated x402 as the crypto settlement extension within its AP2 (Agent Payments Protocol), giving x402 access to a coalition of over 60 partners including Shopify and Walmart.

What MPP actually is

MPP (Machine Payment Protocol) was co-authored by Stripe and Tempo and launched on March 18, 2026. Where x402 is minimalist and standard-driven, MPP is explicitly designed for deep enterprise integration. It uses the same 402 flow but tackles the problem with an out-of-the-box, vertically integrated suite driven by fiat readiness and its Sessions primitive.

The fiat support works through Stripe's Shared Payment Tokens. An agent authorized to use a card or bank account can make payments through Stripe's existing rails, completely sidestepping the crypto onboarding requirement that introduces friction for enterprise compliance teams, handling tax and fraud calculation out of the box.

The Sessions primitive & Tempo Settlement

MPP's Sessions primitive is described by its authors as "OAuth for money." OAuth solves the problem of granting a third party limited access to a resource without sharing credentials. Sessions solves the analogous problem for payments: granting an agent limited, scoped spending authority ("$50 over the next 24 hours") so it can execute thousands of inference calls or utilize a continuous data stream on a single authorization token. The payments are tallied and settled on-chain in one aggregate transaction at the end. While x402 added sessions in V2, MPP's escrow contracts and streaming rails for sessions are widely considered more robust at launch.

MPP's crypto settlement runs on Tempo, an L2 co-developed with Stripe and Paradigm built using Simplex BFT for half-second, deterministic finality. Tempo has fascinating architectural tradeoffs:

• No native gas token: There is no concept of buying ETH or SOL to pay for gas. Agents simply hold and pay in USDC.
• Enshrined Fee AMM: You pay in a stablecoin, and an enshrined on-chain AMM automatically converts it into validator-selected fee tokens, supporting micro-transactions under $0.001.
• Dedicated Payment Lanes: Tempo reserves blockspace specifically for payment transactions, completely isolating them from retail DeFi swaps and NFT mint congestion (the "noisy neighbor" problem).
• Friction Points: As developers build with it, they've noted Tempo relies on TIP-20 rather than standard ERC-20, requiring token account initializations and the mppx CLI fee payer relay, creating slightly non-standard web3 friction.
• Validator Nuance: Tempo at launch uses a permissioned validator set operated by the core team and select partners. To quote the community discourse: it is "permissionless if you're building, permissioned if you're securing." The team notes a roadmap toward progressive decentralization.

The enterprise ecosystem surrounding MPP at launch is formidable. Visa extended MPP for card-based agent payments (Visa CLI). Lightspark extended it for Bitcoin Lightning. Privy is building programmable self-custodial MPP wallets. Klarna is launching KlarnaUSD on Tempo. Financial institutions ranging from UBS to Deutsche Bank, Kalshi to Revolut are all exploring deployments.

Two layers of the same stack

The smartest take circulating among builders right now is that framing x402 vs MPP as a zero-sum war is fundamentally missing the plot. They are not fully competing products; they are two layers of the same stack.

x402 is standardizing the signal and discovery protocol. It is standardizing the HTTP response: "This resource costs $0.001." and through The Bazaar, it tells agents where to find it.

MPP is standardizing the movement and execution logic. It is standardizing the ledger entry: "Here is exactly how the money flows from entity A to entity B."

x402 without MPP means an autonomous agent can interpret the price of a service but lacks a standardized, enterprise-grade way to move the money securely with robust accounting. MPP without x402 means an agent operates a highly-efficient wallet, but lacks an open standard to actively discover what endpoints cost across the web. The most critical proof of this alignment? Stripe openly supports and integrates both protocols.

What Builders Are Actually Doing

While theoretical architecture is interesting, adoption is happening right now in the wild:

• Builders like @gajesh are getting virtual debit cards funded through MPP in under 30 seconds to supply arbitrary APIs to their agents.
• Agents are making successful $0.03 unified Tempo transactions mapping to native search applications (@jonbma).
• Claude Code instances are running autonomously, spending $0.01 per query via Tempo to hit live flight search APIs.
• Engineers are building unified invoice managers via standard MCP integrations taking advantage of Stripe's reporting APIs layered atop Tempo's validation logic (@naruto11eth).

What to take from this