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 all US states except New York, with access in more than 30 other countries on request; fiat payments run over Stripe’s card rails through Shared Payment Tokens, which Stripe lists as available to businesses in all US states and in a set of supported countries outside the US. 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 late 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 three (Solana, Stripe, Tempo; the Solana profile is authored by the Solana Foundation), 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 written as an Internet-Draft of intended status Informational, with no working group, and, like the discovery draft, it has no record in the IETF Datatracker as of 31 October 2026: it is published on paymentauth.org only. 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. Unlike the core draft, it does not appear in the IETF Datatracker as of 31 October 2026; the paymentauth.org copy is regenerated as the drafts change (the current one is dated 26 October 2026 and shows an expiry of 29 April 2027), so read its dates as an editor’s copy rather than an IETF submission record. 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.