MPP

The protocol describes itself as the open standard for machine-to-machine payments via HTTP 402. A payment processor's own documentation puts the same thing from the seller's side: an open protocol that lets agents pay for APIs and services programmatically, with no checkout interface. The server returns 402 and payment details, the agent authorizes and retries, and the resource comes back with a receipt. It is co-authored, and Stripe is one of the two authors. The other is Tempo.

The challenge is a WWW-Authenticate header carrying the Payment scheme and its parameters: the challenge id, the realm it protects, the payment method, the payment intent, and an encoded request holding the details. The specification requires the server to bind that id to the terms it issued, through stored state or a stateless cryptographic check. A client therefore cannot present an identifier back against terms it has altered.

The reply is a credential in the Authorization header under that same Payment scheme: an encoded object echoing the challenge back, naming the payer in a source field and carrying method-specific proof in a payload. The server matches the echoed challenge.id to an outstanding challenge, checks that it has not expired, and applies the payment method's own checks to the proof. It refuses a replay: a credential is good for a single request. An endpoint already using Authorization for its own authentication may take the credential in Payment-Authorization instead.

Three payment intents cover the commercial shapes: a charge for a one-time payment, a session for metered pay-as-you-go, and a subscription for access that renews on a schedule. On success the server returns a payment receipt in a Payment-Receipt header, which the specification forbids on an error response. Payment methods are pluggable rather than fixed: cards and stablecoins both ride the same challenge and credential shape.

Its core is published as an Internet-Draft, The 'Payment' HTTP Authentication Scheme, defining the Payment scheme carried in those two headers. That draft is an individual submission: it states on its face that it has no formal standing in the IETF standards process, and it carries an expiry date. Its maintainers describe anchoring the core at the IETF as what keeps any single company from controlling it. Each payment method is defined and maintained by the rail behind it, and adding one needs no approval.

For a directory of payable endpoints the practical consequence is that two rails run side by side. An endpoint answers on one of them, and a client speaking the other cannot pay it. Any list covering both has to record which rail each endpoint speaks. That is why x402 and MPP are stored as distinct values here, rather than merged into one idea of a payable endpoint.