MPP vs x402: Which Agent Payment Protocol to Use?

Two payment protocols shipped within months of each other, both reviving the same 30-year-old HTTP status code (402 Payment Required) to let AI agents pay programmatically. Both are open standards. Both are production-ready. Both are backed by Stripe in one way or another. And they solve overlapping but not identical problems.

This guide compares MPP (Machine Payments Protocol, Stripe + Tempo, March 2026) and x402 (Coinbase, V2 launched December 2025) on architecture, payment rails, cost, production readiness, and real use cases. At the end, we'll show which protocol to pick for which scenarios, and explain why most serious agent platforms support both.

The TL;DR

The shared foundation: HTTP 402

Both protocols work the same way at the transport layer.

An agent requests a resource. The server responds with HTTP 402 Payment Required and payment instructions (amount, currency, destination). The agent signs and attaches a payment, retries the request, and gets the resource.

The HTTP status code 402 has been reserved in the HTTP spec since 1997 and was never widely implemented. x402 and MPP are the two serious attempts at turning it into a real protocol, driven by a new category of user (AI agents) that doesn't work with traditional checkout forms.

The difference is what happens after the 402 response:

x402: Agent signs an on-chain payment, attaches it to the retry request, server verifies on-chain and delivers.

MPP: Agent selects a payment method (stablecoin, fiat via SPT, card, or Lightning), handles it through the appropriate rail (Tempo for stablecoin, Stripe for fiat/card, Lightspark for BTC), and resubmits with a credential.

Same HTTP shape. Different payment infrastructure underneath.

MPP in detail

MPP is Stripe's bet that agents will pay across multiple rails, not just crypto. It was designed with Tempo, an EVM-compatible blockchain that Stripe built specifically for payment primitives. Tempo has no native gas token - fees are paid in the stablecoin being transacted, through an integrated AMM.

What MPP is built for:

• Agents that pay for a mix of APIs, services, and physical goods
• Integration with existing Stripe accounts (payments flow into your normal balance)
• Enterprise financial infrastructure (tax calculation, fraud protection, refunds, accounting)
• Sessions model: pre-authorize a spending limit once, stream many micropayments
• Multi-rail from day one (stablecoin + fiat + cards + BTC Lightning via extensions)

Example 402 response with MPP:

HTTP/1.1 402 Payment Required
Content-Type: application/json
WWW-Authenticate: tempo realm="zinc" charge="ch_..." amount="25.99" currency="usd"
WWW-Authenticate: stripe realm="zinc" charge="ch_..." amount="25.99" currency="usd"

{
  "error": {
    "code": "payment_method_required",
    "details": {
      "methods": [
        { "method": "tempo", "amount": "25.99", "currency": "usd" },
        { "method": "stripe", "amount": "25.99", "currency": "usd" }
      ]
    }
  }
}

Services can advertise multiple rails. Agents pick what they can pay with.

Production use cases:

• Zinc: programmatic orders at Amazon, Walmart, Target, 50+ retailers
• Browserbase: headless browser sessions
• Parallel Web Systems: per-API-call web access
• Prospect Butcher Co.: sandwich orders in NYC
• PostalForm: print and mail physical letters
• Stripe Climate: programmatic carbon contributions

For a full walkthrough, read What Is MPP? A Developer's Guide to Machine Payments.

x402 in detail

x402 is Coinbase's bet that stablecoin payments are sufficient for the machine economy, and that the HTTP-native experience beats traditional PSP infrastructure for agents.

What x402 is built for:

• Fully crypto-native agents that already hold wallets
• Ultra-low-value transactions where Stripe's 2.9% + 30¢ is too high
• Services that don't need tax, fraud, or refund infrastructure
• Maximum neutrality (x402 Foundation is co-governed with Cloudflare, not controlled by a single vendor)
• One-line integration for servers that accept it

Example x402 middleware (Node.js):

import { paymentMiddleware } from 'x402-express';

app.use(
  paymentMiddleware({
    'GET /weather': {
      accepts: [
        { network: 'base', asset: 'USDC', amount: '0.01' },
        { network: 'solana', asset: 'USDC', amount: '0.01' },
      ],
      description: 'Real-time weather data',
    },
  })
);

A service adds one middleware line, specifies accepted networks and assets, and it now accepts agent payments. No account creation, no API key issuance, no merchant registration.

Production stats (last 30 days, as of April 2026):

• 75.41M transactions
• $24.24M volume
• 94.06K buyers
• 22K sellers

x402 adopters: Stripe, AWS, Messari, Alchemy, Nansen, Vercel, Cloudflare, World. Stripe specifically integrated x402 for USDC on Base in February 2026, then launched MPP alongside it in March.

Where they overlap

Both protocols handle the core case of "agent calls an API, pays, gets response" equally well. If all you need is:

• An agent that pays for API calls
• Payments in USDC
• No enterprise financial controls
• Low-value per-request pricing

Either works. x402 might be simpler (single rail, single protocol); MPP gives you a migration path to fiat later.

Where they diverge

Payment rails

x402: Stablecoins only. If an agent doesn't hold USDC (or equivalent), it can't pay. Great for crypto-native use cases, but limits the user population.

MPP: Multi-rail from day one. An agent with a Stripe Shared Payment Token can pay MPP services in fiat. An agent holding USDC on Tempo can pay the same services in stablecoin. Cards via Visa's extension. Bitcoin via Lightspark. More rails, more agents can use it.

For services like Zinc that need to bill across both crypto-native agents and fiat-funded corporate buyers, the multi-rail capability is decisive.

Enterprise financial controls

x402: Minimal. You get on-chain settlement. Tax, fraud prevention, refunds, accounting integrations are all on you. For most crypto-native builders, this is fine.

MPP: Inherits Stripe's full stack. Payments appear in the Stripe Dashboard. Tax calculated automatically. Fraud scoring runs. Refunds go through the same flow as any Stripe charge. Accounting reconciliation works out of the box.

If you're running a business that needs tax reporting and refund flows, MPP removes weeks of integration work.

Cost structure

x402: Zero protocol fees. Pay only on-chain gas (fractions of a cent on L2s like Base). Cheapest option for crypto-native micropayments.

MPP: Zero protocol fees on-chain for Tempo stablecoin settlement. Standard Stripe processing fees apply to fiat/card SPTs (2.9% + 30¢ typically). Lightspark and Visa have their own fee structures.

For a pennies-per-request API, x402 is materially cheaper. For physical goods and services where the fee is a small percentage of the transaction, MPP's Stripe integration value outweighs the fee difference.

Sessions model

x402: One HTTP round trip, one on-chain payment. Fine for infrequent requests. Expensive for high-frequency streaming workloads (each payment is a blockchain transaction, gas costs add up).

MPP: Sessions. Pre-authorize a spending cap once, stream many micropayments within that cap without per-request on-chain overhead. Critical for agents that make thousands of tiny calls (LLM inference, streaming data, continuous compute).

If your service bills per-token or per-millisecond, MPP's session model is a significant advantage.

Neutrality and governance

x402: Coinbase-created, now co-governed with Cloudflare under the x402 Foundation. Broadly adopted (Stripe, AWS, Vercel, Cloudflare, Alchemy). Neutral in theory and practice.

MPP: Stripe + Tempo. Tempo is a Stripe-adjacent chain. Neutrality is weaker - you're accepting Stripe's infrastructure as a dependency.

For builders who distrust Stripe lock-in, x402 is the more neutral choice. For builders already on Stripe, MPP's integration is a feature, not a bug.

When to use which

Use x402 if:

• Your agents pay for APIs, compute, or data feeds
• You want zero protocol fees and crypto-native settlement
• You're building in the Coinbase/Base/Ethereum ecosystem
• You don't need fiat, card, or Lightning support
• Simplicity and neutrality matter more than enterprise features

Use MPP if:

• Your agents pay for a mix of APIs, services, and physical goods
• You need fiat, cards, or Bitcoin support alongside stablecoins
• You're already on Stripe and want a unified dashboard
• You need enterprise financial controls (tax, fraud, refunds)
• You have high-frequency streaming workloads that benefit from sessions

Use both if:

• You're an infrastructure provider and want to serve all agent types
• You're a service accepting payments (supporting both maximizes reachable agents)
• You're building a shopping agent that needs maximum flexibility

Stripe supports both MPP and x402 in their own payment infrastructure. Most serious agent platforms support both on the accepting side. For client-side agents, you can often pick one based on your wallet and integration preferences.

What neither protocol solves

Both protocols are about paying for something. Neither handles what happens after the payment, especially when that something is a real-world physical good.

Neither MPP nor x402 can place an order at Amazon, Walmart, Target, or any major retailer on its own. They handle the payment handshake between the agent and a service. If the service happens to be a checkout flow at a retailer, great - but you still need someone to run the checkout.

That's why execution-layer infrastructure like Zinc exists. Zinc accepts MPP for retail orders and translates the payment into real orders placed at 50+ retailers. The agent sends an MPP request; Zinc handles the retailer-specific checkout, bot protection, account management, and shipping.

You can think of it as a layered stack:

• Authorization layer: AP2 proves the user approved the transaction
• Checkout layer: ACP handles merchant-side cart management
• Protocol layer: x402 or MPP handles the agent-to-service payment handshake
• Execution layer: Zinc (and similar providers) handle the retailer-specific order placement

No layer replaces the others.

Bottom line

x402 and MPP are cousins, not competitors. They share HTTP 402 as the foundation and diverge on what they're optimized for.

x402 is the right choice for pure crypto-native, zero-fee, low-friction API micropayments. MPP is the right choice for multi-rail, enterprise-friendly, session-based commerce that includes physical goods and services.

For most serious builders, the practical answer is support both. Stripe does. Zinc supports MPP for retail orders. Services that want maximum agent reach accept both protocols at their 402 boundaries.

To see MPP placing a real retail order, try agent.zinc.com. To learn more about MPP specifically, read What Is MPP? A Developer's Guide to Machine Payments. For the broader context on where both protocols fit in the agentic commerce stack, read Agentic Commerce in 2026: The Complete Developer Guide. To build something that uses these protocols end-to-end, follow our AI shopping agent tutorial.

Frequently Asked Questions

Are MPP and x402 competing protocols?

They overlap but aren't direct competitors. Both revive HTTP 402 for agent payments. x402 is stablecoin-only and fully crypto-native. MPP is multi-rail (stablecoin + fiat + cards + Lightning) with Stripe's enterprise financial infrastructure. Most serious agent platforms support both.

Which protocol is cheaper?

x402 is cheaper for pure crypto micropayments - zero protocol fees, only on-chain gas (fractions of a cent on L2s). MPP charges no protocol fees for Tempo stablecoin settlement but adds Stripe's standard processing fees (2.9% + 30¢) on fiat/card payments.

Does Stripe support both protocols?

Yes. Stripe integrated x402 for USDC on Base in February 2026, then launched MPP with Tempo in March 2026. Stripe's stated position is that both protocols serve different use cases and developers should support both.

Can I use MPP and x402 on the same service?

Yes. A service can advertise both payment methods in its 402 response and let the agent pick. This maximizes the agent population that can successfully pay.

Which protocol do AI agents actually use today?

x402 has larger transaction volume right now (75M+ transactions, $24M+ volume in the last 30 days) due to earlier launch and crypto-native adoption. MPP launched with 100+ integrated services including major enterprises (Visa, Anthropic, OpenAI, Shopify, Zinc) and is growing rapidly.

Which protocol should I support if I'm a service accepting agent payments?

Both, if your resources allow. If you can only support one: x402 for pure API and crypto-native services; MPP for services that need fiat, enterprise controls, or physical goods commerce.

Do I need either protocol to build an AI shopping agent?

Not strictly. You can use direct API keys and pre-configured billing. But if you want your agent to transact dynamically with services it discovers at runtime (without pre-provisioning), MPP or x402 is how that works. For physical goods specifically, pair either protocol with an execution layer like Zinc. Our AI shopping agent tutorial walks through the full pattern.