Editor's Note: Regarding the question of how agents should pay, x402 and MPP propose two almost opposite approaches.

x402 follows a minimalist protocol approach: embedding payment directly into HTTP requests, achieving pay-per-request in the simplest way. No accounts, no intermediaries, it resembles the open, permissionless design of the early internet, suitable for long-tail developers and decentralized scenarios.

MPP, on the other hand, is a maximalist system: addressing high-frequency transactions, risk control, and fiat currency integration through sessions, streaming payments, and a compliance framework. It does not pursue purity but prioritizes meeting real-world commercial needs, making it more suitable for enterprise-level and large-scale applications.

The difference between the two is essentially two solutions to the same problem: whether to make payment a part of the protocol or a layer of the system.

Precisely because of this, they are not entirely competitive but rather operate in different segments: x402 covers the long-tail needs of the open web, while MPP handles high-frequency and commercialized traffic. In an yet-to-be-formed Agent economy, this divergence is perhaps inevitable.

Below is the original text:

The HTTP status code 402, defined in the HTTP/1.1 specification since the late 1990s, has been waiting for a purpose. Its meaning is "Payment Required." The original idea was to embed payment capabilities into the protocol layer of the Web, enabling machines to purchase resources as easily as requesting a web page.

But this vision largely remained unrealized. Over the years, this status code has only occasionally appeared in edge cases, such as Shopify's rate-limiting responses or Apple Mobile Me's billing errors, but no one ever truly built the micro-payment future it hinted at. Instead, credit cards, subscription paywalls, and API Key mechanisms took over—systems essentially designed for humans who operate manually.

Today, this future has two competing implementation paths, both announced on the same day. Next, I want to outline what they are, their differences, and why Stripe is betting on both routes simultaneously.

x402: A Simpler Solution

Coinbase officially launched x402 in May 2025. Its core idea is almost radically minimalist. A client requests a resource; the server returns an HTTP 402, informing the client: how much to pay, which token to use, and on which chain to complete the payment. The client completes the payment on-chain, attaches the payment proof to the re-initiated request, and the server then delivers the resource.

It's that simple. No account system, no API Key, no subscription mechanism. Just one HTTP request round trip with a payment inserted in the middle.

Now, Stripe natively supports x402 in its payment system, allowing merchants to receive such payments directly through their existing backend. However, in essence, x402 is still a protocol led by Coinbase, governed by the x402 Foundation co-founded by Coinbase and Cloudflare in September 2025. The protocol is fully open source (Apache 2.0 license) and provides multi-language SDKs including TypeScript, Go, and Python.

In terms of support, Coinbase's official documentation shows that ERC-20 payments are currently supported on Base, Polygon, and Solana. Meanwhile, the ecosystem is exploring extensions to other chains like Avalanche, Sui, and Near, but maturity varies.

As for adoption data, this part is slightly more complex. Coinbase states that x402 has processed over 50 million transactions through its Agentic Wallet infrastructure. That sounds impressive, but according to CoinDesk on March 11th, citing Artemis' on-chain analysis data: daily transaction volume is about 131,000, with a value of approximately $28,000, and the average payment per transaction is only about $0.20. About half of these appear to be test or gamified behavior rather than real commercial transactions.

But this might not be a bad thing. Because this protocol is designed for a market that doesn't truly exist yet—a world where AI agents make micro-payments (even below 1 cent) for API calls and data queries. And the merchants serving this market are just beginning to emerge.

For example, Google's Agentic Payments Protocol (AP2, part of the A2A framework) has integrated x402; Lowe's Innovation Labs demonstrated a demo where an AI agent can complete the entire process from product discovery and research to ordering in one flow. Also, World (initiated by Sam Altman) released AgentKit this week, adding human identity verification capabilities to x402 wallets.

The core assumption behind this is: if you make payment as lightweight as an HTTP request, use cases will naturally emerge. Whether this holds true remains to be seen.

MPP: The Full-Stack Solution

Stripe and Tempo have chosen a different path. The Machine Payments Protocol (MPP) was released today alongside the Tempo mainnet launch. Unlike x402, which is a lightweight wrapper on existing blockchains, MPP is specifically designed for the scenario of high-frequency trading by agents.

Its core mechanism is sessions. Instead of initiating an on-chain transaction for every resource request, an agent can first authorize a spending limit once and then make continuous micro-payments within that limit. If you are an AI that needs to query data sources thousands of times per hour, you absolutely do not want to sign and broadcast an on-chain transaction each time. Sessions are designed to solve this problem.

The Tempo chain is also built around this need. It supports tens of thousands of transactions per second, has sub-second confirmation times, and has no native gas token. Users can pay fees directly with stablecoins, eliminating the hassle of having to buy some random token just to make a transfer.

Another component worth understanding is: Stripe's Agentic Commerce Suite includes Shared Payment Tokens (SPTs). This is not part of MPP itself but is Stripe's extension mechanism that can work alongside it. SPTs allow an agent to securely pass a user's bank card or wallet credentials to a merchant without exposing the real data. These credentials are single-use and time-limited, essentially a programmable, self-destructing authorization. In practice, this means an agent paying via MPP can use either USDC on Tempo or the user's linked Visa card, or even a combination of both.

According to the Tempo mainnet launch blog, its partners include Anthropic, DoorDash, Mastercard, Nubank, OpenAI, Ramp, Revolut, Shopify, Standard Chartered, and Visa. The Block reported that the MPP payment directory already includes over 100 services at launch, including Alchemy, Dune Analytics, Merit Systems, and Parallel Web Systems. Matt Huang, co-founder of Tempo and Paradigm, told Fortune in an interview that this field is still in its early stages, and MPP is designed to eventually scale to environments beyond Tempo.

Why Stripe Supports Both

If you are already integrated with Stripe, the most practical answer is: you don't need to choose between them.

Stripe supports x402 and MPP through two separate integration paths, rather than abstracting them into a unified interface. For x402, its documentation mainly covers generating deposit addresses, monitoring the chain, and settling funds into Stripe accounts—you are responsible for returning the 402 response, while the underlying crypto payment infrastructure is handled by Stripe. It supports USDC on Base for now, with more to come. For MPP, merchants can receive session-based streaming payments through the same PaymentIntents API.

Stripe's Agentic Commerce Suite, released in December 2025, is built on top of these two payment rails. Merchants just need to upload their product catalog, select the AI agents they want to connect with, and Stripe handles product discovery, checkout flow, fraud prevention, and tax processing. Currently, URBN, Etsy, Coach, Kate Spade, and Ashley Furniture are already using it, and platforms like Wix, WooCommerce, BigCommerce, Squarespace, and commercetools have completed integration.

The strategy is actually quite clear: control the abstraction layer and let the underlying protocols compete freely.

Comparison

Macroscopically, these two protocols are doing the same thing: enabling machines to pay for resources via HTTP. But the real differences lie in the details.

x402 (Led by Coinbase) vs MPP (Stripe + Tempo)

Standardization
x402: Fully open source (Apache 2.0), promoted by the x402 Foundation with multi-party participation (Coinbase, Cloudflare, Visa, Google).
MPP: Open standard, co-defined by Stripe and Tempo, part of the Stripe Agentic Commerce Suite.

HTTP Mechanism
x402: Revives HTTP 402, initiates requests via PAYMENT-REQUIRED header, uses PAYMENT-SIGNATURE for retry.
MPP: Also uses a challenge-response mechanism, but employs the Payment HTTP Authentication Scheme (IETF draft), binding challenge ID via HMAC.

Payment Rails
x402: Designed to be chain-agnostic, currently supported on Base, Polygon, Solana, exploration ongoing for other chains.
MPP: Based on the Tempo blockchain—an L1 optimized for payments, supporting 10k+ TPS, sub-second confirmation, no native gas token; long-term goal is cross-chain compatibility.

Payment Methods
x402: Pure stablecoin, fully on-chain.
MPP: Supports USDC on Tempo + SPT (Stripe's mechanism), enabling crypto-fiat hybrid (bank cards, wallets, BNPL).

Settlement
x402: On-chain settlement (~200ms to several seconds), validation and settlement handled by facilitators like Coinbase.
MPP: Tempo sub-second confirmation, automatic booking and compliance handling by Stripe.

Merchant Integration
x402: Open-source middleware (Express, Hono, Next.js, etc.), can be self-built or use a facilitator.
MPP: Direct integration with Stripe's PaymentIntents API, built-in risk control, tax, refunds, reporting.

Core Innovation
x402: Extreme simplicity, no vendor lock-in, similar to the Unix philosophy for payments.
MPP: High throughput + fiat integration, streaming payments via sessions, micro-payment aggregation, and programmable spending control based on SPTs.

Key Partners
x402: Coinbase, Cloudflare, Google (A2A/AP2), Visa, World, Anthropic (MCP).
MPP: Stripe, Visa, Lightspark, Anthropic, DoorDash, Mastercard, OpenAI, Shopify, Revolut, Standard Chartered.

x402 is more like the go-to choice when building open systems: independent developer APIs, decentralized data markets, or any service that doesn't want to rely on a payment processor. Its specification can be written in a whitepaper, and integration only requires a middleware and a wallet address. This purity is attractive—although the crypto-only limitation also means its audience is narrower.

MPP is a completely different paradigm. If your agent needs to make hundreds or even thousands of transactions in a single session without going on-chain each time, then it is the more reasonable choice. The session mechanism keeps most interactions off-chain until final settlement; Stripe's compliance system handles risk and taxes; and the hybrid model allows agents to not only use stablecoins but also directly call the user's Visa and other payment methods. It's less elegant but more practical.

Interestingly, they are not entirely competitive. x402 covers long-tail open scenarios, MPP covers enterprise-level high-frequency traffic. Stripe's strategy is also clear: don't bet on a single protocol, but ensure that no matter which path wins, funds ultimately flow into Stripe's account system.

Reality Check: Where are we now?

Honestly, there is almost no real scaled transaction volume yet.

According to Coinbase's x402 release information, early partners include Hyperbolic (GPU inference payment) and Anthropic (MCP protocol integration). Stripe's blog mentions agent scenarios paying per API call (e.g., CoinGecko). Tempo's launch directory has 100+ services. Cloudflare's Agents SDK natively supports x402, and some small projects on Base L2 are trying to use x402 as a paid gateway.

But overall: transaction volume is small, the number of merchants is limited, and most activity is still in the trial phase.

This is actually not surprising. Any new payment infrastructure starts like this. So-called partner lists sometimes have a big gap between signing a letter of intent and being live in production, and these announcements usually don't distinguish particularly.

What's more noteworthy are the heavyweight players behind the infrastructure. Stripe processed $1.9 trillion in payments in 2025, with total volume growing 34% year-over-year. Meanwhile, Coinbase, Cloudflare, Visa, Google, and Tempo's entire partner network have entered the field.

In other words, the tracks are laid. The only question left is: in 2026, will AI agents really need to transact on these tracks at scale? Or is this more like laying fiber optics in 1998—the demand isn't here yet, but the infrastructure is built first.

So which one to choose?

If you are building an open, permissionless system—x402 is the more natural choice. No platform registration, no payment processor integration, just import middleware, bind a wallet, and start receiving payments. The cost is: compliance, risk control, and fiat settlement must be handled yourself.

If you are already within the Stripe ecosystem and want to接入 agent traffic—MPP is more suitable. Sessions, streaming payments, crypto+fiat hybrid, and a full compliance system are essentially more like a configuration upgrade than a system overhaul.

If you only care about one thing: no matter which protocol the agent uses, I can get paid. Then the answer is simply: use Stripe. It supports both.

HTTP 402 finally has a use. It just took about 27 years.