--- title: "What is MPP? The Machine Payments Protocol explained" description: "MPP (Machine Payments Protocol) is the Stripe- and Tempo-authored \"Payment\" HTTP authentication scheme on the IETF standards track. It standardises HTTP 402 so agents can discover and settle payments in-band. How it works, how it differs from x402, and how to make a paid endpoint MPP-ready." last_updated: 2026-06-09 canonical_url: https://agent-ready.dev/what-is-mpp --- # What is MPP? > The Machine Payments Protocol — Stripe and Tempo's `Payment` HTTP authentication scheme that lets agents discover and settle payments in a single HTTP 402 round-trip. ## 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 Tempo** and submitted to the IETF as the "Payment" HTTP authentication scheme ([paymentauth.org](https://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](https://agent-ready.dev/x402-checker) 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](https://agent-ready.dev/acp-vs-ucp-vs-ap2-vs-x402). ## 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](https://agent-ready.dev/x402-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](https://agent-ready.dev/agent-readability-score). ## 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. --- Read the full guide on the web: Score your site for agents: ## Sitemap See the full [sitemap](https://agent-ready.dev/sitemap.md) for all pages on agent-ready.dev.