How similar are they?#
At the wire level, strikingly. Both answer an unpaid request with machine-readable payment requirements, take a signed authorisation on the retry, and settle. An engineer who has implemented one will recognise the other immediately.
The differences are in what sits behind the handshake.
| x402 | MPP | |
|---|---|---|
| Governance | x402 Foundation, Linux Foundation hosted | Stripe and Paradigm, with partners |
| Default settlement | Stablecoin on a public chain | Stripe PaymentIntents, Tempo by default |
| Rails | On-chain only | Stablecoins, cards and others |
| Seller needs | A wallet address | A Stripe relationship |
| Public record | Every settlement on-chain | Processor records, private |
| Gas | Facilitator pays, buyer holds one asset | Tempo takes fees in stablecoins, no native token |
Both removed the native-token requirement, by different routes. x402 does it by having the facilitator broadcast; Tempo does it by letting fees be paid in stablecoins directly.
What is Tempo, and does it matter?#
Tempo is a payments-focused layer 1 that went to mainnet on 18 March 2026, the same day MPP was announced. Stripe's own documentation describes predictable fees typically under a tenth of a cent, and Stripe uses the chain itself for stablecoin storage and movement.
It matters for one reason that has nothing to do with throughput. A chain operated in the interest of one payments company is a different trust assumption from a general-purpose public chain, even when both are technically permissionless. For most sellers that difference is abstract. For anyone whose business is adversarial to Stripe's, or who expects to be, it is not.
MPP's rail-agnosticism cuts the other way, though. Because it is not bound to Tempo, a seller can in principle take MPP payments that settle elsewhere, including on cards. That optionality is real and x402 does not have an equivalent.
What does Sessions add?#
MPP's sessions extension, added in April 2026, allocates funds up front and streams them as the agent consumes a service, with signed off-chain vouchers and later on-chain settlement.
This is a genuinely different shape from x402's one-payment-per-request, and it is better for a specific case: continuous or high-frequency consumption where settling every unit individually would cost more in overhead than the units are worth. Streaming inference and metered compute are the obvious fits.
x402's answer to the same problem is deferred payment schemes, which several facilitators including Cloudflare have published. The trade is the same in both: fewer settlements, lower overhead, and the seller carrying credit risk between them.
Note
Both approaches move the unit of account away from the individual request, which has a measurement consequence. An index built from on-chain settlements sees one settlement where a thousand calls happened. If you are comparing per-call figures across sources, whether batched payments are counted once or many times is a real source of disagreement.
Which should you choose?#
By your relationship to the two ecosystems, not by feature count.
You already run on Stripe. MPP is less work. Your payouts, reconciliation, tax handling and dispute process already exist and continue to work. This is a large practical advantage and it is the main one.
You want your activity to be publicly verifiable. x402. Settlements are on a public chain, so a buyer can check what you have been paid without asking you, and so can anyone evaluating you. Screening a counterparty only works when the record is open.
Your buyers are autonomous agents with wallets and no accounts. x402 has far more live deployment on that specific path, and the client libraries and facilitator coverage reflect it.
You sell above a few dollars to consumers. Neither, probably. That is ACP territory or ordinary checkout.
Can you support both?#
Yes, and it is less work than it sounds because the HTTP shape is so similar. The honest caution is that supporting two payment paths means two settlement reconciliations, two failure modes and two sets of support questions, and that cost is ongoing rather than one-off. Most sellers should pick one and add the second when a buyer asks.
Frequently asked questions#
Is MPP open source?#
The protocol is published and partners including Visa and Lightspark have implemented extensions. It is not under a neutral foundation the way x402 is, and that is the governance difference to weigh for a long-lived integration.
Does MPP need a blockchain?#
Not necessarily. It is rail-agnostic, and Tempo is the default rather than a requirement. Settling through cards is an explicitly supported path.
Which is cheaper per transaction?#
It depends on volume and on which facilitator or processor you use, and published figures for both are low enough that other costs dominate. At a tenth of a cent either way, the integration and reconciliation cost of your choice is the larger number.
Can one endpoint advertise both?#
In principle you can return requirements for both and let the client choose, since both are driven by what the server advertises. In practice few clients implement both, so you are usually serving two populations rather than offering a choice.
Does Stripe's involvement make MPP safer?#
It makes the counterparty risk familiar rather than absent. You are trusting a large regulated payments company instead of a facilitator and a chain. Which of those you prefer is a real question with no universal answer.
Where to check this yourself#
The asymmetry in this comparison is itself informative: x402 activity can be audited from outside and MPP activity cannot. /transactions, /facilitators and the data API let you verify x402 settlement claims yourself. For MPP you are reading what the parties publish.