x402 vs MPP: Comparing Agent Payment Protocols
Author: Uttam Singh
Autonomous agents need to pay for things. Not someday. Now. Every time an agent queries blockchain data, streams LLM tokens, or calls a paid API, someone has to handle billing. Today that means API keys, billing dashboards, and human provisioning. Two protocols are trying to fix that: x402 and MPP.
In late 2024, Coinbase introduced x402: an open protocol that lets an AI agent call an API, get a "pay first" response, settle with USDC on Base, and retry, all without API keys, billing accounts, or human intervention. Tempo and Stripe then took that thesis further with the Machine Payments Protocol (MPP). Defined in an IETF Internet-Draft, MPP generalizes the 402 pattern into a payment-method-agnostic framework that supports stablecoins, cards, bank transfers, and any future rail through a single protocol.
This post breaks down how the two protocols compare, where they overlap, and when you'd reach for one over the other.
At a Glance
| x402 | MPP | |
|---|---|---|
Payment rails | USDC on Base and other networks | Stablecoin, card, bank: pluggable |
Payment models | One-shot (exact) | One-shot (charge) + sessions |
Session support | No | Yes (escrow + signed vouchers) |
Protocol primitives | Implementation-defined | Standardized (idempotency, expiry, receipts, replay protection) |
Transport | HTTP | HTTP + MCP |
Standardization | Open-source, community-adopted | IETF Internet-Draft (co-authored by Tempo and Stripe) |
How Do x402 and MPP Handle the Core Payment Flow?
At their core, both protocols follow the same flow: an agent calls an API, the server responds with a payment challenge, the client pays and retries, and gets the response. Simple, elegant, and HTTP-native.
Where they differ is in scope, flexibility, and what each protocol chooses to standardize.
How Do x402 and MPP Handle Payment Rails?
x402 was built around on-chain stablecoin payments, primarily USDC on Base and other supported networks. If your use case is crypto-native agents paying with stablecoins, x402 gives you a direct path to get there.
MPP takes a different approach: the protocol itself is payment-method agnostic. The core spec defines how a server and client negotiate, challenge, and settle, but the actual payment rail is a pluggable layer. Today, MPP ships with two production methods: Tempo (stablecoin payments) and Stripe (cards, wallets, and other traditional payment methods), and a server can advertise both simultaneously. The client picks whichever method it supports.
Anyone can define a new payment method by specifying a request schema and a payload schema. No approval from a foundation or intermediary needed. Payment methods compete on adoption, not on permission.
If you're building for a crypto-native audience, x402 gets you there fastest. If you're building for enterprise clients, traditional payment integrators, or mixed audiences, MPP's multi-rail support means you don't have to choose.
What Payment Models Do They Support?
x402 focuses on the "exact" payment model: one request, one payment, one response. This is clean, easy to reason about, and works well for discrete API calls.
MPP supports the same flow through its charge intent, and in fact, x402's exact flows map directly onto MPP charge, making the two protocols compatible at this layer.
But MPP also introduces sessions: a fundamentally different payment model for high-throughput use cases. With sessions, a client deposits funds into an escrow contract once, then makes many requests using signed vouchers off-chain. The server periodically settles the accumulated vouchers on-chain.
Here's a simplified illustration of each flow:
x402: One Request, One Payment
# Step 1: Call the API
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1
# Step 2: Server responds with payment challenge
HTTP/1.1 402 Payment Required
X-Payment-Challenge: {"amount": "0.001", "currency": "USDC", "address": "0x..."}
# Step 3: Client pays on-chain, retries with receipt
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1
X-Payment: {"txHash": "0x...", "signature": "0x..."}
# Step 4: Server verifies and responds
HTTP/1.1 200 OKMPP Session: Deposit Once, Make Thousands of Requests
# Step 1: Open a session (deposit funds to escrow once)
POST /mpp/sessions HTTP/1.1
{"amount": "10.00", "currency": "USDC", "method": "tempo"}
HTTP/1.1 201 Created
{"sessionId": "sess_abc123", "balance": "10.00"}
# Step 2: Make requests with signed vouchers (no on-chain tx per request)
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1
MPP-Session: sess_abc123
MPP-Voucher: {"amount": "0.0001", "nonce": 42, "sig": "0x..."}
HTTP/1.1 200 OK # Sub-100ms, no waiting for chain confirmationMPP sessions enable:
- Payments as small as $0.0001 per request
- Sub-100ms latency: no on-chain confirmation per request
- Near-zero per-request fees: only net settlement hits the chain
Why it matters: Pay-per-token LLM streaming, high-throughput data feeds, and real-time chain monitoring all become economically viable. Paying on-chain for every single interaction would cost more in gas than the data is worth. Sessions flip that calculus entirely, making micropayment-based access practical at scale.
What Protocol-Level Primitives Does Each Provide?
MPP bakes several production concerns into the protocol spec itself, so every implementation inherits them rather than reinventing them:
- Idempotency: safe retries without double-charging
- Expiration: challenges time out, preventing stale payments
- Request-body binding: SHA-256 digest prevents tampering between challenge and payment
- Replay protection: HMAC-bound challenge IDs
- Structured errors: RFC 9457 format for machine-readable error handling
- First-class receipts: standardized payment receipts for auditing
x402 handles some of these at the implementation level, but leaves the rest to individual developers. MPP standardizes them so every server and client speaks the same language out of the box, which matters when agents from different vendors need to interoperate reliably.
Does MPP Work Beyond HTTP?
x402 operates over HTTP. MPP also operates over HTTP, but adds an MCP (Model Context Protocol) transport binding.
This means MCP tool servers can monetize tool calls directly. An AI agent calling a paid tool gets a payment challenge in the tool response, pays, and retries, all within the MCP message flow. No OAuth. No account setup. No HTTP layer required.
Until now, monetizing AI tool calls required out-of-band billing or platform agreements. With MPP's MCP transport, a developer can publish a paid tool that any MCP-compatible agent can discover, pay for, and use autonomously, with no human in the loop.
How Do They Compare on Standardization?
x402 is an open-source protocol with growing community adoption. It's battle-tested in production at Coinbase and increasingly supported across the ecosystem.
MPP's core, the Payment HTTP Authentication Scheme, is submitted as an IETF Internet-Draft, co-authored by Tempo and Stripe. Payment methods and intents are separate specs that anyone can author and publish independently. This mirrors how the web itself works: HTTP is standardized, but content types and auth schemes evolve independently.
An Internet-Draft is a working document, not yet a standards-track RFC, but IETF submission signals intent toward long-term interoperability and stability.
Are x402 and MPP Compatible?
Yes. MPP is backwards compatible with x402. The core x402 "exact" payment flow maps directly onto MPP's charge intent, so MPP clients can consume existing x402 services. If you've already built on x402, MPP extends what you have rather than replacing it.
Start Building with Alchemy
Alchemy supports both x402 and MPP across its API platform. That means your agents can access blockchain data (token balances, NFT metadata, transaction history, smart contract reads, price feeds, and more) and pay per request using either protocol. No API key required. No billing dashboard. Just a wallet and an HTTP call.
With x402, an agent authenticates via SIWE (Sign-In with Ethereum) or SIWS (Sign-In with Solana), pays with USDC on Base, and gets access to Alchemy's endpoints. With MPP, the same agent can negotiate across payment methods (stablecoins via Tempo, cards via Stripe) and use sessions for high-throughput workloads like indexing pipelines or real-time chain monitoring.
What you can build:
- Autonomous blockchain agents that query on-chain data and pay for every call, no human provisioning required
- Multi-chain data pipelines that pull from Ethereum, Base, Polygon, Solana, and more, paying per request at sub-cent rates via MPP sessions
- AI-powered wallets and copilots that fetch portfolio data, simulate transactions, and monitor addresses, all self-funded
- MCP tool servers that wrap Alchemy endpoints as paid tools, letting any MCP-compatible agent access blockchain infrastructure on demand
Ready to start? Head to alchemy.com/agents to explore the platform and start building agents that pay for their own infrastructure.
FAQ
Can I use both x402 and MPP together?
Yes. Since MPP's charge intent is backwards compatible with x402, you can support both simultaneously. A server can advertise both protocols and let clients choose whichever they support.
Which should I choose?
If you're building a crypto-native agent that pays with stablecoins and want the simplest path to production, start with x402. If you need multi-rail payment support, sessions for high-throughput workloads, MCP transport integration, or standardized protocol primitives, MPP is the better fit. You don't have to abandon your x402 investment to get there.
Is x402 being replaced by MPP?
No. MPP is designed to be compatible with x402, not to replace it. Think of MPP as an evolution that adds capabilities x402 didn't set out to provide. The x402 community continues to grow independently.
What payment methods does MPP support today?
MPP ships with two production payment methods: Tempo for stablecoin payments and Stripe for cards, wallets, and other traditional payment methods. Because payment methods are pluggable, anyone can define and publish a new one by specifying a request schema and a payload schema.
Do I need to run my own infrastructure to use these protocols?
No. Alchemy supports both x402 and MPP across its API platform, so you can start building agents that pay for blockchain data without running any payment infrastructure yourself. Head to alchemy.com/agents to get started.
Alchemy Newsletter
Be the first to know about releases
Sign up for our newsletter
Get the latest product updates and resources from Alchemy
By entering your email address, you agree to receive our marketing communications and product updates. You acknowledge that Alchemy processes the information we receive in accordance with our Privacy Notice. You can unsubscribe anytime.
Related articles
The Infrastructure Behind the World's Leading Blockchain Applications
Alchemy processes billions of blockchain requests daily for companies like Visa, Stripe, and Coinbase. Here's how eight years of engineering built the infrastructure behind $150B+ in annual onchain transactions across 100+ chains.
Blockchain RPC Infrastructure Evaluation Guide for Enterprises
Choosing the wrong blockchain RPC provider can mean costly migrations and poor performance. Use this enterprise evaluation framework to ask the right questions before you commit.
What are Zero-Knowledge Rollups (ZK-rollups)?
Explore ZK-rollups, a fast-growing L2 design. Learn how they cut costs, enable instant finality, and boost security.