MPP vs x402: you do not have to choose.

Search "MPP vs x402" and you get the same shape of answer everywhere: x402 is the crypto-native one (Coinbase, Base, USDC, no accounts), MPP is the Stripe one (cards, Tempo, enterprise, sessions). It is a useful first cut, and the timing made it loud. MPP launched on 18 March 2026, the day Tempo’s payments chain went to mainnet, with over a hundred services signed on, and Stripe Directory arrived in June to make those services discoverable. Naturally everyone reached for a versus.

We accept both, in production, settling real money. From that seat the popular framing is mostly right and quietly wrong in one place that matters. Here is the honest version.

The two protocols, plainly

x402 is the smaller idea, done deliberately small. Coinbase revived the dormant HTTP 402 status code: an agent calls an endpoint, gets a "pay first" response with the amount, asset, network, and recipient, signs a USDC authorization for that exact transfer, and retries. A facilitator verifies and settles on Base. No API keys, no billing account, no human. The traction is real: per Chainalysis, x402 went from near-zero in mid-2025 to over 100 million cumulative transactions on Base through Q1 2026, and in a recent 30-day window did 3.1 million transactions. The mix also matured, with payments of a dollar and up rising from 49% to 95% of volume.

MPP, the Machine Payments Protocol from Stripe and Tempo, takes the same 402 pattern and generalises it. It is defined as an Internet-Draft and is payment-method-agnostic: one protocol that can carry an on-chain stablecoin transfer, a Tempo payment, or a card through a Stripe Shared Payment Token. It adds sessions, described as OAuth for money, where an agent authorises a spending cap once and then streams many small payments without re-approving each one. Its launch partners read like a roster of the internet: Anthropic, OpenAI, Shopify, DoorDash, Mastercard, and more.

What most comparisons get wrong

The standard line is "MPP assumes Stripe as the processor and Tempo as the settlement chain." For MPP’s Stripe method, true. As a description of MPP, incomplete, and the gap is the whole point of this post.

MPP defines an evm method. Under it, the agent signs an EIP-3009 transferWithAuthorization for USDC on an EVM chain like Base, and a facilitator settles it. No Stripe account. No Tempo. That is not a footnote, it is the same on-chain rail x402 runs on, wearing MPP’s discovery and challenge format instead of x402’s. So "crypto versus Stripe" is a false binary. MPP can be crypto. We know, because that is exactly how we ship it: MPP over the evm method, settling on Base, from a UK company that cannot use Stripe’s card rail at all.

What is identical underneath

Strip away the wire formats and the money movement is the same object. In both x402 and MPP’s evm method:

• The agent signs an EIP-3009 USDC authorization for an exact amount. It is just a signature, so the agent spends no gas.
• A facilitator verifies the signature and broadcasts the transfer, paying gas itself.
• Settlement lands as USDC on Base mainnet, to the recipient the challenge named.
• There is no account and no card. The payment itself is the credential.

Concretely: we settle an MPP evm payment through the same Coinbase CDP facilitator our x402 path uses. An agent paid us $1.00 over MPP with mppx, and the settlement is on-chain, a $1.00 USDC transferWithAuthorization you can verify on BaseScan. Swap the client for an x402 one and the receipt looks the same.

What actually differs

The real differences are about discovery, breadth, and intent, not the dollar.

Two notes worth keeping honest. First, MPP’s defaults lean Tempo: its registry, SDK ergonomics, and examples mostly assume the Tempo method, so the evm path takes a little more work to wire and is under-documented today. Second, the x402 numbers carry a caveat from the same Chainalysis analysis: a large share of late-2025 volume was linked to gamed or wash activity, so read the headline counts as direction, not gospel.

Why we accept both

Because asking an agent to carry the right client before it can pay you is a tax you do not need to charge. Our /provision endpoint answers with both an x402 PAYMENT-REQUIRED header and an MPP WWW-Authenticate: Payment challenge. An agent with an x402 wallet pays. An agent with mppx pays. Same endpoint, same settlement, one fewer reason for the payment to fail. Supporting both cost us one extra envelope over a rail we already ran, not a second integration.

It also matches where the money is going. The shift to dollar-scale agent payments is exactly the range a flat $1 to provision sits in, and the discovery surfaces, Stripe Directory on the MPP side and facilitator catalogs on the x402 side, are how an agent finds a service to pay in the first place. Being in both is cheap insurance against guessing which directory your next customer searches.

How to choose, if you must

If you are wiring payments into your own API and want a single answer: pick x402 when you want the smallest possible thing, crypto-native and pay-per-request, and you do not need cards or sessions. Pick MPP when you want multiple rails behind one protocol, streaming sessions, or the discovery reach of Stripe Directory, and you can either use the Stripe method (US account) or are happy to settle the evm method on-chain. Pick both when you simply want the widest set of agents to be able to pay you, which for a host is the whole game.

For the record, we are the both case. If you run an agent, you can pay us either way today, and the deeper how-it-works is on our x402 and MPP pages. If you build agent products, the point under the protocol war is the one to sit with: your next customer might be software, and it helps to take its money however it shows up.