Author: Nick Sawinyh, defiprime.com
Compiled by: Peggy, Blockbeats
Editor's note: Regarding the issue of how Agent pays, x402 and MPP provide two almost opposite paths.
x402 follows protocol minimization: embedding payments directly into HTTP requests, achieving pay-per-request in the simplest way. No accounts, no intermediaries, more like the early open and permissionless design of the internet, suitable for long-tail developers and decentralized scenarios.
MPP is the system maximization: solving high-frequency trading, risk control, and fiat currency access issues through sessions, streaming payments, and compliance systems. It does not pursue purity but prioritizes meeting real business needs, making it more suitable for enterprise-level and scalable applications.
The differences between the two are essentially two solutions to the same problem: should payments be part of the protocol or a layer of the system.
Because of this, they are not completely competitive but are more like distributions across different intervals, with x402 covering the long-tail demand of open networks, and MPP handling high-frequency and commercial traffic. In an unformed Agent economy, this differentiation may be inevitable.
The original text is as follows:
HTTP status code 402 has been waiting for a use case since it was defined in the HTTP/1.1 specification in the late 1990s. Its meaning is 'Payment Required.' The original idea was to embed payment capability into the protocol layer of the Web, allowing machines to buy resources like they request web pages.
However, this vision has largely not been realized. Over the years, this status code has only occasionally appeared in some edge cases, such as Shopify's rate-limiting response, Apple Mobile Me's billing errors, etc., yet no one has truly built the micro-payment future it implies. Instead, there are credit cards, subscription payment walls, and API Key mechanisms, all of which are essentially designed for humans with manual operations.
And today, this future has seen two competing implementation paths emerge, both released on the same day. Next, I want to outline what they are, what the differences are, and why Stripe is betting on both paths simultaneously.
x402: a simpler option
Coinbase officially launched x402 in May 2025, with a core idea that can be described as radical simplicity. The client requests a resource; the server returns HTTP 402 and informs the client: how much payment is needed, which token to use, and on which chain to complete the payment. After completing the payment on-chain, the client attaches the payment proof to the re-initiated request, and the server promptly delivers the resource.
It's that simple. No account system, no API Key, and no subscription mechanism. Just a round trip of an HTTP request with a payment inserted in between.
Today, Stripe has provided native support for x402 in its payment system, allowing merchants to receive such payments directly through their existing backend. However, fundamentally, x402 is still a protocol led by Coinbase, governed by the x402 Foundation, which was jointly initiated with Cloudflare in September 2025. The protocol is fully open source (Apache 2.0 license) and provides multilingual SDKs in TypeScript, Go, and Python.
In terms of support scope, Coinbase's official documentation shows that ERC-20 payments are currently supported on Base, Polygon, and Solana. At the same time, the ecosystem is exploring extending this to other chains like Avalanche, Sui, and Near, but with varying degrees of maturity.
Looking at adoption data, this part is a bit more complex. Coinbase states that x402 has processed over 50 million transactions through its Agentic Wallet infrastructure. It sounds impressive, but according to on-chain analysis data from Artemis cited by CoinDesk on March 11: the daily transaction volume is about 131,000, with a total amount of about $28,000, and the average payment per transaction is only about $0.20, of which about half seems more like testing or gamified behavior rather than real commercial transactions.
But this may not be a bad thing. Because this protocol was originally designed for a market that has not yet truly existed, a world where AI agents conduct micro-payments (even less than 1 cent) for API calls and data queries. And 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 has also demonstrated a demo: AI agents can complete the entire process from product discovery and research to placing an order in one workflow. At the same time, World (initiated by Sam Altman) released AgentKit this week, adding human identity verification capabilities to the x402 wallet.
The core assumption behind it is: as long as payments can be made as lightweight as HTTP requests, application scenarios will naturally emerge. As for whether this holds true, it remains to be seen.
MPP: full-stack solution
Stripe and Tempo have chosen a different path. The Machine Payments Protocol (MPP) was launched today alongside the Tempo mainnet. Unlike x402, which serves as a lightweight encapsulation layer on existing blockchains, MPP is specifically designed for high-frequency trading scenarios involving intelligent agents.
Its core mechanism is sessions. Unlike having to initiate an on-chain transaction for each resource request, agents can authorize a spending limit at once and then continuously make micro-payments within that limit. If you are an AI that needs to query thousands of data sources every hour, you definitely do not want to sign and broadcast an on-chain transaction every time, and sessions are designed to solve this problem.
The Tempo chain is also built around this demand. It supports tens of thousands of transactions per second, has sub-second confirmation times, and does not have a native gas token. Users can directly use stablecoins to pay transaction fees, eliminating the cumbersome process of first purchasing some random token for transfers.
Another component worth understanding is that Stripe's Agentic Commerce Suite includes Shared Payment Tokens (SPTs). This is not part of MPP itself but an expansion mechanism from Stripe, which can be used in conjunction. SPT allows agents to securely pass users' bank card or wallet credentials to merchants without exposing real data. These credentials are limited to single transactions and have a time constraint, which can be understood as a programmable, self-destructing authorization. In practical use, this means that 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 blog disclosure of Tempo's mainnet launch, its partners include Anthropic, DoorDash, Mastercard, Nubank, OpenAI, Ramp, Revolut, Shopify, Standard Chartered, and Visa. (The Block) also reported that there were over 100 services in the payment catalog when MPP launched, including Alchemy, Dune Analytics, Merit Systems, and Parallel Web Systems. Matt Huang, co-founder of Tempo and Paradigm, stated in an interview with (Fortune) that this area is still in its early stages, and the design goal of MPP is to extend to more on-chain environments beyond Tempo in the future.
Why does Stripe support both?
If you are already integrated with Stripe, the most practical answer is: you do not need to choose between the two.
Stripe supports both x402 and MPP through two independent integration paths, rather than abstracting them into a unified interface. For x402, its documentation mainly covers generating recharge addresses, on-chain monitoring, and the process of settling funds to Stripe accounts—you are responsible for returning a 402 response, while Stripe handles the underlying crypto payment infrastructure. Currently, USDC is supported on Base and will be expanded in the future. For MPP, merchants can receive session-based streaming payments through the same PaymentIntents API.
The Agentic Commerce Suite released by Stripe in December 2025 builds on these two payment tracks. Merchants only need to upload a product catalog, select the AI agents they wish to connect with, and Stripe will handle product discovery, checkout processes, anti-fraud measures, and tax processing. Currently, URBN, Etsy, Coach, Kate Spade, and Ashley Furniture are already using it, and platforms such as Wix, WooCommerce, BigCommerce, Squarespace, and commercetools have also completed integration.
Its strategy is quite clear: control the abstraction layer and let the underlying protocols compete freely.
In comparison
From a macro perspective, these two protocols are doing the same thing: allowing machines to pay for resources via HTTP. However, the real differences are reflected in the details.
x402 (led by Coinbase) vs MPP (Stripe + Tempo)
Standardization
x402: fully open source (Apache 2.0), driven by the x402 Foundation to promote multi-party participation (Coinbase, Cloudflare, Visa, Google).
MPP: open standard, jointly developed by Stripe and Tempo, part of Stripe's Agentic Commerce Suite.
HTTP mechanism
x402: Reviving HTTP 402, initiating requests through the PAYMENT-REQUIRED header, and completing retries using PAYMENT-SIGNATURE.
MPP: also adopts a challenge-response mechanism but uses the Payment HTTP Authentication Scheme (IETF draft) and binds the challenge ID through HMAC.
Payment infrastructure (Rails)
x402: designed to be chain-agnostic, and now has support on Base, Polygon, and Solana, with other chains still being explored.
MPP: based on the Tempo blockchain—a layer 1 optimized for payments, supporting over 10,000 TPS, sub-second confirmations, and no native gas token; the long-term goal is to achieve cross-chain compatibility.
Payment methods
x402: pure stablecoin, fully on-chain.
MPP: supports USDC + SPT (Stripe's mechanism) on Tempo, achieving a mix of crypto and fiat (bank cards, wallets, BNPL).
Settlement method
x402: settled on-chain (about 200ms to several seconds), verified and settled by facilitators such as Coinbase.
MPP: Tempo sub-second confirmation, Stripe automatically settles and handles compliance.
Merchant integration
x402: open-source middleware (like Express, Hono, Next.js, etc.), which can be self-built or use facilitators.
MPP: directly integrating with Stripe's PaymentIntents API, with risk control, tax, refunds, and reporting all built-in.
Core innovation
x402: extremely simple, vendor-neutral, resembling the Unix philosophy in the payment field.
MPP: high throughput + fiat integration, achieving streaming payments, micro-payment aggregation, and programmable spending control based on SPT through sessions.
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 your first choice when building an open system: independent developer APIs, decentralized data markets, or any service that does not want to rely on payment processors. Its specification could be written into a white paper, and integration only requires middleware and a wallet address. This purity is very attractive—though the limitations of pure crypto also mean its audience is narrower.
MPP is a completely different paradigm. If your agent needs to conduct hundreds or even thousands of transactions in a single session without wanting to go on-chain every time, then it is a more reasonable choice. The session mechanism keeps most interactions off-chain until the final settlement; Stripe's compliance system takes care of risk control and tax; while the hybrid model of SPT allows agents to not be limited to stablecoins and directly utilize users' Visa and other payment methods. It may not be as elegant, but it is closer to reality.
Interestingly, they are not completely competitive. x402 covers long-tail open scenarios, while MPP covers enterprise-level high-frequency traffic. Stripe's strategy is also very clear: not to bet on a single protocol, but to ensure that regardless of which path wins, funds ultimately flow into Stripe's account system.
The reality is: where has it developed to now?
To be honest, there are currently almost no truly large-scale transactions.
According to Coinbase's x402 release information, early partners include Hyperbolic (GPU inference payments) and Anthropic (MCP protocol integration). Stripe's blog mentions agent scenarios that pay per API call (e.g., CoinGecko). There were over 100 services in the catalog when Tempo launched.
However, overall: transaction volumes are small, the number of merchants is limited, and most activities remain at the experimental stage.
This is not surprising. Any new payment infrastructure starts this way. The so-called partner list sometimes sees a significant gap between signing a letter of intent and actually going live, and these releases usually do not distinguish much.
What is more noteworthy is the heavyweight participants behind the infrastructure. Stripe processed $1.9 trillion in payments in 2025, a year-on-year increase of 34%. Meanwhile, a complete network of collaborations involving Coinbase, Cloudflare, Visa, Google, and Tempo has entered the arena.
That is to say, the tracks have already been laid. The only remaining question is: in 2026, will AI agents really need to conduct large-scale transactions on this track? Or is this more like laying fiber optics in 1998—demand hasn't arrived yet, but infrastructure is ahead.
So which one should you choose?
If you are building an open, permissionless system—x402 is the more natural choice. No need to register on a platform, no need to interface with payment processors; simply import middleware and bind a wallet to receive payments. The trade-off is that compliance, risk control, and fiat settlement all need to be handled by yourself.
If you are already within the Stripe ecosystem and wish to connect with agent traffic—MPP is more suitable. Sessions, streaming payments, fiat + crypto mix, and a complete compliance system are essentially more like a configuration upgrade rather than a system overhaul.
If you only care about one thing: regardless of which protocol the agent uses, I can receive money. The answer is actually: use Stripe. It supports both sides.
HTTP 402 has finally come into play. It just had to wait almost 27 years.