x402 vs MPP: Which Agent Payment Protocol Should You Use? (2026)
x402 and MPP both let AI agents pay for APIs over HTTP 402 — but they settle differently. A builder's comparison of rails, costs, and when to use each (or both).
If you're building an agent skill that has to pay for something mid-task — a paid API, a data feed, a unit of compute — you've probably hit HTTP 402 Payment Required and found two different answers waiting on the other side of it: x402 and MPP. They look similar from the agent's seat. They are not the same underneath, and picking wrong means re-plumbing your payment code when the next merchant speaks the other one.
This is a builder's comparison of x402 vs MPP: what each is, how they settle, what they cost, and when to reach for which. The short version: x402 is the lean, USDC-native, crypto-first standard; MPP is the broader, multi-rail framework with fiat and card support. Most serious agent platforms end up supporting both — which is exactly the problem a routing layer exists to solve.
What x402 is
x402 revives the dormant HTTP 402 status code into a real payment flow. A client requests a resource, the server replies 402 with a payment instruction, the client pays on-chain, and retries the request with proof of payment attached. No accounts, no subscriptions, no pre-existing relationship between buyer and seller.
x402 originated at Coinbase and is now stewarded through the x402 Foundation under the Linux Foundation, with institutional backers including Cloudflare, Stripe, AWS, Google, Visa, and Circle. It settles in USDC, primarily on Base (and increasingly other chains such as Solana). By early 2026 it had crossed from concept to real volume — Coinbase reported 160M+ agentic transactions across tens of thousands of active agents.
Use x402 when: your agent lives in a crypto-native stack, you want the leanest possible pay-per-call flow, and USDC settlement on Base/Solana fits your merchants.
What MPP is
MPP — the Machine Payments Protocol — is also built on HTTP 402, but it aims wider. Co-authored by Stripe and Tempo, MPP formalizes a 402 authentication scheme (proposed to the IETF) and is explicitly multi-rail: it supports stablecoins, cards, wallets, and custom payment methods through extensible specifications, and settles tempo-native on Stripe's payments-focused Tempo blockchain.
That breadth is the point. MPP carries the weight of Stripe's enterprise financial infrastructure and merchant network, so it reaches places a USDC-only flow can't — fiat-settled merchants, card rails, and mixed-currency settlement.
Use MPP when: you need rails beyond USDC, you're settling tempo-native, or your merchants live in Stripe's world.
x402 vs MPP at a glance
| x402 | MPP | |
|---|---|---|
| Origin | Coinbase → Linux Foundation | Stripe + Tempo |
| Built on | HTTP 402 | HTTP 402 (formal auth scheme, IETF-proposed) |
| Settlement | USDC, on-chain (Base, Solana) | Tempo-native; multi-rail |
| Payment methods | Stablecoin (USDC) | Stablecoins, fiat, cards, custom |
| Best fit | Lean crypto-native pay-per-call | Broad coverage incl. fiat/cards |
| Philosophy | Minimal open standard | Extensible multi-rail framework |
The catch: you probably need both
Here's what the comparison tables miss. You don't get to choose x402 or MPP once and be done. The merchant chooses. One paid API answers a 402 with an x402 challenge on Base; the next answers with MPP settling tempo-native. If your agent only speaks one, it stalls on every merchant that speaks the other.
So the real-world answer to "x402 vs MPP" is usually "both" — which means your agent now has to hold two sets of credentials, understand two settlement shapes, fund liquidity on two rails, and reconcile across both. That's the integration tax, and it grows with every new protocol that ships (and several already have: ACP, UCP, AP2, A2A, and more).
The rail-neutral answer
This is the gap SELAT is built to close. Instead of making your agent fluent in every protocol, SELAT puts a rail-neutral router in front of all of them. Your agent signs one shape and funds one wallet; the SELAT Router translates that single inbound payment into whatever the upstream speaks — Circle Gateway-batched (direct), x402 on Base/Solana, or MPP tempo-native.
In practice that looks like one command:
selat run "search the web for recent papers on agentic payments"SELAT discovers a service, prices it, detects the rail, pays it (direct or routed automatically), and returns the response — without your code branching on protocol. By default it prefers MPP among routed options and treats x402 as opt-in, but you never have to hand-write either flow.
The deeper point: x402 vs MPP is a real question today, and it'll be x402 vs MPP vs the next three protocols by next quarter. Choosing a single rail is a bet that the market will consolidate. Choosing a neutral layer above the rails is a bet that it won't — which, so far, is the safer bet.
Bottom line
- x402 — lean, USDC-native, crypto-first. Great when your stack and merchants are already there.
- MPP — broad, multi-rail, fiat and card-capable, Stripe/Tempo-backed. Great when you need reach beyond USDC.
- Both — the actual production reality, because merchants pick, not you.
- Neutral routing — the way to support both (and whatever's next) without paying the integration tax twice.
And one thought to carry out of the protocol weeds: the moment a skill chains merchants on both rails in a single run, the question quietly changes. It stops being "which protocol should I speak" and becomes "what pays every endpoint my skill calls — from one balance, under one set of caps, into one ledger." That's cross-rail composition, and it points to a category taking shape, not a feature — skill settlement — with rail comparisons like this one as its plumbing.
Want the rail-level details? See the x402 primer and the MPP on Tempo primer, or read how the SELAT Router resolves a payment end to end.