x402 vs MPP, compared: which rail should an agent pay on?

An AI agent that needs data, compute or a paid tool call should not need an API key, a billing dashboard and a human to provision it. Two protocols now let the agent pay for the call inside the call itself: x402, led by Coinbase, and MPP — the Machine Payments Protocol from Stripe and Tempo, launched in March 2026. Both do the same basic job. They are not converging on the same design, and choosing between them is mostly a choice about rails, compliance and how often the agent pays.

#Same job, same starting point

Both protocols revive an old idea in HTTP, the web's request-and-response standard: the 402 Payment Required status code, reserved decades ago and almost never used. The flow is identical at the top level:

1. The agent requests a resource.
2. The server replies with a payment challenge instead of the resource.
3. The agent pays and retries with proof of payment.
4. The server verifies and returns the resource.

What differs is everything underneath that flow: what money moves, on which rails, who checks the payment, and who is responsible when something goes wrong. For the wider map of competing protocols, see agent payment protocols, explained and how AI agents pay each other.

#How x402 works

x402 is a family of on-chain payment schemes attached to HTTP 402. The server sends a PAYMENT-REQUIRED header describing the price; the agent signs a payment and retries with a PAYMENT-SIGNATURE header; a facilitator — a service that verifies the payment and settles it on-chain — completes the transfer.

• Money: stablecoins only, settled fully on-chain. USDC — Circle's dollar stablecoin — is the main asset. The protocol is chain-agnostic (independent of any one blockchain): Base, Polygon and Solana are live, and Circle's Facilitator Service settles x402 USDC on Arc, Base and Polygon PoS, as of October 2026.
• Governance: open-source, now stewarded by the x402 Foundation, a Linux Foundation-backed group launched in July 2026 with 40 members.
• Integration: open-source middleware for common web frameworks; a merchant can be live in minutes, or use a facilitator such as Coinbase or Circle instead of running settlement itself.
• Compliance: the merchant's problem. Fraud checks, tax, refunds and reporting are not part of the protocol.

In x402's default exact scheme, one request means one payment, and a signed authorization settles immediately.

#How MPP works

MPP generalizes the same challenge-and-retry pattern into a payment-method-agnostic framework. Its core, the Payment HTTP Authentication Scheme, is an IETF Internet-Draft — a working document submitted to the Internet Engineering Task Force, the body that standardizes internet protocols — co-authored by Tempo and Stripe. Challenge IDs are bound with HMAC, a keyed hash that makes a challenge tamper-evident and replay-resistant.

• Money: pluggable. Today that means USDC on Tempo, a blockchain built specifically for payments, plus Stripe rails — cards, wallets and buy-now-pay-later — through Shared Payment Tokens, which let an agent pay without exposing the underlying card credentials.
• Sessions: MPP's structural difference. Instead of settling every call on-chain, a session funds once and then aggregates many calls into that one funding event, using escrow and signed vouchers off-chain. Alchemy's comparison notes sessions make payments as small as $0.0001 per request practical, with no on-chain confirmation per request — the pattern high-frequency streaming and per-token billing need.
• Integration: MPP plugs into Stripe's PaymentIntents, so risk checks, tax, refunds and reporting come built in. The trade-off is setup: it is heavier than x402 unless the merchant already runs on Stripe.
• Standardization: idempotency (safe retries without double-charging), expiry, receipts and replay protection are defined in the protocol itself, rather than left to each implementation.

#Side by side

Sources: Alchemy protocol comparison, March 2026; WorkOS head-to-head, 2026; dev.to comparative analysis, October 2026.

#The volume numbers, honestly

The headline gap looks decisive and is mostly a measurement artefact. x402's 191.7M cumulative transactions as of October 11, 2026 count every on-chain payment across 12 chains. MPP's 46,198 cumulative events count something else: because one MPP session amortizes many calls into a single funding event, a busy MPP endpoint can serve thousands of paid calls while recording few events. The two units do not measure the same thing.

Discount x402 as well. An estimated 25–30% of its activity may be test or leaderboard noise, per the October 11, 2026 briefing cited above. And count is not value: XRPL's 13M+ x402 payments by October 10, 2026 were overwhelmingly micropayments for inference, data and API calls — real machine-to-machine use, at very small average size. That matches the wider pattern in agent payments in Q3 2026: lots of transactions, most of them tiny.

x402 owns today's on-chain agent volume. MPP owns the card-and-compliance on-ramp. Both are settlement plumbing.

#Which rail should an agent pay on?

Choose x402 first if the audience is crypto-native, the agent already holds stablecoins, and speed to production matters more than built-in compliance. It is the simplest path, there is no vendor lock-in, and it carries nearly all of today's live agent volume.

Choose MPP first if the buyers are mainstream or enterprise, the agent needs to pay with a card as well as a stablecoin, the workload is high-frequency enough to need sessions, or the merchant wants fraud, tax and refunds handled rather than built.

Run both if you can. The endpoint does not have to pick a winner. MPP's charge flow is backwards compatible with x402's exact flow, and a server can advertise both protocols and let the client use whichever it supports. The protocols are diverging in design — permissionless and chain-agnostic on one side, multi-rail and compliance-first on the other — while remaining interoperable at the point of payment.

#The missing layer: intent, checked before the money moves

That gap is now being built as a separate layer, starting with the card networks. On October 13, 2026, American Express published its Intent Intelligence Framework — the first card-network design that treats a customer's approved intent as a machine-checkable object, rather than a click at checkout. It is part of Amex's Agentic Commerce Experiences (ACE) Developer Kit, launched in April 2026.

It works in four steps:

1. Create intent. A Create Intent API records the customer's instructions and constraints — merchant, maximum budget, preferences. The customer authenticates and signs off on what was captured.
2. Establish proof. The system issues an Intent ID and a Proof of Intent Token carrying those constraints.
3. Scope the credential. The token is exchanged for a secure digital payment credential scoped to that intent. The agent never sees the customer's card number.
4. Check throughout. The Intent ID and token are then used at authorization, fraud and dispute stages, so a purchase that does not match what was approved can be stopped at authorization instead of argued about after settlement.

Amex says it is publishing the framework to help the industry settle on a common approach to intent, and it name-checked supporting the x402 Foundation's standards work in the release. The demand signal it cited: 66% of surveyed US consumers said they were likely to use agents to research prices and 61% for recommendations (Amex Trendex survey, cited October 2026).

The honest caveat, from an October 2026 dev.to analysis of the framework: proving that a purchase matches approved intent is not the same as judging whether the purchase itself is wise. Intent-as-a-token closes the authorization gap. The judgment gap — did the agent pick well, at a fair price, from the right merchant — is still open on every rail.

#The risks

#Key terms

x402

An open protocol that revives HTTP 402 so an agent can pay for a request with an on-chain stablecoin payment and retry, without accounts or API keys.

MPP (Machine Payments Protocol)

Stripe and Tempo's payment-method-agnostic HTTP payment framework, covering stablecoins, cards and sessions.

Facilitator

A service that verifies an agent's payment and settles it on-chain on the merchant's behalf.

Session

In MPP, a single funding event that covers many subsequent paid calls, settled in aggregate rather than one by one.

Shared Payment Token

A Stripe credential that lets an agent pay across merchants without exposing the underlying card details.

Intent

What a customer approved an agent to buy, including constraints such as merchant and maximum budget, recorded before the purchase.

Proof of Intent Token

Amex's token carrying a customer's approved constraints, used to scope the payment credential and check the purchase later.