How Agents Pay for Things with Machine Payments Protocol
Key Takeaways
What is the Machine Payments Protocol (MPP) and how does it work? MPP is an open standard co-authored by Stripe and Tempo that enables machine-to-machine payments over HTTP. A client requests a resource, the server returns an HTTP 402 with payment requirements, the client pays and retries with cryptographic proof, and the server delivers the resource with a receipt. The entire flow happens in a single request cycle.
How is MPP different from x402 and other agent payment protocols? MPP is payment-method agnostic — it supports credit cards (via Stripe), stablecoins (via Tempo), and Bitcoin Lightning, while x402 only supports on-chain crypto. MPP also adds protocol-level features like idempotency keys, request-body binding, and streaming sessions that enable micropayments as low as $0.0001.
Why do AI agents need a native payment protocol? Traditional payment flows — account creation, pricing pages, checkout forms, OAuth — assume a human is in the loop. Agents running multi-step workflows need to discover, negotiate, and complete payments programmatically without manual intervention. MPP removes the human bottleneck from the payment layer.
The Internet Has No Payment Layer
Every protocol stack has a gap. HTTP handles communication. TLS handles encryption. DNS handles naming. But when one machine needs to pay another machine for a service — a web scraping API call, an inference endpoint, a data lookup — there's no standard way to do it.
HTTP 402 Payment Required has existed since the original HTTP specification in 1997. It was reserved for exactly this purpose: machine-native payments. But the infrastructure to support it never materialized, so the status code sat dormant for nearly three decades.
Why Agents Can't Use Human Payment Flows
The payment infrastructure that works for humans — Stripe Checkout, PayPal buttons, subscription management dashboards — is structurally incompatible with autonomous agents. Consider what happens when an AI agent running a research workflow needs to call a paid API:
- Create an account on the service provider's platform
- Navigate a pricing page and select a tier
- Enter payment credentials through a web form
- Manage API keys and billing state across sessions
Each step assumes a human with a browser. An agent orchestrated by LangChain or AutoGen can't fill out a Stripe Checkout form. It can't solve a CAPTCHA. It can't evaluate whether a $49/month plan or a $99/month plan is the right choice for a one-off data request.
The result is that most agent-to-service interactions today require a human to pre-configure billing, pre-provision API keys, and pre-authorize spending limits. The agent doesn't pay for things — the human pays in advance, and the agent spends down a pre-allocated budget.
How MPP Works: Challenge, Credential, Receipt
The Machine Payments Protocol solves this with a three-primitive model built directly on HTTP semantics:
1. GET /resource → Client requests the resource
2. 402 Payment Required + WWW-Authenticate → Server issues a Challenge
3. Client fulfills payment → Signs transaction or pays invoice
4. GET /resource + Authorization: Payment → Client retries with Credential
5. 200 OK + Payment-Receipt → Server delivers resource + ReceiptThe Challenge contains everything the client needs to decide whether and how to pay: the amount, accepted payment methods, and whether this is a one-time charge or a streaming session. The Credential contains cryptographic proof that payment was completed. The Receipt confirms settlement.
| Primitive | HTTP Header | Purpose |
|---|---|---|
| Challenge | WWW-Authenticate: Payment | Server declares price and accepted methods |
| Credential | Authorization: Payment | Client proves payment was made |
| Receipt | Payment-Receipt | Server confirms settlement |
Several design decisions make this production-ready rather than academic. Servers must not perform side effects on unpaid requests — no database writes, no external API calls — until payment is verified. Challenge IDs are cryptographically bound to prevent replay attacks. For non-idempotent requests, servers accept an Idempotency-Key header to allow safe client retries.
Charges vs. Sessions: Two Payment Modes
MPP supports two payment intents that map to different agent workloads.
A charge is a one-time payment per request. One API call, one payment, one receipt. At typical prices of $0.01 to $0.10 per request, charges work well for discrete operations like a single data lookup or a one-off inference call.
A session is a streaming payment channel for continuous agent activity. The client opens a channel by depositing funds into an escrow contract, then makes subsequent requests by issuing signed off-chain vouchers rather than on-chain transactions. The server periodically settles the accumulated vouchers, and unspent deposits are refunded when the channel closes.
The performance difference is significant. Individual interactions within a session settle via off-chain signature verification rather than on-chain consensus, which means per-request latency drops to low double-digit milliseconds and per-request cost can reach $0.0001.
Consider a research agent running a multi-step market analysis. It might query a web search API dozens of times, access a data provider, and call an inference endpoint — all within a single task. With charges, each interaction is a separate payment negotiation. With a session, the agent authorizes a budget once and issues signed vouchers for each subsequent call.
Payment Method Agnosticism
Unlike x402 (Coinbase/a16z), which requires on-chain crypto for every payment, MPP is explicitly payment-method agnostic. The core protocol standardizes the Challenge-Credential-Receipt negotiation, while individual payment method specifications define how each network integrates.
| Payment Method | Rail | Status |
|---|---|---|
| Stripe | Visa, Mastercard, card networks | Production |
| Tempo | USDC/USDT stablecoins on Tempo L1 | Production |
| Bitcoin Lightning | Lightning Network | Production |
| Solana | SOL and SPL tokens | Specification available |
This means an agent can pay for a service using a credit card, a stablecoin, or Bitcoin Lightning, depending on what the service accepts and what the agent has available. The protocol handles the negotiation — the agent doesn't need to know in advance what a given service supports.
The protocol is also open to extension. Any developer or payment network can define a new payment method by publishing a specification for their rail. This mirrors the architecture of the web itself: the HTTP standard is fixed, but what runs over it isn't.
MPP Meets MCP: Payments for Tool Calls
For developers building on the Model Context Protocol (MCP), MPP includes a dedicated MCP transport binding. This maps the Challenge-Credential-Receipt flow directly onto MCP tool calls, so agents can discover and pay for tools within the same interaction.
An agent using an MCP server that exposes a paid tool — a web scraping Actor, an inference endpoint, a data API — can pay for that tool call without a separate billing account, API key management, or human approval. The payment is part of the protocol, not a side channel.
This is where the agentic commerce stack starts to look real. The data layer that agents depend on — scrapers, APIs, databases — can be monetized at the request level, with payments flowing automatically as agents consume services.
What's Already in Production
MPP launched with production adoption from day one. Browserbase lets agents run headless browsers and pay per session — exactly the kind of continuous, metered workload that sessions are designed for. Parallel Web Systems integrated MPP to allow per-API-call payment for web access. For Stripe merchants, MPP payments appear in the Stripe dashboard like any other transaction, with the same fraud protection, tax calculation, and payout infrastructure.
The open question isn't whether machine-native payments will become standard. It's how quickly the surrounding identity and authorization layers — agent identity verification, spending controls, dispute resolution — will develop to support them at enterprise scale.
Related: The Agentic Stack and How Modern Automation Fits Together explains why the data layer is the bottleneck in AI agent systems. What Is the Model Context Protocol and Why Developers Are Building on It covers the protocol that MPP's payment layer plugs into.