MPP Explained: The Machine Payments Protocol

The Machine Payments Protocol (MPP) is an open standard for letting an AI agent pay for something on its own, without a person entering card details or clicking a checkout button. It is built for the kinds of purchases agents actually make: paying for an API call, renting compute, buying access to a piece of data, or settling a small recurring charge. MPP is a settlement-layer protocol, not a consumer checkout standard.

Who is behind it

MPP was co-authored by Stripe and Tempo and launched on 18 March 2026. It is published as an open standard, with the specification at mpp.dev. Tempo is the blockchain Stripe pairs with MPP for stablecoin settlement, and Stripe provides the merchant side: businesses already on Stripe can accept payments over MPP using the same PaymentIntents API they use for human payments.

The problem MPP sets out to solve is that today’s financial tools were built for people. To buy something, an agent often has to create an account, read a pricing page, choose a plan, enter payment details, and set up billing, steps that usually need a human. MPP replaces that with a programmatic handshake an agent can complete by itself.

What MPP actually does

MPP standardizes the payment conversation between an agent and a service. The flow is deliberately simple: an agent requests a resource from a service, an API, a Model Context Protocol (MCP) endpoint, or any HTTP-addressable endpoint; the service responds with a payment request; the agent authorizes the payment; and the resource is delivered to the agent.

For a business accepting MPP through Stripe, these payments appear in the Stripe API and Dashboard like any other transaction. Funds settle into the business’s existing balance, in its default currency, on its normal payout schedule, and the usual Stripe machinery applies, including tax calculation, fraud protection, reporting, accounting integrations, and refunds. Payment can be made in stablecoins as well as cards, wallets, and the other methods that Stripe’s Shared Payment Tokens carry. Stripe’s machine-payments documentation sets out the two halves plainly: crypto payments settle on-chain through a deposit address on Tempo or Solana, available to businesses in more than 30 countries and in all US states except New York; fiat payments run over Stripe’s card rails through Shared Payment Tokens and are open to developers with a US legal entity. Individual charges can be as small as 0.01 USDC, and Stripe applies a minimum charge of 0.50 USD or equivalent to card payments made through a Shared Payment Token. Stripe also documents accepting x402 alongside MPP, on Base.

How MPP is specified, and where it stands as a standard

This is worth being precise about, because MPP is marketed alongside a link labelled “IETF Specs” and it is easy to read that as meaning MPP is already an internet standard. It is not, yet.

The core of MPP is not a bespoke API. It is defined as an HTTP authentication scheme, an extension of the ordinary HTTP authentication mechanism that uses the “402 Payment Required” status code. A client requests a resource; the server answers 402 with a WWW-Authenticate: Payment challenge describing what is owed; the client fulfills the challenge and retries with an Authorization: Payment credential; the server verifies it and returns the resource together with a receipt.

That core was submitted to the IETF on 18 March 2026 as draft-ryan-httpauth-payment, authored by Brendan Ryan, Jake Moxey, and Tom Meagher of Tempo Labs and Jeff Weinstein and Steve Kaliski of Stripe. The draft header states an intended status of Standards Track. The status to hold onto is what the IETF Datatracker itself records: the document is an individual Internet-Draft with no RFC stream, no responsible area director, no working group, and, in the Datatracker’s own wording, no formal standing in the IETF standards process. Anyone may submit an Internet-Draft. So the honest characterization is that MPP’s authors have started down the IETF path in the normal way, not that MPP is an IETF standard.

The same work now also runs under a second, shorter document name, draft-httpauth-payment, with the author prefix dropped: -00 was posted on 19 June 2026 and -01 on 9 September 2026, by the same five authors and under the same title. It expires 13 March 2027, which supersedes the 19 September 2026 expiry the original name carried. Do not read the shortened name as adoption. Draft filenames usually lose their author prefix when a working group takes a document over, but that has not happened here: the Datatracker still lists draft-httpauth-payment as an Active Internet-Draft (individual), with RFC stream (None), intended RFC status (None), an IESG state of I-D Exists, and no responsible area director. It records no formal replaces relationship between the two names either, so on paper the two documents simply coexist. The practical read is that the core specification is being kept alive and current in the IETF’s document system while remaining outside the IETF’s process.

The specification is deliberately modular, which matters if you are building against it: a payment-method-agnostic core (HTTP 402 semantics, headers, IANA registries), intents that describe abstract payment patterns, methods that implement those patterns on a concrete network, and extensions for optional additions such as discovery and identity. The repository README gives the intents as charge, authorize, and subscription and the methods as Tempo, Stripe, and ACH, but read that as illustration rather than inventory: as of October 2026 the published drafts cover a charge intent with eleven methods (card, EVM, Hedera, Lightning, NearIntents, Solana, Stellar, Stripe, Tempo, USDC, XRPL), a session intent with six, and a subscription intent with Stripe and Tempo, while no ACH draft is published. The core also establishes two IANA registries, for payment methods and payment intents, and three header fields: Accept-Payment, Payment-Authorization, and Payment-Receipt. The design principles state that the protocol is network- and currency-agnostic and intended to cover bank rails and cards as well as stablecoins. The specifications are released into the public domain under CC0 1.0, with the surrounding tooling under Apache 2.0 or MIT.

The drafts are now collected on a dedicated site, paymentauth.org, and the family is growing. A second document, draft-payment-discovery, “Service Discovery for HTTP Payment Authentication,” by Tempo Labs and Merit Systems, lets a service publish an OpenAPI document at /openapi.json annotated with two extensions, x-service-info and x-payment-info, so an agent can find priced endpoints and their input schemas before making a request. It reached revision -01 on 1 October 2026, adding output-schema guidance so an agent can evaluate a seller-declared response shape before paying, with careful language that such a schema is “seller-declared discovery metadata” and “MUST NOT be described as a runtime observation.” The draft is careful to keep discovery advisory throughout: “The runtime 402 challenge remains authoritative for all payment parameters,” and clients “MUST NOT rely on discovery metadata for security decisions.”

MPP over MCP: the settlement layer reaches the discovery layer

The most consequential document in the family for agentic commerce arrived on 1 October 2026: draft-payment-transport-mcp-00, “Payment Authentication Scheme: JSON-RPC & MCP Transport,” by two Tempo Labs authors. It defines how the Payment scheme operates over JSON-RPC 2.0, and therefore over MCP, which uses JSON-RPC as its message format. A server signals that payment is required by returning JSON-RPC error code -32042 carrying one or more challenges, with httpStatus: 402 included for transports that bridge to HTTP. The client then retries with a credential in _meta under the key org.paymentauth/credential, and the server returns a receipt in _meta under org.paymentauth/receipt. The operations named as payable are exactly the ones a merchant server would expose: tools/call, resources/read, and prompts/get.

Why this matters more than its draft status suggests. Everywhere else on this site, the settlement layer and the discovery layer are described as adjacent: MCP is how an agent finds a merchant’s tools, and x402 or MPP is how software pays software. This draft joins them. A merchant’s MCP server could put a price on an individual tool call, which is a different commercial shape from either agentic checkout or flat-rate API access.

Two things keep it in proportion. It is an individual Internet-Draft of intended status Informational, with no working group, like the rest of the family. And it still cites MCP revision 2025-11-25 and advertises capabilities under experimental, two revisions behind the current 2026-07-28, which is a fair measure of how early the work is. See MCP explained for what changed in between.

Two details in that second draft are worth noticing. Its authors are Brendan Ryan and Jake Moxey of Tempo Labs together with Ryan Sproule and Sam Ragsdale of Merit Systems, so Stripe is not on it. And it carries an intended status of Informational, expiring 8 February 2027. Like the core draft, it is an individual submission with no working group behind it. The pattern to read is a spec family accumulating in the IETF’s document system without yet entering the IETF’s process.

Governance sits with the two co-authors. The specification repository names Tempo Labs and Stripe as the maintaining organizations. Unlike x402, which now sits under a Linux Foundation body, MPP has no neutral foundation, and the IETF submission is currently the only route toward multi-party stewardship.

What has changed since launch

MPP has iterated steadily rather than sitting still since the March release, and the running list on the MPP blog is the place to check before you build. Subscriptions for recurring access arrived in May 2026, followed by typed payment hooks in the core SDKs for logging, monitoring, and request context. In June, one SDK gained the ability to speak both generic EVM payments and x402 exact flows alongside MPP, so a single client can pay whichever protocol an endpoint supports, and the pay-as-you-go sessions experience was reworked. In July, mppx added hooks for agent runtimes: it installs a payment-aware global fetch, so existing HTTP tools and MCP transports can call paid endpoints without changing their request code, with published integration guides for Cloudflare Agents, the Vercel AI SDK, and the official TypeScript MCP SDK.

On 3 August 2026 the mppx SDK added support for relays. Note the layer: this was an SDK and ecosystem capability rather than a change to the specification. A relay is an external service that sits between an application and the settlement layer and handles two operations on the application’s behalf: validating that a payment credential is acceptable to the underlying rail, and broadcasting it to finalize payment and return what is needed to build a receipt. The practical effect is that a business can accept several payment methods through one interface and let the relay operator deal with each rail. The design point to note is how loose it is: MPP “does not require relays or require them to conform to a single interface,” and relay authors define their own API shape. That keeps the protocol small, and it means relay behavior is not something a merchant can assume from the specification.

Where it sits in the stack

MPP lives at the settlement layer, the part of the stack concerned with how value actually moves. Both MPP and x402 build on the same web mechanism, the long-dormant HTTP “402 Payment Required” status, so an agent can settle a charge inside a single request; the difference is sponsorship and rails, not the underlying method. x402 is the version contributed by Coinbase and now stewarded by the x402 Foundation under the Linux Foundation, which is stablecoin-focused in practice though network and token agnostic by design. The two are best understood as parallel machine-native options rather than a commerce protocol versus a payment one: both target agent-to-agent and micro-transaction use cases, and Stripe explicitly supports both MPP and x402. For a side-by-side, see x402 vs MPP.

It is just as important to be clear about what MPP is not. It is not a checkout protocol for the consumer shopping journey, that is the job of ACP and UCP. It is not a discovery layer, that is MCP. And it is not a payment-authorization and trust framework like AP2. MPP composes beneath or alongside those layers. For the full picture, see the protocol stack.

What is actually live

MPP is live infrastructure on Stripe, and the launch came with named businesses already using it rather than just intentions. Browserbase lets agents spin up headless browsers and pay per session. PostalForm helps agents pay to print and send physical mail. Prospect Butcher Co. lets agents order sandwiches for pickup or delivery in New York City. Agents can also contribute programmatically to Stripe Climate. Parallel Web Systems uses machine payments so agents can pay per API call for web access.

The honest caveat is the same one that applies across agentic commerce: this is early, and it sits in the machine-to-machine lane, not retail checkout. MPP makes agent-initiated payments for services real and easy to accept on Stripe, but the broad ecosystem of agents and services transacting over it is still forming.

What it means for you

If you sell APIs, compute, data, or other digital services, MPP is the standard that lets agents become paying customers without a human in the loop, and if you are already on Stripe, accepting it is a small lift. If you are a builder, treat MPP as one of two settlement options for machine-native payments, alongside x402, and choose per use case. And if you are mapping the landscape, file MPP under settlement, next to x402, not as another contender at the checkout layer.

FAQ

Who created MPP? Stripe and Tempo co-authored it, launched 18 March 2026, with the spec at mpp.dev and acceptance available through Stripe’s PaymentIntents API.

How is MPP different from x402? Both are machine-native settlement standards for software-to-software payments, and both build on the HTTP “402 Payment Required” status. x402 is Coinbase’s stablecoin-focused version; MPP is Stripe and Tempo’s, settling in stablecoins as well as the cards, wallets, and other methods Shared Payment Tokens carry. Stripe supports both.

Is MPP a checkout protocol like ACP or UCP? No. It is a settlement-layer protocol for agents paying for APIs, compute, and services. ACP and UCP handle the consumer shopping journey; MPP composes beneath or alongside them.

Is MPP an IETF standard? Not yet. The core was submitted to the IETF on 18 March 2026 as draft-ryan-httpauth-payment, by Tempo Labs and Stripe engineers, with an intended status of Standards Track. The IETF Datatracker records it as an individual Internet-Draft with no RFC stream, no working group, and no formal standing in the standards process. That original document has since expired and is archived; the live one is the shorter name, draft-httpauth-payment, whose -01 revision was posted on 9 September 2026 and expires 13 March 2027. The rename is not an adoption: the Datatracker records an individual submission with no working group and an IESG state of I-D Exists, and no formal replaces relationship between the two names.