The Machine Payments Protocol (MPP) is an open standard that lets AI agents pay for API calls over HTTP, co-authored by Stripe and Tempo Labs and launched on March 18, 2026. It uses HTTP's 402 status code to enable challenge-response payments in stablecoins or cards, with a native session primitive for sub-cent streaming micropayments. Tempo's team describes sessions as "OAuth for money": authorize once, then let payments execute programmatically within defined limits.
AI agents are increasingly autonomous. They browse the web, call APIs, book services, and execute transactions on behalf of users. But until recently, there was no standard way for a machine to pay another machine over HTTP.
HTTP actually anticipated this problem decades ago. The 402 status code ("Payment Required") was reserved in the original HTTP/1.1 spec (RFC 9110) but never formally standardized. For 27 years, it sat unused.
The problem is not a lack of payment methods. As the MPP documentation puts it: there is no shortage of ways to pay for things on the internet. The real gap exists at the interface level. The things that make checkout flows fast and familiar for humans (optimized payment forms, visual CAPTCHAs, one-click buttons) are structural headwinds for agents. Browser automation pipelines are brittle, slow, and expensive to maintain.
MPP addresses this by defining a payment interface built for agents. It strips away the complexity of rich checkout flows while providing robust security and reliability. Three parties interact through the protocol: developers who build apps and agents that consume paid services, agents that autonomously call APIs and pay on behalf of users, and services that operate APIs charging for access.
How Does MPP Work? A Technical Overview
MPP operates as an HTTP Authentication Scheme, formally proposed to the IETF as draft-httpauth-payment-00 (published March 30, 2026, authored by engineers from Tempo Labs and Stripe). The canonical reference lives at paymentauth.org. The core protocol follows a challenge-response pattern that will feel familiar to anyone who has worked with HTTP auth:
Request: A client (AI agent) sends a normal HTTP request to a resource.
Challenge: The server returns HTTP 402 with a
WWW-Authenticate: Paymentheader encoding the payment requirements.Payment: The client fulfills the challenge by signing a transaction, paying an invoice, or completing a card authorization.
Retry: The client retries the original request with an
Authorization: Paymentheader containing proof of payment.Delivery: The server verifies settlement and returns the resource alongside a
Payment-Receiptheader.
Here is what the actual HTTP exchange looks like:
The Anatomy of a Payment Challenge
When a server returns 402, the WWW-Authenticate header carries several required parameters that define the payment terms:
id: A unique challenge identifier. Servers bind this to the challenge parameters (typically via HMAC-SHA256) so they can verify credentials statelessly, with no database lookup required.realm: The protection space, similar to how HTTP Basic auth scopes credentials.method: The payment method identifier (e.g., tempo, stripe, solana, card). Each method is defined in its own IETF specification with separate request and payload schemas.intent: The type of payment being requested (charge for one-shot, session for streaming).request: Base64url-encoded JSON containing method-specific data needed to complete payment (amount, currency, recipient address, etc.), serialized using JSON Canonicalization Scheme (JCS, RFC 8785) for deterministic encoding.
A server can also return multiple Payment challenges in a single 402 response, each with a different payment method or configuration. The client picks whichever one it can fulfill.
The Credential and Receipt
After fulfilling the payment, the client retries with an Authorization: Payment header containing a base64url-encoded JSON object. This credential echoes back the challenge parameters and includes a payload with method-specific proof of payment (a transaction signature, a Stripe token, etc.). The credential can also carry a source field identifying the payer, recommended to use DID format (W3C Decentralized Identifiers).
On success, the server responds with a Payment-Receipt header: a base64url-encoded JSON object containing the settlement status, payment method used, timestamp, and a method-specific reference (transaction hash, invoice ID, etc.).
The Modular Spec Architecture
One of MPP's most important design decisions is its separation of concerns. The core protocol (the Payment HTTP auth scheme) is payment-method agnostic. It defines the challenge-response flow, error handling, and security model, but knows nothing about how any specific payment method works.
Concrete payment methods are defined in separate IETF specifications. As of launch, these include:
Charge intents (one-shot payments): Tempo, Stripe, Card, Solana (SDK live but spec not yet finalized)
Session intents (streaming payments): Tempo
Discovery: A spec for how clients find payment-enabled services
Transports: Specs for JSON-RPC and MCP alongside HTTP
This means MPP can support any payment rail, present or future, without modifying the core protocol. New payment methods register an identifier and publish a spec defining their schemas and verification procedures.
Charge Intent vs. Session Intent
Charge intent handles one-shot payments: one request, one payment, one response. This is functionally equivalent to x402's "exact" flow and maintains backward compatibility with existing 402 implementations.
Session intent is MPP's architectural differentiator. Agents deposit funds into an escrow contract (roughly 500ms setup time), then issue cumulative EIP-712 signed vouchers with each subsequent request.
The server verifies vouchers via ecrecover with no RPC call or database lookup required, enabling sub-100ms latency. Payments as small as $0.0001 per request become practical because thousands of micro-interactions batch-settle into a single on-chain transaction when the session ends. Unused funds are refunded automatically.
Security Model
The IETF spec defines a thorough security model built around several assumptions: attackers can observe all network traffic, inject or replay messages, and may control malicious servers or clients. Key requirements include:
TLS required: Servers must not issue challenges over unencrypted HTTP. Clients must not send credentials over unencrypted HTTP.
Replay protection: Payment proofs must be single-use. Subsequent attempts to reuse the same proof must be rejected.
Idempotency: Servers must not perform side effects for unpaid requests. Non-idempotent methods (POST, PUT, DELETE) should support
Idempotency-Keyheaders for safe retries.Amount verification: Clients must verify that the requested amount, recipient, and currency are reasonable before authorizing payment, and must not rely on the
descriptionfield for this verification.Privacy: Servers must not require user accounts for payment. Payment methods should support pseudonymous options where possible.
Supported SDKs and Middleware
Official SDKs ship in TypeScript, Python, and Rust. Middleware is available for Next.js, Hono, Express, Cloudflare Workers, FastAPI, Deno, and Bun. MPP operates over HTTP, MCP (Model Context Protocol), and JSON-RPC transports.
What Does the MPP Ecosystem Look Like Today?
Early Adoption Numbers
MPPScan, the protocol's block-explorer equivalent built by Merit Systems, tracks adoption in real time. As of late March 2026, the self-reported numbers are modest: roughly 31,100 transactions, $3,730 in volume, 671 registered agents, and 326 servers. These figures have not been independently verified, which is expected for a protocol barely two weeks old.
Integrated Services
The MPP Services Directory lists over 100 integrated services spanning developer infrastructure, AI tools, and physical-world commerce. Developer infrastructure providers like Alchemy and QuickNode offer pay-per-request blockchain data. Browserbase lets agents spin up headless browsers and pay per session. fal.ai offers image generation per request.
Developer Onboarding
For developers, the onboarding path is straightforward:
This creates a passkey-based wallet in the browser. The AgentCash toolkit (built by Merit Systems) provides one-command setup.
MPP vs. x402: How Do They Compare?
The most important comparison for crypto-native builders is between MPP and x402, Coinbase's HTTP-native micropayment protocol that launched in May 2025, nearly a year earlier.
x402: Optimized for Permissionlessness
x402 was created by Coinbase and is governed by the x402 Foundation (co-founded with Cloudflare, with members including Google and Visa). It is open-source under Apache 2.0. Any wallet can pay. The protocol itself charges zero fees, though the default Coinbase CDP facilitator charges $0.001 per transaction after 1,000 free monthly transactions.
x402 uses a facilitator (a service that verifies and settles payments between client and server). The facilitator is optional but recommended in the official docs; servers can verify payments locally, but nearly all production implementations use one.
x402 V2 (shipped December 2025) added a plugin architecture, multi-chain support via CAIP standards, and architectural compatibility with legacy payment rails (ACH, SEPA, cards) through the facilitator model, though no production fiat facilitator has shipped yet. V2 also laid the groundwork for wallet-based sessions.
The full Sign-In-With-X (SIWx) extension shipped on March 16, 2026, allowing wallet-authenticated sessions that skip re-payment for previously purchased content. However, SIWx sessions are fundamentally different from MPP sessions: they are authentication-based (prove wallet ownership, receive a JWT) rather than payment-based (deposit escrow, stream signed vouchers).
On adoption: x402 reports 140M+ raw on-chain transactions, but a CoinDesk investigation citing Artemis on-chain analysis found that roughly 48% of transactions and 81% of dollar volume were linked to artificial activity (self-dealing and wash trading). The frequently cited $600M volume figure is an annualized projection; actual daily volume is approximately $28,000.
MPP: Optimized for System Completeness
MPP eliminates the facilitator as an architectural concept. Payment methods (Tempo stablecoins, Stripe cards) are first-class protocol extensions that settle natively, with no intermediary routing service required.
It ships with native streaming payment sessions from day one. It supports fiat rails (cards, wallets, BNPL via Stripe) alongside crypto.
It includes first-class protocol primitives for idempotency, replay protection, and structured receipts.
And unlike x402, MPP has been submitted to the IETF as a Standards Track Internet-Draft, pursuing the same standardization path as HTTP itself.
The tradeoff: MPP is more opinionated. Its primary settlement chain is Tempo (a VC-backed L1), and its fiat integration requires Stripe, making it less permissionless but more enterprise-ready.
Currently, only US businesses can accept stablecoin payments through the Stripe integration. MPP still relies on payment providers (Stripe for fiat, Tempo for stablecoins), but these function as payment rails rather than routing intermediaries.
When to Use Which
Consideration | x402 | MPP |
|---|---|---|
Philosophy | Permissionless, crypto-native | Enterprise-ready, multi-rail |
Sessions | Auth-based via SIWx (skip re-payment for purchased content) | Payment-based (escrow deposit, streaming signed vouchers, batch settlement) |
Fiat Support | Architecturally supported in V2, no production facilitator yet | Production-ready (via Stripe) |
Protocol Fees | Zero (Coinbase facilitator: $0.001/tx after 1K free/month) | Zero (Stripe fees on fiat, sub-cent gas on Tempo) |
Adoption | 140M+ raw transactions (~half artificial per Artemis), ~$28K daily volume | ~31K transactions, ~$3.7K volume (unverified, 2 weeks old) |
Facilitator | Optional but recommended; nearly all implementations use one | Eliminated as a concept; payment methods are protocol extensions |
IETF Standardization | No | Yes (Internet-Draft submitted) |
Backward Compatible | N/A | x402 charge flow maps to MPP charge intent |
One crucial detail: MPP is backward-compatible with x402 at the charge layer. The x402 "exact" payment flow maps directly onto MPP's charge intent.
The Emerging Four-Protocol Stack for Agentic Commerce
MPP's launch completes a four-protocol stack that is emerging for autonomous agent commerce, each handling a different layer:
ACP (Agentic Commerce Protocol, OpenAI + Stripe): standardizes the checkout flow between agents and merchants.
AP2 (Agentic Payments Protocol, Google/A2A framework): standardizes authorization and trust, and integrates x402 for settlement.
x402 (Coinbase): permissionless stablecoin settlement over HTTP.
MPP (Stripe + Tempo): multi-rail settlement with streaming sessions.
These protocols are designed to be composed together rather than to compete exclusively. A production agent system might use ACP for product discovery, AP2 for trust verification, and either x402 or MPP (or both) for settlement depending on the payment context.
What Does MPP Mean for DeFi Builders?
For DeFi protocol teams evaluating MPP, the honest assessment requires separating what is genuinely new from what is incremental.
MPP's real technical contribution is the streaming payment session. If your protocol serves high-frequency agent queries (on-chain analytics, MEV protection, real-time data feeds), sessions solve a real problem. Per-request on-chain settlement is too expensive even on cheap L2s when you are talking about thousands of $0.001 calls per minute. MPP sessions batch-settle into a single transaction and refund the unused balance. x402 now has SIWx sessions (shipped March 2026), but those are authentication-based: they let agents skip re-payment for previously purchased content. MPP sessions are payment-based: agents deposit escrow and stream signed vouchers for ongoing micropayments. These solve different problems.
The fiat bridge matters if your users include non-crypto-native agents. Stripe's integration means agents operating with traditional payment rails can access your service through the same protocol as agents paying in USDC. For protocols that only serve crypto-native users, this is irrelevant. For protocols trying to reach the broader AI agent market, it could be a significant onboarding advantage.
The partner roster is notable but the traction is early on both sides. Visa, Mastercard, Cloudflare, Anthropic, and OpenAI are all listed as MPP partners. Stripe processes payments for millions of businesses. That said, neither protocol has meaningful commercial volume yet. x402 reports 140M+ transactions, but independent analysis found roughly half are artificial, with actual daily volume around $28,000. MPP's self-reported numbers (~31K transactions, ~$3.7K volume) are unverified. Partner announcements and production adoption are very different things.
The centralization tradeoff deserves honest scrutiny. Tempo is a VC-backed L1 with centralized validator sets at launch. The Stripe dependency for fiat rails introduces a traditional fintech gatekeeper. The modular spec architecture means you can use MPP with other chains (Solana has an SDK, though the spec is not yet finalized), but the session primitive currently only works on Tempo.
Our pragmatic recommendation: Default to x402 for permissionless crypto-native use cases. It has a longer track record, zero protocol fees, and any-wallet compatibility. Adopt MPP when you specifically need streaming micropayment sessions or production-ready fiat support today. The backward compatibility at the charge layer means you are not making an either/or bet. You are choosing which features justify the additional integration.
Frequently Asked Questions (FAQ)
What is MPP (Machine Payments Protocol)?
MPP is an open standard for machine-to-machine payments over HTTP, co-authored by Stripe and Tempo Labs and proposed to the IETF. It gives HTTP's 402 status code a formal specification, allowing AI agents to discover pricing, pay for resources (using stablecoins or cards), and receive cryptographic receipts in a single request-response cycle. The core protocol is payment-method agnostic, with concrete payment methods defined in separate specifications.
How is MPP different from x402?
Both protocols use the HTTP 402 status code for payments, but they differ in philosophy and features. x402 (by Coinbase) is permissionless with zero protocol fees (the Coinbase facilitator charges $0.001/tx after a free tier). Its V2 added architectural support for fiat via facilitators, though no production fiat integration has shipped yet. x402's SIWx extension (shipped March 2026) offers wallet-authenticated sessions for skipping re-payment, but these are authentication-based, not streaming micropayment sessions.
MPP supports multiple payment rails including production-ready fiat (via Stripe), ships with native streaming payment sessions, eliminates the facilitator as an architectural concept, and has been submitted to the IETF as a Standards Track Internet-Draft. MPP is backward-compatible with x402's charge flow.
What is an MPP session, and why does it matter?
An MPP session lets an agent deposit funds into an escrow contract once, then make thousands of subsequent micropayment requests using signed vouchers, without hitting the blockchain on every call.
This enables payments as small as $0.0001 per request with sub-100ms latency. All micro-interactions batch-settle into a single on-chain transaction when the session ends, with unused funds refunded. Currently, session intents are specified for Tempo.
What blockchain does MPP use?
MPP is payment-method agnostic at the protocol level. The core spec does not mandate any specific chain. In practice, payment method specifications have been published for Tempo (Stripe and Paradigm's payments-focused EVM L1 with sub-second finality), Solana (SDK live, spec not yet finalized), and card payments via Stripe. Sessions are currently available on Tempo.
Can I use MPP for my DeFi protocol or API today?
Yes. MPP SDKs are available in TypeScript, Python, and Rust, with middleware for popular frameworks. The onboarding process starts with the Tempo CLI. Over 100 services are already listed in the MPP Services Directory. Note that stablecoin acceptance through Stripe is currently limited to US businesses.
Is MPP an open standard?
MPP is proposed to the IETF as a Standards Track Internet-Draft. The spec architecture is modular: the core authentication scheme is defined in one document, with separate specifications for each payment method, intent type, discovery mechanism, and transport. All specifications are publicly available at paymentauth.org. The reference SDKs are maintained by Tempo Labs and Wevm.
How does MPP relate to MCP (Model Context Protocol)?
MPP supports MCP as a first-class transport alongside HTTP and JSON-RPC, defined in a separate IETF specification (draft-payment-transport-mcp-00). This means MCP tool servers can natively charge agents for tool usage using the same 402 challenge-response pattern. For AI agent builders, this makes it straightforward to monetize MCP-based tools.
Should I use MPP or x402 for my project?
For permissionless crypto-native use cases, x402 has a longer track record, zero protocol fees, and any-wallet compatibility. Adopt MPP when you specifically need streaming micropayment sessions (MPP's genuine innovation; x402's SIWx sessions solve a different problem) or production-ready fiat support today.
Neither protocol has significant commercial volume yet, so the decision should be based on technical fit rather than adoption metrics. The two protocols are backward-compatible at the charge layer, so you are not locked into an either/or decision.
