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 a session-based streaming protocol. An agent (or its operator) authorises a spending limit upfront with Stripe; over the life of that session the agent calls APIs and Stripe streams micropayments against the authorised cap. The compliance, KYC, dispute handling, and reconciliation all live in Stripe's stack, with currency exchange handled the way Stripe handles any other payment. It launched on March 18, 2026 alongside Tempo.
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 access over a session — an agent running for a long task that will hit many of your endpoints, often the same one repeatedly — MPP's "authorise a budget, stream against it" shape is closer to the workload. The agent does not pay a tiny fee per call; it draws from a pre-authorised pool.
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.
MPP softens this with session aggregation: many micro-charges are settled as part of a stream rather than each one going through the full Stripe charge cycle. That changes the picture for high-frequency callers within a single session. It does not change the picture for the single-call long-tail case, where x402's stablecoin settlement model carries far less overhead per transaction. The honest summary is: if you expect a lot of calls per agent-operator per session, MPP's economics become acceptable; if you expect one-off calls or genuinely sporadic agents, x402 is the cheaper substrate.
4. Where compliance and disputes live
Stripe's MPP inherits Stripe's compliance stack — KYC of the funding party, fraud screening, dispute handling, chargebacks. For an API selling into a regulated downstream user, that machinery is real value; you do not build any of it.
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 shape is closer.
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 Paywall, the x402 side is already done for you (SDKs); adding an MPP path on top is additive, not disruptive.
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 access during long-running agent sessions, and your customer base is operators with established billing relationships: MPP fits the workload, and you already know Stripe.
- You sell into regulated downstream users who need chargebacks and Stripe-style dispute machinery: MPP. x402 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 session-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.