x402 vs MPP: Which Machine Payment Protocol Fits?.

TL;DR: x402 and the Machine Payments Protocol (MPP) are the same four-step HTTP 402 exchange on different rails. x402 is stablecoin-first (USDC on Base and other chains) with an optional facilitator for verification and settlement. MPP is payment-method agnostic (stablecoins, cards through Stripe, custom methods), formalizes 402 with a Payment authentication scheme proposed to the IETF, and is backwards-compatible with x402. Choose by how your buyers pay and how your finance team wants receipts, not by which one is newer.

Part 3 of 5 in the Field Notes series When Agents Pay. Previously: how AI agents pay over HTTP 402 and should you charge AI crawlers. Next: how to charge for MCP tools.

What is x402?

x402 is the protocol that made HTTP 402 practical for agents. It was created by the x402 Foundation, with facilitator infrastructure operated by Coinbase, and it is the one you will meet first because it shipped first and because Cloudflare’s Agents SDK has, in its own words, “first-class x402 integration.”

The flow, from Cloudflare’s x402 documentation:

1. A client requests a resource.
2. The server returns 402 Payment Required with a PAYMENT-REQUIRED header describing the price, the asset, and the network.
3. The client constructs a signed payment payload and retries with a PAYMENT-SIGNATURE header.
4. The server verifies the payment, usually by handing the payload to a facilitator, and serves the resource with a PAYMENT-RESPONSE header.

Payment is USDC (an ERC-20 token on EVM chains) across Base, Ethereum, Polygon, Optimism, Arbitrum, Avalanche, Solana, Aptos, Stellar, and Sui. The facilitator is “an optional but recommended third-party service that abstracts blockchain interaction”: it checks that the payload is valid and submits the transaction on-chain, and it never holds funds. Cloudflare’s SDK ships x402-hono middleware for Worker routes, paidTool for MCP servers, withX402Client for MCP clients, and a @x402/fetch wrapper that pays automatically. Testing runs on base-sepolia with faucet USDC.

What x402 does well: it is small, it is live, and a wallet-holding agent can pay you in seconds with no account. What it leaves out by design: cards, fiat, and the receipts your bookkeeper recognizes.

What is MPP?

The Machine Payments Protocol was co-authored by Tempo and Stripe and published as an open standard in March 2026 at mpp.dev. Where x402 defined headers of its own, MPP standardizes 402 through HTTP’s existing authentication machinery: a formal Payment scheme, proposed to the IETF, carried in WWW-Authenticate: Payment on the challenge and Authorization: Payment on the credential. mpp.dev calls the shape a Challenge-Credential model, and a Payment-Receipt header returns the receipt.

The defining property is that MPP is payment-method agnostic. The protocol lists Tempo stablecoins, Stripe (cards and Shared Payment Tokens), Lightning, and several EVM and non-EVM chains, and lets anyone implement a custom method. Stripe’s announcement puts it plainly: agents can pay with “stablecoins as well as fiat with cards and buy now, pay later payment methods via Shared Payment Tokens (SPTs).”

On Cloudflare, per the MPP accept-payments docs, a Worker route or an MCP tool accepts MPP through the mppx middleware (Mppx.create(), then mppx.charge() with an amount, currency, description, and recipient), with payment methods such as tempo.charge() plugged in. A paid retry reaches your handler; an MCP tool returns its result plus an MPP receipt in the response _meta.

How do they differ, side by side?

Are they compatible?

In the direction that matters for a seller, yes. Cloudflare’s MPP page states that “MPP clients can consume existing x402 services without changes to those services.” An x402 endpoint you stand up today keeps working as MPP-capable agents arrive. The reverse is not promised: an x402-only client cannot pay an MPP-only endpoint that offers no stablecoin method.

That asymmetry is the practical hinge of the decision.

Which should you build on?

Three heuristics, in the order we apply them with clients.

Who is paying you, and what do they hold? If your buyers are agents operating with crypto wallets (developer tools, data APIs, anything in the agent-infrastructure market), x402 meets them where they are. If your buyers are agents acting for ordinary businesses, whose budgets are cards and bank accounts, MPP is the one that can take the payment.

What does your finance team need at month end? Stablecoin settlement is fast and cheap and produces on-chain records. Card settlement through Stripe produces the ledger, receipts, and dispute handling your accountant already understands. Choose the rail whose paperwork you can live with.

How sure are you? If the honest answer is “not very,” serve x402 today, because MPP clients can pay it, and keep the interface open so an MPP method can be added without redesign. Do not build both on day one for a market that has not shown up yet. This is the sequencing advice at the heart of our agentic commerce work, and it is why we sometimes recommend building neither this quarter.

What do both protocols leave to you?

Everything that actually goes wrong. Neither x402 nor MPP will stop you from:

• Double-charging when a client retries after a timeout. Fulfillment must be idempotent: the same payment credential returns the same result once, and never bills twice.
• Accepting a replayed credential. Verify every payment server-side, every time. Never trust a client’s claim that it paid.
• Leaking the dataset through a paid lookup that returns more than it should. Scope the response to the price.
• Mispricing. A price that needs a human approval loop is too high for a machine buyer; a price below your marginal cost is a subsidy. Part 4 works through pricing for MCP tools specifically.
• Losing the receipt. Store the receipt with the fulfillment record. It is your evidence when a buyer disputes.

The protocol is the easy part. The receipts, the idempotency keys, and the access scoping are the product.

The question isn’t x402 or MPP. It’s whether the machine that wants to pay you can, and whether you can prove afterward that it did.

Deciding which rail to build on?

Bold Crow AI designs machine-payment flows on open standards (HTTP 402, x402, MPP) with the verification, idempotency, and receipts built in, and gives straight “don’t build this yet” guidance where the economics don’t clear. See agentic commerce for how an engagement works.

Contact Bold Crow AI to talk through who would pay you, and how.