MPP vs x402: a second agent payment standard, and one decision for API sellers

What Ripple shipped on September 17, 2026

Ripple released version 1.1 of the XRPL AI Starter Kit. The headline addition is support for the Machine Payments Protocol (MPP) — an open standard co-authored by Stripe and Tempo, the payments-focused L1 that went to mainnet in March 2026 — alongside the Open Wallet Standard, which lets software drive wallets across different chains through one interface.

The mechanics are the ones you already know from x402: a service answers an agent's request with a price, the agent authorises payment, the service delivers. Ripple's implementation runs over HTTP 402 with 3–5 second finality, fixed fees under a cent, and native DEX conversion on the ledger.

Jazzi Cooper, RippleX head of product, framed the release the way an infrastructure vendor does: "Our job is to make XRP and RLUSD first-class options wherever developers are building." Ripple had already added x402 support in June 2026 — we covered that in Ripple brings x402 to the XRP Ledger — so the company now backs both standards rather than betting on one.

Circle, for its part, launched its payments chain Arc the day before. Two competing agent-payment stacks announced inside 48 hours is a reasonable summary of where this market is in September 2026.

The detail in the release notes that matters to a seller

Read past the press coverage and there is one line an API provider should stop on.

On XRPL, MPP supports single payments in XRP, in issued assets like RLUSD, and in Multi-Purpose Tokens. But session payments — the streaming mode where an agent opens a channel, signs off-chain vouchers as it consumes, and the provider settles with two on-chain transactions — work only with XRP. Payment channels are native to the XRP Ledger's own settlement system; RLUSD sits on top of that ledger as an issued token, and extending channels to issued tokens requires a future XRPL amendment that Ripple has not scheduled. You can read the channel mechanics in XRPL's own documentation.

Translate that into a revenue statement. If you are an API provider and you accept a session on XRPL today, the money arriving for your metered compute is XRP — a volatile asset — not a dollar. You can convert it, on the ledger's DEX or elsewhere, and you can hedge. But the default behaviour of the newest, most-hyped payment mode sends you something whose price moves while you're serving the request.

That is not a criticism of Ripple's engineering, which is doing exactly what the ledger permits. It's an observation about what "supported" means when you're the one being paid. Supported by a chain is not the same as usable by a business.

Two standards, three chains, and the cost lands on the seller

Step back and look at what has shipped in three weeks.

• September 3: the Solana Foundation launched Payment Channels, with escrow, off-chain vouchers and a benchmark measured in millions of payments per second.
• September 16: Circle's Arc mainnet went public, positioned as a chain built for stablecoin payments.
• September 17: Ripple wired MPP and channel-based sessions into XRPL.

Each announcement is written for a developer building the buyer. Each one adds a row to a matrix that the seller has to reason about: which protocol (x402 or MPP), which mode (per-call or session), which chain (Base, Solana, XRPL, Tempo, Polygon), which asset (USDC, USDT, RLUSD, XRP), which facilitator, which wallet standard.

MPP is a genuinely well-built specification — it defines a payment-method-agnostic core with intents (charge, authorise, subscription), methods (concrete network implementations), and extensions for discovery and identity, with SDKs in TypeScript, Python, Rust, Go and Ruby, and it has been proposed to the IETF. The specs are public at github.com/tempoxyz/mpp-specs. None of that quality changes the arithmetic for a five-person API company: every additional standard is another integration, another test surface, another thing to keep running at 3am.

And there is a second cost that's easy to miss. When MPP payments run through Stripe, they land in the business's existing Stripe balance, in its default currency, on its normal payout schedule, with the usual machinery applied. That's convenient — and it means the "machine-native" payment inherits the same custody and timing model as a card payment. The headers are new. The place your money waits is not.

Before you build: what the demand data says

On September 9, 2026, TRM Labs published "Who's Actually Paying? Measuring AI Agent Payments Onchain" — an analysis of roughly $52.7M across 198.9M x402 settlement transactions on Base, Solana and Polygon since May 2025.

After stripping out self-payments, flows concentrated in one or two payers, and sellers with fewer than ten distinct buyers, about half the settled value disappeared. Of the $25.62M that survived screening, TRM estimated the genuinely agentic share at 0.6% to 7.5% — between $150,000 and $1.92M. Their strict model required facilitator-broadcast payments averaging under a dollar, sustained across months, with public agent registration or payments to multiple sellers; the permissive model counted anything plausible.

TRM is the third independent group to reach a version of this conclusion, after Visa and Artemis in July and the Bitquery audit we analysed earlier this month. The honest read is not "agent payments are fake" — it's that the rail works and the demand is early. TRM's own conclusion is that what's missing is registration, counterparty reputation an agent can check, and monitoring built for volume rather than value.

One number in that report should change how you choose, though: $52.47M of $52.68M in settled value — 99.6% — was USDC, and nearly every seller in the catalogue names USDC as the asset it wants to receive. When the buyers have already voted that decisively on the asset, adding a rail that pays you in something else is a choice you should make deliberately, not by default.

What an API seller should actually do this week

The strategy that survives this much standards churn is boring and it works: make demand cheap to test.

You don't need to know whether MPP or x402 wins, whether sessions beat per-call metering, or which chain the agent economy settles on. You need to know whether anything is willing to pay you per request — and you need to find that out for close to zero engineering cost, so that the answer "not yet" costs you a week rather than a quarter.

That's exactly what Payzum does for x402, and it's worth being precise about the role, because the word "facilitator" gets thrown around loosely.

Payzum is the middleware — the proxy that sits in front of your existing API. Payzum is not the facilitator. Settlement runs through an external facilitator (today, Coinbase's). You configure; we publish, price, gate and proxy.

Concretely, and nothing more than the real capabilities:

• You keep your API exactly as it is. No SDK, no protocol to implement, no 402 handling in your codebase, no wallet library. Your endpoint doesn't learn a new language.
• You configure three things in a dashboard: your existing endpoint URL, your API key or bearer token, and a price.
• Payzum publishes an x402 URL, returns the 402 with the payment requirements, settles the payment via the external facilitator, then proxies the paid call to your real endpoint with your key and returns the response.
• The money is USDC on Base, and it goes to a wallet you control. Non-custodial: there is no Payzum balance, no payout schedule, no settlement delay. The payment is the settlement.
• Pricing: roughly the first 1,000 transactions a month are free, then about $0.001 per transaction plus gas.

Typical confirmation on Base is around two seconds. You can be serving agents the same day you configure it, which is the entire point: the experiment is cheap enough to run before the standards war resolves.

The honest boundary — what Payzum does not do

We'd rather write this than have you discover it on a call.

• Payzum does not support MPP today. Not on Tempo, not on XRPL, not through Stripe. Our agentic support is x402.
• Payzum does not do payment channels or session payments. The model is per-call: one request, one price, one settlement. Streaming and metered upto schemes are not something we offer.
• Payzum is not an x402 facilitator. We are the middleware in front of your API; settlement goes through an external facilitator. We'd like to be a facilitator in future. We are not one today.
• Payzum is crypto-only. We accept crypto and settle in crypto, with optional auto-conversion to USDC or USDT. We do not settle to bank accounts.
• We have no commercial relationship with Ripple, Stripe, Tempo, Circle or the Solana Foundation. We're writing about their releases because they matter to the same sellers we serve.

Supported networks for ordinary payment acceptance are Bitcoin, Ethereum, Solana, Polygon, Base, Arbitrum, Optimism, BNB Chain and Avalanche — so a business can take stablecoins on Solana today even though we don't implement Solana's payment channels.

How to become payable by agents, step by step

1. Pick one endpoint. The one with a clear unit of value — a lookup, a scrape, a generation, a score. Don't start with your whole surface. Start with the call you could price in one sentence.
2. Own the destination wallet. Create or connect the address where USDC on Base should land. That address is the account; everything downstream inherits its custody model. Turn on 2FA.
3. Configure the proxy. In the Payzum dashboard: endpoint URL, your API key or bearer, and a price per call. Payzum publishes the x402 URL.
4. Test it like an agent would. Hit the published URL, get the 402, pay, retry, confirm the proxied response matches your origin. The integration playground and signed webhooks let you wire the result into whatever you already run.
5. Publish and measure. List the URL where agents look, then watch two numbers for a month: distinct payers, and revenue per distinct payer. Those two tell you whether to invest in rails — and if they move, you'll have real data to bring to the MPP-versus-x402 decision instead of a roadmap guess.

Who this is for, concretely

The sellers for whom this stops being theoretical:

• A data or scraping API whose human customers sign up, burn a free tier and churn. Per-call agent revenue has no signup, no card, no churn event — the agent either pays for the call or doesn't get it. We walked through the economics in x402 vs API-key billing.
• An MCP server that is already being called by assistants and earning nothing. Charging per tool call is the same configuration problem as charging per API call — see monetising an MCP server with x402.
• A model or inference endpoint where a session-based rail sounds attractive until you notice it would pay you in a volatile asset. Per-call USDC is less elegant and far easier to put in a P&L.
• A niche B2B API — freight rates, legal citations, chemical properties — where the addressable buyer was always small in humans and might be large in agents. The cost of finding out should be an afternoon.

MPP vs x402 vs Payzum — what a seller is actually choosing

Common objections

"Shouldn't I wait for one standard to win?"

Waiting is a defensible position for a rebuild. It's an expensive position for an experiment. The reason to act now isn't that x402 will win — it might not — it's that the cost of being payable over x402 is a dashboard configuration, so the "wait" argument is answering a question nobody asked you to fund. If MPP becomes the standard your buyers speak, you will have lost an afternoon and gained a month of real demand data.

"The volume numbers say there's no demand."

Largely true today, and we said so above: TRM put the genuinely agentic share of screened value between 0.6% and 7.5%. But the sellers who were live during the quiet period are the ones with data, catalogue presence and a working payment path when demand arrives. The asymmetry matters: being early costs an afternoon, being late costs the first cohort of agent buyers who found someone else.

"Isn't crypto revenue an accounting problem?"

It's a real question, and it's getting less awkward rather than more — FASB's proposed guidance on which stablecoin holdings count as cash equivalents is working through its comment process, which we covered in stablecoins as cash equivalents. Practically: USDC on Base, into an address you control, with an audit log of every event, is easier to reconcile than most processor statements. This isn't accounting advice — take the specifics to your accountant.