How agents pay for things with Machine Payments Protocol (MPP)

The internet has always had protocols for communication, data exchange, and computation. What it lacked was a standard for machines to pay other machines.

The Machine Payments Protocol (MPP), co-authored by Stripe and Tempo and launched in March 2026, is a serious attempt to define that layer. It's a currency- and asset-agnostic protocol designed for programmatic access across any payment rail.

To understand MPP, you need to know the problem it solves and how its core primitives work. You'll learn both in this article as we explain how MPP fits within the broader agentic commerce protocol stack.

The problem with paying for things programmatically

Every API developer knows that to access a paid service, an agent typically needs to create an account, navigate a pricing page, choose a subscription tier, enter payment details, and manage billing credentials. Each of these steps assumes a human is in the loop.

The problem isn’t any individual payment method - it’s at the interface level itself. The mechanisms through which buyers and sellers agree on price, negotiate supported payment methods, and complete a transaction were designed for visual checkout flows. Captchas, billing forms, and OAuth flows that work well for human purchasers become structural obstacles for programmatic consumption.

MPP solves this by defining a payment interface stripped of checkout complexity, but maintaining security and reliability. A client - whether an AI agent, an application, or a human - can pay for any service in the same HTTP request that requests the resource.

The core protocol: Challenge, Credential, Receipt

The technical foundation of MPP is a three-primitive model defined in the protocol specification:

• A client requests a resource. The server returns an HTTP 402 with a Challenge in the WWW-Authenticate: Payment header, specifying payment requirements: amount, accepted payment methods, and intent type.
• The client fulfils the payment, then retries the request with a Credential in the Authorization: Payment header containing cryptographic proof of payment.
• The server verifies the proof and delivers the resource with a Receipt in the Payment-Receipt header confirming successful settlement.

The full flow below is submitted to the IETF as the Payment HTTP Authentication Scheme:

1. GET /resource - client requests the resource
2. 402 Payment Required + WWW-Authenticate: Payment - server issues the Challenge
3. Client fulfils payment (signs a transaction, pays a Lightning invoice, or completes a card payment)
4. GET /resource + Authorization: Payment - client retries with Credential
5. 200 OK + Payment-Receipt - server delivers resource with Receipt

It’s worth noting several design decisions in this flow:

Servers mustn’t 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. These are first-class protocol primitives, not implementation details left to individual services.

How MPP builds on the HTTP 402 concept

MPP isn't the first attempt at payment-gated requests. HTTP 402 - Payment Required has existed since the original HTTP specification. It was reserved for machine-native payments, but never implemented because the infrastructure to support it didn't exist. Protocols like x402 and L402 were the first serious attempts to bring it to life, using HTTP 402 to gate API access with stablecoin and Bitcoin Lightning payments respectively.

MPP builds directly on this concept and extends it in three significant ways.

1. First, where x402 requires an on-chain transaction for every individual request, MPP supports the Tempo blockchain, which settles interactions off-chain as signed vouchers with only net settlement hitting the chain. This is a capability of Tempo itself rather than the MPP protocol, which is designed to support multiple payment rails with their own distinct properties.
2. Second, MPP adds protocol-level features absent from x402: idempotency keys for safe retries, request-body binding via content digest to prevent tampering, and receipts as a first-class primitive.
3. Third, MPP is multi-rail from the ground up. It supports cards and Bitcoin Lightning alongside stablecoins, where x402 currently supports only blockchain-based rails.

MPP is also explicitly backwards compatible: the core x402 charge flows map directly onto MPP's charge intent, meaning MPP clients can consume existing x402 services without modification. The relationship is additive rather than competitive: MPP is best understood as a generalization of the HTTP 402 payment concept into a production-grade, multi-rail protocol with a formal standards process behind it.

Payment intents: charge vs. session

MPP supports multiple payment intents that define the type of payment being requested. The two production intents today are charge and session, and the distinction matters significantly for how agent workloads operate.

A charge is a one-time payment that settles immediately per request. It is the simpler model - one API call, one payment, one receipt. At typical prices of $0.01 to $0.10 per request, charges work well for discrete, infrequent operations.

A session is a streaming payment channel designed for continuous agent activity. Specifically, this is a feature of the Tempo blockchain that MPP supports. A client opens a channel by depositing funds into an escrow contract on-chain, then makes subsequent requests by issuing signed off-chain vouchers rather than on-chain transactions. The server periodically settles the accumulated vouchers on-chain, and any unspent deposit is refunded when the channel closes.

The performance characteristics of sessions are what make them significant. Individual interactions settle via off-chain signature verification rather than on-chain consensus, which means per-request latency drops to the low double-digit milliseconds, and per-request cost can reach as low as $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 of those is a separate payment negotiation. With a session, the agent authorizes a budget once and issues signed vouchers for each subsequent interaction, with only net settlement hitting the chain at the end.

The server can offer both intents simultaneously, and the client chooses:

• WWW-Authenticate: Payment id="abc", method="tempo", intent="charge", ...
• WWW-Authenticate: Payment id="def", method="tempo", intent="session", ...

Payment method agnosticism

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 its own request and credential schemas.

The payment methods currently available include:

• Tempo - stablecoin payments (USDC, USDT) on Tempo's payments-focused L1, designed for high-throughput, low-cost settlement
• Stripe - traditional card payments via Visa, Mastercard, and other networks through Stripe's platform
• Bitcoin Lightning - Bitcoin payments over the Lightning Network
• Solana - SOL and SPL token payments on Solana

Of these, Tempo, Stripe, and Bitcoin Lightning are confirmed in production. Solana is available as a payment method specification.

The protocol is open to extension without gatekeeping. Any developer or payment network can define a new payment method by publishing a specification for their rail. This mirrors the broader architecture of the web: the HTTP standard is fixed, but what runs over it isn’t.

This means an agent can pay for a service using a 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.

MPP and MCP: payments for tool calls

One detail that matters for anyone building on MCP: MPP includes a dedicated MCP transport binding that maps the Challenge-Credential-Receipt flow directly onto the Model Context Protocol. MCP servers can accept payment for individual tool calls, and agents pay autonomously without OAuth or account setup.

In practical terms, an agent using an MCP server that exposes a paid tool - a web scraping Actor, an inference endpoint, a data API - can discover and pay for that tool call within the same MCP interaction. No separate billing account, no API key management, no human approval required.

What MPP looks like in production

MPP launched with production adoption on day one. Browserbase lets agents run headless browsers and pay per session. That’s exactly the kind of continuous, metered workload the sessions intent is designed for. Parallel Web Systems integrated MPP in a few lines of code to allow per-API-call payment for web access. The founder described it as a way to reach any agent developer on the same Stripe infrastructure they already run. PostalForm uses it to let agents pay to print and send physical mail.

For Stripe merchants, MPP payments appear in the Stripe API and dashboard like any other transaction. Funds settle into existing balances in the merchant's default currency on their standard payout schedule. Tax calculation, fraud protection, accounting integrations, and refunds all operate as normal - the same infrastructure businesses use for human payments handles agent payments without modification.

What MPP still needs

MPP solves the payment coordination problem: how a machine requests a resource, negotiates payment, proves it paid, and receives a receipt. What it doesn’t yet resolve is the surrounding infrastructure: how a service verifies an agent is authorized to spend, what controls govern session limits, and how disputes are handled when a service underdelivers.

These are identity, authorization, and observability problems rather than payment problems. Standards like ERC-8004 address agent identity on-chain. Skyfire's KYAPay protocol addresses authorization and spending controls. Neither is yet mature enough for enterprise-scale agent deployments without significant human oversight in the loop.

MPP is early-access infrastructure. The sessions primitive, the multi-rail architecture, and the IETF submission are meaningful signals that this is being built as durable, standards-track infrastructure rather than a proprietary API. The open question isn’t whether machine-native payments will become standard. It’s how quickly the surrounding identity and authorization layers will develop to support them at scale.

Learn more about agentic protocols in Agentic commerce and the AI economy stack: Infrastructure for autonomous payments