HTTP 402 Payment Required so an agent can pay for a resource with no account and no prior relationship. They differ in scope: x402 is a lean, USDC-native on-chain standard; MPP is a multi-rail framework that also reaches cards and fiat. This page compares them and explains why picking one is usually the wrong question.
x402, briefly
x402 turns402 into a real pay-per-call flow: the server answers with a payment instruction, the client pays on-chain in USDC (primarily Base and Solana), and retries with proof. It originated at Coinbase and is now stewarded by the x402 Foundation under the Linux Foundation. See the x402 primer for the challenge shape.
Reach for x402 when your stack is crypto-native, you want the leanest pay-per-call flow, and USDC settlement fits your merchants.
MPP, briefly
MPP — the Machine Payments Protocol, co-authored by Stripe and Tempo — is also built on402, but aims wider. It formalizes a 402 authentication scheme (submitted to the IETF) and is explicitly multi-rail: Tempo-native stablecoins today, plus Stripe card / Shared Payment Token flows and extensible custom methods. You do not have to settle on Tempo to use MPP. See the MPP on Tempo primer.
Reach for MPP when you need rails beyond USDC, your merchants speak MPP, or they live in Stripe’s world.
At a glance
The catch: you probably need both
You do not get to choose x402 or MPP once and be done — the merchant chooses. One paid API answers402 with an x402 challenge; the next answers with MPP. An agent that speaks only one stalls on every merchant that speaks the other. So the real answer is usually “both,” which means two sets of credentials, two settlement shapes, liquidity on two rails, and reconciliation across both — an integration tax that grows with every new protocol (ACP, UCP, and AP2 are already in the market).
The rail-neutral answer
This is the gap SELAT closes. Instead of making your agent fluent in every protocol, SELAT puts a rail-neutral path in front of it: discover a capability, fund Circle Gateway, and pay USDC from the user’s Circle Agent Wallet. You sign one shape; SELAT translates it into whatever the upstream speaks — Gateway-batched x402, on-chain x402, or MPP — and never holds keys or funds. How the router picks the outbound rail per call is covered in How SELAT chooses the rail. In practice, one command:selat run spends unless you pass --dry-run. It discovers a service, prices it, detects the rail, pays (direct or routed), and returns the response — without your code branching on protocol. See the SELAT CLI. Ranking is by fit, live quote, rail, and reliability, not a hard-coded “always MPP” or “always x402.”
Choosing a single rail bets that the market consolidates; choosing a neutral layer above the rails bets it won’t — so far the safer bet.
Bottom line
- x402 — lean, USDC-native, crypto-first.
- MPP — broad, multi-rail, fiat and card-capable.
- Both — the production reality, because merchants pick, not you.
- Neutral routing — how to support both (and whatever’s next) without paying the integration tax twice.
FAQ
What is the difference between x402 and MPP?
Both useHTTP 402. x402 is a USDC-native, on-chain pay-per-call standard (Coinbase → Linux Foundation). MPP is a multi-rail framework (Stripe + Tempo) that can settle stablecoins, cards, and custom methods.
Should my agent implement x402 or MPP?
The merchant chooses the rail. If you only implement one, you stall on merchants that speak the other. Agents paying across catalogs usually need both — or a router that speaks both.Does MPP only settle on Tempo?
No. Tempo is one production method. MPP also specifies Stripe card / Shared Payment Token flows and lets others add methods; it is payment-method agnostic.How does SELAT pay x402 and MPP?
One self-custody Circle Agent Wallet, funded via Circle Gateway, paying USDC. SELAT detects the upstream rail and settles; it never holds keys or funds.selat run spends unless you pass --dry-run.