MPP: the Machine Payments Protocol

How an MPP request works

1. 01

   Request a resource

   An agent or application calls an API, MCP tool, content route, or other HTTP address.

2. 02

   Receive a payment challenge

   The service returns 402 with WWW-Authenticate: Payment and describes a payment method, intent, and method-specific request.

3. 03

   Fulfill the challenge

   The client selects and fulfills a compatible challenge. An application policy may decide whether it is authorized to do so.

4. 04

   Present payment

   The client retries with Authorization: Payment. The credential echoes the challenge; a body digest binds the retry to the body when the challenge includes one.

5. 05

   Receive the resource and evidence

   The service performs method-specific verification and settlement, returns the resource, and can include a Payment-Receipt on a successful 2xx response.

A protocol above the payment method

MPP separates the HTTP negotiation from the underlying way value moves. Stripe’s integration accepts stablecoins settled onchain as well as fiat methods—cards, Link, and buy-now-pay-later—through Shared Payment Tokens. Tempo provides a payments-first network for stablecoin settlement, while the protocol can coordinate other methods.

This separation matters for businesses that want machine-readable payments without forcing every buyer into the same wallet or settlement model. The seller can advertise supported methods and the client can choose one it is authorized to use.

Payment patterns MPP is designed to support

• Charges for a fixed, one-time API call or resource.
• Metered sessions that increment authorization as tokens, bytes, or other usage accrues.
• Subscriptions for fixed recurring access; the current implementation begins with stablecoin payments on Tempo, and availability varies by method.
• Stripe-specific merchant workflows with reporting, refunds, and payouts when Stripe is the selected method.

Implementation questions to answer first

Define the resource, amount, validity window, supported methods, and the relationship between payment and business authorization. Decide which system owns idempotency and how the service communicates an expired, rejected, or already-used credential.

For agent buyers, keep the policy engine outside the model’s prompt. For sellers, treat the protocol challenge as part of the API contract and test it with the same care as any authentication or billing boundary.

MPP’s HTTP payment authentication specification is published as an individual Internet-Draft with intended Standards Track status. It is a work in progress, can change or be replaced, and is not an adopted RFC or evidence of IETF endorsement.