MPP vs. x402: Two Ways to Pay an Agent
Stripe’s Machine Payments Protocol and the open x402 rail both answer the same question — how does an AI agent pay for something? They agree on the mechanism and disagree on the one thing that follows from it: who holds the money.
Two things happened to agent payments in quick succession, and they rhyme. The open-source x402 protocol took the long-dormant HTTP 402 “Payment Required” response — a status code that sat reserved-but-unused in the web’s plumbing for decades — and turned it into a working rail, so software could pay per request with no account and no card. Then, in March 2026, Stripe and the new Tempo blockchain launched the Machine Payments Protocol, or MPP — and it, too, is built on HTTP 402.
That coincidence is the most useful fact for understanding the landscape. The two are usually framed as competitors, and in places they are. But they don’t disagree about how an agent should ask to pay, or how a server should demand it. A server returns 402 with the payment details; the agent authorizes, pays, and receives the resource and a receipt. Both protocols do exactly that. The argument between them is not about the handshake. It is about everything that happens to the money after the agent agrees to pay — and that comes down to a single question: who holds it.
The custodial rail: MPP, Stripe and Tempo
MPP’s flagship settlement layer is Tempo, an EVM-compatible Layer-1 incubated by Stripe and Paradigm that went live on mainnet in March 2026. It is fast — sub-second finality — and its gas is paid in stablecoins, so a transfer can cost a fraction of a cent. On paper it looks like any other modern chain. The difference is who runs it. Tempo is permissioned: it runs a closed validator set that includes Stripe, Visa, Zodia Custody and MoneyGram, and it ships with a protocol-level policy registry that can maintain allow- and block-lists and freeze funds in an emergency. That is a deliberate design choice, and for a regulated payments business it is a feature, not a bug.
For the merchant, MPP rides on top of Stripe’s existing rails. You accept it the way you already accept Stripe payments — a few lines against the same APIs — and the funds arrive as a balance in your Stripe account. You can take cards or stablecoins; an agent can pay with a Shared Payment Token that never exposes the buyer’s real credentials. Then Stripe pays you out, on its schedule, to your bank — in your local currency, roughly two days later for the default US card payout — or, if you prefer, in USDC to a wallet. Through the whole journey, the money is held by Stripe (or by Bridge, the stablecoin custodian Stripe owns) until it lands with you.
Be honest about what that buys you, because it is a lot. Stripe absorbs the parts of payments that are genuinely hard and genuinely unglamorous: fraud scoring, chargebacks and dispute handling, sanctions screening, the Travel Rule, the tax and reporting machinery, and the regulatory licensing that makes all of it legal in dozens of countries. If an agent is defrauded, there is a party who can reverse the transaction. If a payment needs to settle as dollars in a bank account, it does. For a consumer-facing merchant — or any business that does not want to touch crypto, hold keys, or become its own compliance department — that is exactly the deal it wants.
The price of the deal is also clear. There is a cut: about 1.5% on stablecoin payments, and Stripe’s standard 2.9% + $0.30 on cards, plus a currency-conversion fee of around 1% where it applies. There is custody: your money sits with a third party in transit, and is released on someone else’s timetable. There is onboarding: a Stripe account, KYC, and availability only in the countries Stripe supports. And there is the chain itself, whose policy registry means a payment can, in principle, be frozen or an address blocked. None of that is hidden or sinister — it is the cost of having a regulated intermediary do the work. It is simply the opposite of self-custody.
The open rail: x402, wallet-to-wallet
x402 makes the other choice at the fork. When the agent agrees to pay, it sends a transfer straight to the merchant’s own wallet — one on-chain transaction — and the merchant verifies that transaction itself, reading it against its own RPC node. No processor sits in the middle. No custodian ever holds the funds. There is no facilitator the merchant has to trust and no database it has to run; the protocol’s own specification blesses this merchant-local verification, so the backendless shape is supported, not a workaround. The money was in the buyer’s wallet, and a few seconds later it is in the seller’s. That is the entire path.
Because nothing intermediates, there is no protocol fee — 0%. The only cost is the chain’s gas, which on a low-cost chain is a fraction of a cent, and which can be sponsored entirely so the buyer pays nothing at all. There is no account to create and no approval to wait for: a developer runs npm install, names a chain, adds a wallet, and can accept payments. And it is not tied to one chain — it works across roughly 29 of them, from Base and Solana to the XRP Ledger, so an agent pays with whatever it already holds.
The honest cost of that openness is the mirror image of MPP’s. You hold your own keys, which means you carry the risk that comes with them — lose them and there is no support line. Settlement is final: a wallet-to-wallet transfer on a public chain has no chargeback, which protects the payee and exposes a defrauded payer. Compliance is yours to handle, not a processor’s. And unless you off-ramp the funds yourself, you end the journey holding stablecoins or crypto, not dollars in a bank. The open rail asks more of you precisely because it removes the party that would otherwise do those things — and take a cut for it.
This is the side I build on. PipRail is an open, self-custody implementation of x402 — a TypeScript SDK and an MCP server that let a developer accept payments in one line, or hand an agent a budget-bound wallet (a hard spend cap, per call and lifetime, that the agent cannot exceed) to pay across roughly 29 chains — the broadest reach of any x402 SDK, and the only one that puts the payer’s own wallet on chains like NEAR, Aptos, and the XRP Ledger. No backend, no account, no fee; payments go straight to the developer’s wallet, verified locally against their own node. So I have a side, and I am telling you which one. But the comparison below is the one I would want to read if I were choosing.
The two rails, side by side
Strip away the framing and the differences are concrete. Here is the same payment, measured on the things a merchant or an agent actually cares about. Notice that the top row is identical — the disagreement starts the moment money has to move.
Which one should carry the payment?
Because both speak 402, this was never really an either/or for the buyer. An agent can support both, and a server can advertise more than one way to be paid — Stripe’s own Agentic Commerce Suite, in fact, supports MPP and x402. So the useful question is not “which protocol wins,” but “which rail should this particular payment ride.”
MPP is the right rail when the payment looks like commerce as we already know it. A regulated merchant selling to consumers, who needs chargebacks and a fraud net. A business that wants its money to land as dollars in a bank and never wants to see a private key. Anyone for whom “Stripe handles compliance” is worth more than the 1.5%. For those payments, the custodian is doing real work, and the fee is the price of not doing it yourself.
x402 is the right rail when the payment is small, frequent, and machine-to-machine. An agent buying a single API call, or paying another agent for a subtask, hundreds of times an hour. A builder who is already crypto-native and wants self-custody by default. Anyone who balks at a percentage cut on a sub-cent payment, or at a two-day payout schedule for money that moved in two seconds, or at asking permission to accept funds at all. For those payments, the intermediary is overhead, and removing it is the point.
It helps to look at the human web for the shape of where this goes. Most of the money online runs through processors like Stripe, and that is not changing — the convenience and the compliance are worth it to most businesses. But a real, durable share of the web is self-hosted and self-custodied, by people who want to own their stack rather than rent it. The agent economy will split the same way. There will be a custodial lane and an open one, and both will be large.
PipRail’s bet is simply that the open lane is bigger than it looks — and that the agent-to-agent payments at the center of it, the small and constant ones that will outnumber every other kind, want a rail with no middle: no account, no custodian, no cut. The custodial rail meets businesses where they are. The open rail is the one you own rather than the platform you join. Both will carry real money. We are building the one we would want to pay on.
Like & share PipRail
Star on GitHub Follow @piprailhq