You find an API that does exactly what you need. You only want to make a handful of calls to see if it works. Before the first request goes out, you are creating an account, confirming your email, entering a credit card, choosing a pricing tier and copying an API key into an environment variable. Ten minutes of paperwork for a few cents of usage.
Now picture an AI agent in the same position. It is halfway through a research task and hits a paid data source. It cannot fill in a signup form, solve a CAPTCHA or wait for a verification email. So it either stops, or it quietly works with worse data. The payment is trivial. The ceremony around the payment is what blocks it.
The Machine Payments Protocol (MPP) is an attempt to delete that ceremony. It lets a client pay for a resource inside the same HTTP exchange that requests it, with no account and no checkout page.
The Problem: Payments Were Built for Humans
Online payments are very good at one thing: getting a person through a checkout. One-click buttons, saved cards, fraud checks and 3-D Secure prompts are all tuned for a human sitting in front of a browser. For software, every one of those features is an obstacle. Automating a checkout form means fighting CAPTCHAs, changing layouts and bot detection that exists specifically to stop you.
APIs dodged this by moving payment out of the request entirely. You sign up once, attach a card to an account and get an API key. Every request carries the key, and the provider bills you monthly. That works when a developer sets things up in advance for a service they will use for months. It fails when the caller is an agent that discovers a service mid-task and needs it exactly once.
There is also a pricing problem. Card networks have fixed per-transaction fees, which makes charging one cent for a single search request uneconomical. So providers bundle usage into subscriptions and credit packs, which pushes the caller back into the signup flow.
MPP's framing is that none of this is the fault of cards or any single payment method. The gap is at the interface level: there is no standard way for a buyer and a seller to negotiate a price, agree on a payment method and exchange proof of payment programmatically.
A Status Code That Waited 30 Years
HTTP has had a status code for this since 1997. 402 Payment Required appeared in the HTTP/1.1 specification and was marked "reserved for future use." The current HTTP semantics RFC still says the same thing. Almost nobody used it, because there was no agreed way to say what payment was required or how to prove it had been made.
MPP gives 402 that missing definition. It was co-authored by Stripe and Tempo, a payments-focused blockchain incubated by Stripe and Paradigm, and launched in March 2026. The core has been submitted to the IETF as an Internet-Draft that defines a new HTTP authentication scheme called Payment.
That last detail is the clever part. HTTP already has a general framework for "you cannot have this until you prove something." A server replies with a WWW-Authenticate header describing what it wants, and the client retries with an Authorization header carrying the proof. You have seen this with Basic and Bearer. MPP treats payment as just another thing to prove, and slots into the same machinery.
How It Works: Challenge, Credential, Receipt
Every MPP exchange is built from three objects. The server issues a Challenge describing the price. The client answers with a Credential proving it paid. The server returns a Receipt confirming delivery.
Step by step:
- The client makes a normal request, exactly as it would to a free API.
- The server replies
402with a Challenge in aWWW-Authenticate: Paymentheader. - The client picks a payment method it supports and pays: signing a stablecoin transfer, paying a Lightning invoice or completing a card payment.
- The client repeats the request, this time with a Credential in an
Authorization: Paymentheader. - The server verifies the payment and returns the resource with a
Payment-Receiptheader.
There is no signup anywhere in that flow. The server never needs to know who the client is ahead of time, only that this particular request has been paid for.
What a Challenge Looks Like
Here is the first round trip on the wire, lightly simplified from the MPP protocol docs:
GET /v1/search?q=solar+tariffs HTTP/1.1
Host: api.example.com
HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="qB3wErTyU7iOpAsD9fGhJk",
realm="api.example.com",
method="tempo",
intent="charge",
request="eyJhbW91bnQiOiIxMDAwIiwiY3VycmVuY3kiOi...",
expires="2027-01-15T12:05:00Z"The server is saying: "This costs something, here is how to pay, and this offer is valid until the timestamp in expires." The request parameter is base64url-encoded JSON. Decoded, it holds the actual terms:
{
"amount": "1000",
"currency": "0x20c0000000000000000000000000000000000000",
"recipient": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266"
}Amounts are in base units of the currency, the same way many payment APIs express dollars as cents. The currency here is a token address because the method is tempo; for a stripe method it would be an ordinary currency code like usd.
What a Credential Looks Like
Once the client has paid, it retries the request with a Credential. On the wire it is one long base64url string after the word Payment. Decoded, it has three parts:
{
"challenge": {
"id": "qB3wErTyU7iOpAsD9fGhJk",
"realm": "api.example.com",
"method": "tempo",
"intent": "charge",
"request": "eyJhbW91bnQiOiIxMDAwIiwiY3VycmVuY3kiOi...",
"expires": "2027-01-15T12:05:00Z"
},
"payload": { "type": "hash", "hash": "0xabab...abab" },
"source": "did:pkh:eip155:4217:0x1234...5678"
}The challenge block echoes the server's offer back unchanged, so the server can confirm the client is answering the offer it actually made. The payload is the method-specific proof of payment; here it is the hash of an on-chain transfer, which the server looks up to confirm the right amount went to the right recipient. The source identifies the payer, as a wallet address, a decentralized identifier or an account ID.
Finally, the server returns 200 OK with the content and a Payment-Receipt header. The receipt is the client's proof that the service delivered what was paid for, which matters when an agent needs to account for its spending later.
Keeping It Honest
A protocol that moves money inside HTTP headers has to assume someone will try to cheat. MPP bakes in a few protections that are worth understanding, because they explain some of its design choices.
Challenge binding stops a client from editing the terms. If the client could change amount from 1000 to 1 and send back the same id, the server would be in trouble. So the server must bind the id to every parameter of the offer, either by storing the offer or by making the id an HMAC over the terms. Any tampering produces an id that no longer matches.
Single-use credentials stop replay. Binding proves the terms were not modified; it does not stop a client from sending the same valid payment proof twice to get two responses. Servers must reject any credential they have already accepted, check that the challenge has not expired and verify the payment itself.
Body digests handle requests that carry data. For a POST, the server can include a digest of the request body in the challenge, so a payment for one request cannot be reused to cover a different one.
There is also a practical wrinkle. Plenty of APIs already use the Authorization header for their own login tokens. A challenge can therefore specify header="Payment-Authorization", and the client sends its app token and its payment proof in separate headers.
Charge, Session and Subscription
The simple flow above is the charge intent: one request, one known price, one payment. It fits most per-call APIs. But it breaks down in two common situations: when the price is tiny and requests are frequent, and when the final cost is not known until the work is done. An LLM streaming tokens is both.
Paying a separate on-chain transaction for every token or every search request would drown the useful work in settlement overhead. The session intent solves this with a pattern borrowed from payment channels.
In a session, the client first locks a deposit into an escrow-backed channel. That is one real transaction. From then on, each request carries a signed voucher: a small message saying "I now owe you this running total." Vouchers are just signatures, so they are free to produce and instant to verify. When the session ends, the server submits the latest voucher, collects what it is owed and the rest of the deposit goes back to the client.
However many requests happen in between, the payment network only sees two transactions. That is what makes sub-cent pricing viable: per token, per query or per compute unit.
The third intent, subscription, covers the familiar case where access renews at a fixed amount each billing period. The intents describe the shape of the payment; each payment method defines how that shape maps onto its own network.
Payment Methods: Stablecoins and Cards
MPP does not pick a winner on how money moves. A challenge's method field can name a stablecoin network like Tempo or Solana, the Bitcoin Lightning Network, card payments through Stripe or a custom method. A server can offer several at once by sending multiple WWW-Authenticate headers, and the client answers whichever one it supports.
Cards are the interesting case, because an agent should never hold your raw card number. Stripe handles this with Shared Payment Tokens (SPTs): scoped, revocable tokens that let an agent spend against a saved payment method within limits. The trade-off is fees. Stripe documents a minimum of $0.50 for card payments over MPP, versus one cent for stablecoin payments. For true micropayments, stablecoins are currently the practical choice.
The protocol also extends beyond plain HTTP. MCP tool calls use the same challenge, credential and receipt flow carried inside JSON-RPC messages, and there is a WebSocket transport for long-lived connections. A paid MCP server can charge per tool invocation without any separate billing system.
MPP, x402 and ACP
MPP is not the only protocol in this space, and the names get confusing quickly.
- x402, from Coinbase, arrived first with the same core idea: revive
402so clients can pay per request, primarily in stablecoins. MPP's documentation describes MPP as backward-compatible with x402, and Stripe supports both. - ACP (Agentic Commerce Protocol), co-developed by Stripe and OpenAI, solves a different problem. It lets an agent check out from a merchant's product catalog on a user's behalf: buying a pair of shoes, not paying for an API call.
The useful mental model: ACP replaces the shopping cart, while MPP and x402 replace the API key. An agent could plausibly use both in the same task.
Where You'll Encounter It
As of September 2026, MPP is early but already showing up in real infrastructure.
Stripe lets businesses accept MPP payments through its existing PaymentIntents API, which means agent payments flow into the same tax, fraud, reporting and refund tooling as human ones. Access is currently by request.
Cloudflare documents MPP support in its Agents platform, and there are integrations for the official MCP SDK and the Vercel AI SDK. Official client and server SDKs exist for TypeScript (mppx), Python, Rust and Go, with middleware for frameworks like Express, Hono and Next.js.
On the service side, paid APIs are starting to expose MPP endpoints directly. The web research API Parallel, for example, lets agents pay per request for search and extraction, starting at one cent, with no account setup.
If you run an API, the realistic first step is not replacing your API keys. It is adding MPP as a second door: existing customers keep their keys, while agents and one-off callers pay per request without ever signing up.
If you build agents, the question shifts from "does my agent have an API key for this?" to "how much is my agent allowed to spend?" Wallet limits, per-task budgets and receipt logging become part of agent design, and the MPP docs already include guidance on managing agent spend.
Summary
MPP's core insight is that paying for a web resource is just another form of proving you are allowed to have it. HTTP already had the machinery for that, in the challenge-and-response pattern behind every Authorization header, and a status code reserved for payments since 1997. MPP connects the two. A server states its price in a 402 challenge, the client pays by whatever method both sides support and proves it with a credential, and the server hands over the resource with a receipt.
Everything else is refinement: challenge binding and single-use credentials to keep the exchange honest, sessions and vouchers to make sub-cent pricing economical, and pluggable methods so the same handshake works for stablecoins and cards alike. The result is that paying for an API call can be as mechanical as calling it, which is exactly what software that acts on its own needs.
Part of the Explained series — concepts in tech, clearly.