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. The current version, -01, expires on 19 September 2026. 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 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 such as charge, authorize, and subscription, methods that implement those patterns on a concrete network such as Tempo, Stripe, or ACH, and extensions for optional additions such as discovery and identity. 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. On 7 August 2026 a second document was submitted, draft-payment-discovery-00, “Service Discovery for HTTP Payment Authentication.” It 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. The draft is careful to keep discovery advisory: “The runtime 402 challenge remains authoritative for all payment parameters,” and clients “MUST NOT rely on discovery metadata for security decisions.”

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.

The most recent addition, on 3 August 2026, is relays. 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. It expires 19 September 2026.