The agent-payments space has, in the space of a year, gone from "nobody is shipping this" to "two credible protocols are in production." On one side, x402, the HTTP-native pay-per-call protocol governed by the x402 Foundation and now under the Linux Foundation umbrella. On the other, Stripe's Machine Payments Protocol (MPP), launched in March 2026 with Tempo, bringing Stripe's compliance and rails to autonomous callers.
If you are picking infrastructure to charge AI agents for an API or a tool, you are now picking between these two. This post compares them honestly — same protocol literature, same engineering criteria — so you can decide which fits your workload without re-reading every announcement. For background on x402 itself, see What is x402?; for the model it replaces, see x402 vs API keys.
What each one actually is
x402 is an open HTTP protocol. A monetised resource answers an unpaid request with 402 Payment Required and a quoted price; the caller pays in a stablecoin (typically USDC); the caller retries with proof; the server verifies and serves. There are no accounts, no sessions, no API keys — the protocol is the whole surface. It is governed under the x402 Foundation (Coinbase, Cloudflare and others) and was admitted to the Linux Foundation in April 2026 with Google, AWS, Microsoft, Stripe, Visa, Mastercard and others as founding members.
Stripe's MPP is built on the same HTTP 402 challenge-response as x402. A monetised resource answers an unpaid request with 402 Payment Required and payment challenges (carried in WWW-Authenticate headers); the agent authorises payment, retries with an Authorization: Payment credential, and gets the resource plus a receipt. Each payment is independent — there's no pre-authorised session or budget aggregation in the base protocol. What MPP adds on top is Stripe's rails and lifecycle: settlement in stablecoin (on the Tempo network) or fiat (cards and other methods via Shared Payment Tokens), plus recurring-subscription and streaming primitives, all wrapped in Stripe's compliance, fraud screening, and reporting. It was co-authored with Tempo and launched on March 18, 2026.
Neither replaces the other. They optimise different things.
The decision tree, honestly
If you have read the marketing of either, you have read why it is the future. The useful framing is "which one fits your specific workload." A few axes that actually move the answer:
1. Granularity of the unit you sell
If the thing you are selling is a single discrete call — a search, an enrichment, a model invocation, a tool result — and you want to be paid every time, x402 fits natively. The 402 challenge quotes a price for that call; payment proof is attached to that call's retry. There is no session to open and close, no spend-cap to size in advance.
If the thing you are selling is continuous or recurring access — a subscription, or a long-running stream an agent consumes over time — MPP's lifecycle primitives (recurring billing, and streaming from Sessions 2026) are built for that shape, which x402's single-shot 402 leaves you to assemble yourself. Both protocols handle the one-off call the same way; MPP simply layers the subscription and streaming machinery on top.
2. Onboarding the caller
x402 has no onboarding for the caller. There is no account on your platform; the agent shows up with funds and a wallet, gets the 402, pays, gets served. For an API owner this is an asset: an agent your operator has never heard of can pay you for a single call and never come back, which is exactly the long-tail behaviour you want to capture.
MPP has Stripe's onboarding for the operator of the agent — same way any Stripe-paid service works. Familiar territory for teams already on Stripe, and a real lift for teams that aren't. If your customer base is "businesses with Stripe accounts whose agents will make many calls," that lift is paid back; if it is "an open population of agents you have never seen before," it is friction that costs you reach.
3. Per-transaction overhead
This is the math people skip and it matters. Stripe's classic fee is $0.30 per successful charge + 2.9% of the amount. At a SaaS price of $29/month, that comes out to $1.14 in fees — roughly 3.9%, which is reasonable. At a per-call price of $0.005, the same fee structure destroys the unit economics, because $0.30 dwarfs $0.005.
The overhead depends on the rail, not just the protocol. Settling in stablecoin — which both x402 and MPP's Tempo path do — carries far less per-transaction overhead than a card charge, so sub-cent prices stay viable. MPP's card path inherits Stripe's $0.30 + 2.9%, which is fine at SaaS-sized amounts but destroys sub-cent unit economics because $0.30 dwarfs $0.005. The honest summary: for one-off, sub-cent, long-tail calls, stablecoin settlement (x402, or MPP on Tempo) is the cheaper substrate; card rails only pay off at larger ticket sizes.
4. Where compliance and disputes live
Stripe's MPP inherits Stripe's payments stack — fraud screening, tax, reporting, refunds, and — on its card path — the dispute and chargeback machinery cards carry. For an API selling into a regulated downstream user, that machinery is real value; you do not build any of it. (Its stablecoin path, like x402, settles without chargebacks.)
x402 has a different shape. The caller pays in a stablecoin; settlement is by reference, not by reversible charge. There is no chargeback. Disputes, when they exist, are resolved off the rails. Most API operators serving autonomous callers prefer non-reversibility — the call ran, the payment cleared, both sides move on — which is exactly the property x402 ships with. If your business genuinely needs chargebacks (consumer-facing, high-fraud category), MPP's card path gives you that — though its stablecoin path is non-reversible too, just like x402.
5. Identity of the caller
x402 identifies the payment, not the caller. The 402 challenge cares about price and proof of settlement; it does not care which agent or operator paid, because the call's outcome is the same either way. That is the right default for an open market — the same way an HTTP server does not need to know who is fetching a URL to serve it.
MPP identifies the operator — the entity that authorised the spend. This is good if you have a notion of "customers" in the classical sense (people who reconcile their bill at month-end, who you want to upsell, who can churn). It is overhead if you do not — most APIs serving autonomous callers in 2026 do not.
Where they coexist
It is tempting to frame this as a fight. It is not, yet. A serious API in 2026 can support both. x402 captures the long-tail, one-off, anonymous-program traffic with no integration on the caller side. MPP captures the high-frequency, repeat-business, operator-known traffic with a familiar billing path. Most monetised APIs will end up with x402 on the wire and an MPP path for operators who prefer it; the work is small enough that having both is cheaper than picking one and being wrong.
The middleware shape on the server is similar in both cases — your handler runs only after a payment is verified, and otherwise returns the appropriate failure. With Payrelayer, the x402 side is done for you (SDKs); an MPP path, if you decide to add one, sits alongside rather than forcing a rebuild.
So which one do I pick?
A pragmatic rubric, in plain English:
- You sell discrete API calls or MCP tools, and want the broadest possible audience of agents to be able to pay you for one call: start with x402. The audience is "any agent runtime with a wallet," which is now the default. See MCP server monetization with x402 for the tool-calling version.
- You sell continuous or recurring access — subscriptions or streamed usage — and your customer base is operators with established billing relationships: MPP's lifecycle primitives fit, and you already know Stripe.
- You sell into regulated downstream users who need chargebacks and Stripe-style dispute machinery: MPP's card path. x402 (and MPP's stablecoin path) is intentionally non-reversible.
- You don't know yet, and want to ship today: x402, because the integration is small (five-minute integration guide), the audience is broad, and adding MPP later is additive.
There is no scenario in which x402 blocks MPP, or vice versa. There is no protocol war to win or lose on the API operator side. The honest version is: x402 is the right HTTP-native default for paid agent calls, MPP is the right path for subscription- or stream-billed agent traffic where you already have a Stripe footprint, and a mature API will likely speak both within twelve months.
One thing worth saying out loud
The most interesting fact about 2026 is not that two protocols exist — it is that the question has shifted from "can we charge agents?" to "which infrastructure fits which workload?" That is the same maturity curve every payment category goes through. The teams winning at it are the ones who stopped waiting for the standard to settle and started shipping a paid endpoint. Either protocol gets you to "earning revenue from autonomous callers" faster than any home-grown alternative; pick the one that fits the call pattern you actually have, and ship.
If you want to start with x402, the developer integration guide is the shortest path, and the SDK pages carry the per-stack snippets.