MPP (Machine Payments Protocol) is an open standard for programmatic payments inside HTTP requests. Co-authored by Stripe and Tempo and submitted to the IETF as the "Payment" HTTP authentication scheme (draft-ryan-httpauth-payment), it standardises the 402 Payment Required status so a client — an agent, app, or service — can discover what a resource costs and settle it within the same request cycle, without API keys or a signup flow. It is payment-method agnostic: the same envelope carries Stripe, card, Tempo and other stablecoin, Lightning, Solana, or Stellar settlement.

How does the MPP payment flow work?

Three steps. (1) Challenge: the server answers an unpaid request with 402 Payment Required and a WWW-Authenticate: Payment header describing the payment options. (2) Credential: the client pays and retries the request with an Authorization: Payment header carrying proof of payment. (3) Receipt: the server verifies, returns the resource, and confirms with a Payment-Receipt header. The whole handshake happens in-band over standard HTTP semantics.

How is MPP different from x402?

Both collapse payment discovery into the 402 response, but the wire format differs. x402 (originally from Coinbase) puts its terms in the 402's JSON body — an x402Version field plus an accepts array — and is stablecoin-native. MPP puts the challenge in a WWW-Authenticate: Payment header (auth-params: id, method, intent, request, optional digest and realm), reuses the standard HTTP authentication framework, is on the IETF standards track, and is settlement-agnostic. They answer the same publisher question — 'is my paid endpoint correctly advertising machine-payment terms?' — so a single endpoint can advertise both.

What's in an MPP Payment challenge?

The WWW-Authenticate: Payment header carries auth-params: id (a challenge identifier), method (the payment method, e.g. "tempo", "stripe", "card", "lightning"), intent ("charge", "session", or "subscription"), request (a method-specific payload, usually JSON), and optionally digest (an RFC 9530 body binding) and realm (a human-readable scope). At minimum a well-formed challenge needs method and intent so a client knows how and what it is being asked to pay.

What is MPP? The Machine Payments Protocol explained

What is MPP?

MPP (the Machine Payments Protocol) is an open standard for programmatic payments inside HTTP requests. It standardises 402 Payment Required so a client — an agent, an app, a service — can discover what a resource costs and pay for it within the same request cycle, with no API key and no signup flow. Human checkout is built around rich visual flows; MPP strips that away for software callers.

It is co-authored by Stripe and Tempoand submitted to the IETF as the “Payment” HTTP authentication scheme (paymentauth.org). The core is payment-method agnostic: the same envelope carries Stripe, card, Tempo and other stablecoins, Lightning, Solana, or Stellar settlement, each defined as a pluggable method.

The 402 handshake: challenge, credential, receipt

MPP rides standard HTTP authentication. The flow is three steps:

Challenge. The server answers an unpaid request with 402 and a WWW-Authenticate: Payment header describing the payment options.
Credential. The client pays and retries with an Authorization: Payment header carrying proof of payment.
Receipt. The server verifies, returns the resource, and confirms with a Payment-Receipt header.

The challenge itself is a set of auth-params: id, method (e.g. tempo, stripe), intent (charge, session, or subscription), a method-specific request payload, and optionally digest and realm.

MPP vs x402: same question, different envelope

MPP and x402 both collapse payment discovery into the 402 response, and both answer the same publisher question — is my paid endpoint correctly advertising machine-payment terms? The difference is the wire format.

x402(originally from Coinbase) puts its terms in the 402’s JSON body— an x402Version field and an accepts array — and is stablecoin-native.
MPP puts the challenge in a WWW-Authenticate: Payment header, reuses the standard HTTP authentication framework, sits on the IETF standards track, and is settlement-agnostic (Stripe-backed or crypto).

They’re not mutually exclusive: a single endpoint can advertise both, and a thorough scan reports on each. For the wider machine-commerce landscape — x402, MPP, ACP, and Google AP2 — see the payments-protocol comparison.

How do agents discover what an endpoint costs?

Two ways. In-band, the 402 challenge tells a client the price the moment it hits a paid resource — no pre-flight needed, which is the elegance MPP shares with x402. Out-of-band, MPP’s discovery extension lets a server advertise payment terms in an OpenAPI document (typically at /openapi.json) so agents can learn endpoint costs before making a request. A hosted payments directory catalogues MPP-compatible services for agents to browse.

How do I make a paid endpoint MPP-ready?

Four moves:

Answer unpaid requests with 402. Return 402 Payment Required rather than a generic 401/403.
Emit a Payment challenge. Include WWW-Authenticate: Payment with at least a method and intent, plus a request payload the client can act on.
Verify and receipt. Check the Authorization: Payment credential on the retry and return a Payment-Receipt.
Advertise pricing (optional). Surface per-endpoint costs in an OpenAPI discovery document so agents can budget before they call.

Agent Ready validates exactly this. Paste a paid URL into the payment-endpoint checker and checks C18 (Payment challenge present) and C19 (challenge params) confirm the 402 carries a well-formed WWW-Authenticate: Payment challenge — alongside the x402 checks, since the same probe answers both. To see where your site stands across every agent-readiness signal, run a full agent-readability scan.

Frequently asked questions

What is MPP?: MPP (Machine Payments Protocol) is an open standard for programmatic payments inside HTTP requests. Co-authored by Stripe and Tempo and submitted to the IETF as the "Payment" HTTP authentication scheme (draft-ryan-httpauth-payment), it standardises the 402 Payment Required status so a client — an agent, app, or service — can discover what a resource costs and settle it within the same request cycle, without API keys or a signup flow. It is payment-method agnostic: the same envelope carries Stripe, card, Tempo and other stablecoin, Lightning, Solana, or Stellar settlement.
How does the MPP payment flow work?: Three steps. (1) Challenge: the server answers an unpaid request with 402 Payment Required and a WWW-Authenticate: Payment header describing the payment options. (2) Credential: the client pays and retries the request with an Authorization: Payment header carrying proof of payment. (3) Receipt: the server verifies, returns the resource, and confirms with a Payment-Receipt header. The whole handshake happens in-band over standard HTTP semantics.
How is MPP different from x402?: Both collapse payment discovery into the 402 response, but the wire format differs. x402 (originally from Coinbase) puts its terms in the 402's JSON body — an x402Version field plus an accepts array — and is stablecoin-native. MPP puts the challenge in a WWW-Authenticate: Payment header (auth-params: id, method, intent, request, optional digest and realm), reuses the standard HTTP authentication framework, is on the IETF standards track, and is settlement-agnostic. They answer the same publisher question — 'is my paid endpoint correctly advertising machine-payment terms?' — so a single endpoint can advertise both.
What's in an MPP Payment challenge?: The WWW-Authenticate: Payment header carries auth-params: id (a challenge identifier), method (the payment method, e.g. "tempo", "stripe", "card", "lightning"), intent ("charge", "session", or "subscription"), request (a method-specific payload, usually JSON), and optionally digest (an RFC 9530 body binding) and realm (a human-readable scope). At minimum a well-formed challenge needs method and intent so a client knows how and what it is being asked to pay.
How do agents discover what an endpoint costs?: Two ways. In-band, the 402 challenge itself tells a client the price the moment it hits a paid resource — no pre-flight needed. Out-of-band, MPP's discovery extension lets a server advertise payment terms in an OpenAPI document (typically generated and served at /openapi.json) so agents can learn endpoint costs before making any request. There is also a hosted payments directory cataloguing MPP-compatible services.
How do I make a paid endpoint MPP-ready?: Respond to unpaid requests with 402 Payment Required and a WWW-Authenticate: Payment challenge that names a method and an intent and includes a request payload the client can act on. Verify the Authorization: Payment credential on the retry and return a Payment-Receipt. Optionally advertise per-endpoint pricing in an OpenAPI discovery document. Agent Ready validates exactly this: paste a paid URL and checks C18 and C19 confirm the challenge is present and well-formed.