MPP — the Machine Payments Protocol — is an open standard for machine-to-machine payments, co-authored by Tempo Labs and Stripe, that gives the long-reserved HTTP 402 Payment Required status code an actual authentication scheme. Cloudflare’s Agents documentation started documenting native support for it on 5 August 2026, alongside the more familiar x402 protocol — which means a second HTTP 402 payment scheme is now live on infrastructure merchants and their MCP servers already run on.

How the payment flow works

MPP’s core is a plain HTTP challenge-response exchange, specified in an IETF draft:

  1. A client requests a paid resource.
  2. The server replies 402 Payment Required with a WWW-Authenticate: Payment header — a challenge naming the payment method, intent (charge, session or subscription) and method-specific request data.
  3. The client fulfills the payment off-band (a signed transaction, a card charge, an invoice).
  4. The client retries with an Authorization: Payment credential proving payment.
  5. The server verifies it and returns the resource with a Payment-Receipt header.

The protocol is deliberately payment-method agnostic: the same 402/challenge/credential shape can carry a stablecoin transfer, a Stripe charge, or a card payment, with method-specific details registered separately (Tempo, Stripe, ACH, Solana, Hedera, Near, EVM, Lightning are already defined in the specs directory).

It already speaks MCP

MPP defines a JSON-RPC and MCP transport extension that maps the same challenge/credential/receipt exchange onto tools/call and resources/read responses: a payment-gated MCP tool returns JSON-RPC error -32042 with the challenge in error.data, the client resends the call with the credential in _meta["org.paymentauth/credential"], and a successful result carries the receipt in _meta["org.paymentauth/receipt"]. For any merchant running an MCP server — the surface AgentReady’s Pillar 4 already checks — this is a standardized way to meter or charge individual tool calls without inventing a bespoke billing header.

Compatible with x402, not a replacement

Cloudflare’s docs state plainly that MPP is “backwards-compatible with x402” and that MPP clients can consume existing x402 services unchanged. That matters because x402 already has real distribution — we covered it in July — and Cloudflare is now shipping build guides for both: “Charge for a Worker route or an MCP tool” and “Pay from the Agents SDK” exist for x402 and, as of this month, for MPP too.

The funding and identity side: Cloudflare Wallets

The same week, Cloudflare separately announced Cloudflare Wallets: Account Wallets held by humans that delegate spend to per-agent Virtual Wallets, each capped by an allowance, an allow-list and a maximum transaction size set by the account owner. A cloudflare.pay handle gives an agent an optional, human-readable identity tied to the account it acts for. Wallets fund the payment; MPP and x402 are the protocols that move it — distinct layers of the same stack.

What this means for a merchant

If your store already exposes an MCP server or API endpoints behind Cloudflare Workers, MPP is a second protocol — not a competing one — that a paying agent may now try before falling back to x402 or a conventional checkout. The practical items to track: whether your Workers or payment integrations advertise experimental.payment capabilities agents can discover ahead of a call, and whether any metered or paid tool/API on your stack returns a plain, undocumented 402 today rather than a challenge an agent can actually fulfill. Both rails only help if an agent reaches your checkout or paid API in the first place — the protocol choice is downstream of being reachable at all.

Sources

A protocol for an agent to pay you is only useful once it can find, parse and reach what it’s paying for — the transaction step this audit exists to check.