Plain-English explainer

What is MPP?

The Machine Payments Protocol, explained: what it is, how one payment works, how it relates to x402, and where it is settling real money today.

MPP (Machine Payments Protocol) is an open, IETF-track standard that lets software pay for web services per request through HTTP's native authentication headers. A paid endpoint answers an unpaid request with status 402 Payment Required and a WWW-Authenticate: Payment challenge naming a price; the client responds with a signed stablecoin payment in an Authorization: Payment header; the server verifies it, settles it on-chain, and returns the result with a signed Payment-Receipt. No accounts, API keys, or subscriptions.

How one MPP payment works

The client requests a paid resource. The server answers 402 Payment Required with a WWW-Authenticate: Payment challenge - the price, the asset (a stablecoin such as USDC), the chain, and a one-time challenge id.
The client signs a payment authorization for exactly that amount with its own wallet key and retries the request with an Authorization: Payment header carrying the signed credential. The key never leaves the client.
The server verifies the credential against the challenge, settles the payment on-chain, and only then runs the request.
The response arrives with a signed Payment-Receipt header - a verifiable record that this exact payment bought this exact answer.

The whole exchange is two HTTP round trips, typically a couple of seconds. Because it rides the standard HTTP authentication mechanism (the same WWW-Authenticate / Authorization machinery defined in RFC 9110 that powers every login prompt on the web), payment becomes just another auth scheme - which is what makes it a natural candidate for the IETF standards track.

MPP vs x402

MPP and x402 are two dialects of the same idea: pay-per-request over HTTP 402, settled in stablecoins, with no accounts. They differ in which headers carry the handshake:

	x402	MPP
Payment terms ride in	`PAYMENT-REQUIRED` header (base64 JSON offer)	`WWW-Authenticate: Payment` challenge
Payment rides in	`X-PAYMENT` header	`Authorization: Payment` header
Proof of settlement	`PAYMENT-RESPONSE` header	Signed `Payment-Receipt` header
Origin	Coinbase (x402.org)	Tempo (paymentauth.org, IETF-track)

The two are not rivals in practice: a server can speak both from the same URL at the same price, letting the buyer's client pick its dialect. That is how Agent402 runs today - one paywall, two wire formats, one settlement path.

Is it real? Where MPP settles today

Every paid endpoint on Agent402.Tools is dual-stack: the same 402 carries an x402 offer and an MPP challenge, a stock mppx client works unmodified, and a real purchase settles over the native MPP wire every day as part of the service's paid canary - so "MPP works here" is continuously re-proven on mainnet, not demonstrated once. Other x402 sellers have begun advertising MPP as an alternate rail as well. The reference tooling lives in the tempoxyz/mpp repository, and the 'Payment' auth scheme is documented at paymentauth.org.

For the broader story - why machine payments exist, what "agents paying agents" means, and an interactive walk-through of one payment - see What is x402?. To accept either protocol on your own API, start at /sell.

FAQ

What is the Machine Payments Protocol (MPP)?

MPP is an open, IETF-track protocol that lets software pay for web services per request using HTTP's standard authentication mechanism. A paid endpoint answers an unpaid request with status 402 and a WWW-Authenticate: Payment challenge naming a price; the client answers with a signed stablecoin payment in an Authorization: Payment header; the server verifies it, settles on-chain, and returns the result with a signed Payment-Receipt header. No account, API key, or subscription is involved.

How is MPP different from x402?

They are two dialects of the same idea - pay-per-request over HTTP 402, settled in stablecoins. x402 (from Coinbase) carries payment terms in a PAYMENT-REQUIRED header and the payment in an X-PAYMENT header; MPP carries the same handshake through the web's standard auth headers (WWW-Authenticate / Authorization, the mechanism defined in RFC 9110), which makes it a natural fit for the IETF standards track. A server can speak both from the same URL at the same price, and dual-stack servers exist today.

Is MPP a finished standard?

It is IETF-track and in active development - the 'Payment' HTTP authentication scheme is documented at paymentauth.org with the reference implementation in the tempoxyz/mpp repository. Live services accept MPP payments on mainnet today, so the wire format is real and settling, but as with any draft-stage protocol, details can still evolve.

Where can I see MPP working right now?

Every paid endpoint on Agent402.Tools is dual-stack: the same 402 response carries both an x402 offer and a WWW-Authenticate: Payment challenge, a stock mppx client works unmodified, and settled responses return a signed Payment-Receipt. A real purchase settles over the native MPP wire daily as part of the service's paid canary, so the claim is continuously re-proven, not a demo that worked once.

How do I accept MPP payments on my own API?

If you already speak x402, a translation layer can add MPP without touching settlement: answer 402s with an additional WWW-Authenticate: Payment challenge derived from your existing offer, and re-encode inbound Authorization: Payment credentials into your existing verification path. Agent402's implementation of exactly that pattern is open source (AGPL) in its server repository, and the mppx tooling in tempoxyz/mpp provides the client and codec primitives.