Machine Payments Protocol (MPP)

The Machine Payments Protocol (MPP) is the specification for the status code everybody has joked about for thirty years. 402 Payment Required was reserved in the original HTTP/1.1 work and left undefined ever since, and MPP fills it in as an HTTP authentication scheme — the same shape as Basic or Bearer, with money in it. The core document is The “Payment” HTTP Authentication Scheme, published 18 March 2026 by Brendan Ryan, Jake Moxey and Tom Meagher of Tempo Labs with Jeff Weinstein and Steve Kaliski of Stripe, alongside the launch of the Tempo chain that Stripe and Paradigm incubated. The specifications are CC0, the tooling is Apache-2.0 or MIT, and the whole set renders at paymentauth.org out of one repository.

• Three headers and one round trip - The server answers a request for a paid resource with 402 and a Challenge in WWW-Authenticate: Payment, carrying id, realm, method, intent and a base64url-encoded JSON request, with an optional RFC 9530 digest binding it to the request body. The client pays, retries with a Credential in Authorization: Payment, and gets 200 plus an optional Payment-Receipt. No account, no signup form, no pricing page to read.
• The status codes carry the distinction that matters - 402 means the payment barrier is still up, 200 means paid and served, and 403 means the payment verified but policy denies access anyway. Failures come back as RFC 9457 problem details with a defined code list — verification-failed, payment-expired, invalid-challenge, malformed-credential — rather than as prose in a header.
• The core is method-agnostic; the money is in the companions - Twenty-two documents ship: one core, two intent base specs, eighteen payment-method drafts and two extensions. charge, session and subscription are the intents; card, EVM, Solana, Stellar, Hedera, Lightning, USDC, NEAR intents, Stripe and Tempo are the methods. A server can offer several intents at once as multiple WWW-Authenticate headers and let the client choose.
• It reaches into the agent stack directly - One extension is a discovery draft, the other binds the scheme to JSON-RPC and MCP, which is what makes this a tool-call monetization protocol and not only a web one. Paying per tool call is the use case being designed for, not a side effect.
• Proposed to the IETF, not adopted by it - draft-ryan-httpauth-payment-01 is an individual submission with no working group and no stream, and the datatracker page says plainly that it is not endorsed by the IETF. The IANA registries for payment methods and payment intents are requested in the draft, not established. Read the “open standard” claim as published openly under CC0, which is true, rather than standardized, which is not yet.
• The governance is two companies that also sell the rails - There is no foundation, no charter and no participant roster — a CONTRIBUTING file, a style guide and commit access at Tempo and Stripe. Five of the eighteen method drafts are Tempo’s and Stripe’s own rails, and Tempo is the only method with all three intents specified. That is not disqualifying at this stage, and it is exactly the thing to watch: a payment scheme is only neutral if methods that compete with the editors’ can land on the same terms.
• The published set has holes worth knowing about - session is described as a first-class intent but only exists as five per-method drafts; there is no base session intent specification the way there is for charge and subscription. Everything except the NEAR intents draft is still at -00.
• No schema artifact - The object model for challenges, credentials and receipts is normative and entirely prose. There is no JSON Schema in the repository, so anything that validates an MPP payload today was hand-transcribed from a document.

The reason this belongs in the catalog is not the blockchain launch it arrived with. It is that HTTP gained a defined answer to “this costs money” that a machine can act on without a human in the loop, and that answer is expressed in the plumbing every API already speaks — status codes, an auth scheme, problem details, an IANA registry — rather than in a new protocol nobody’s gateway understands. x402 is doing the same thing from a different starting point — a Linux Foundation project with the card networks in it, rather than an individual IETF draft — and Stripe is on both, down to Steve Kaliski co-authoring this draft while sitting on the x402 technical steering committee. This layer has two candidates and no winner. For an API provider the practical read is that per-call pricing is becoming a property of the interface rather than of the signup flow, and the providers who will be ready for it are the ones whose pricing, rate limits and scopes are already machine-readable — which, measured across this catalog, is very few of them.