Understanding x402 and MPP in One Article: The Two Paths of Agent Payments

Original Article Title: Stripe's MPP vs. x402: What Actually Happened Today
Original Article Author: Nick Sawinyh, defiprime.com
Translation: Peggy, Blockbeats

Editor's Note: Regarding the issue of how Agent pays, x402 and MPP have taken two almost opposite paths.

x402 took the path of protocol minimization: embedding payments directly into HTTP requests, achieving request-to-pay in the simplest way possible. With no accounts, no intermediaries, it resembles the open and permissionless design of the early Internet, suitable for long-tail developers and decentralized scenarios.

MPP, on the other hand, maximizes the system: addressing high-frequency transactions, risk management, and fiat onramp issues through sessions, streaming payments, and a compliance framework. It does not pursue purity but prioritizes meeting real-world business needs, making it more suitable for enterprise-level and scalable applications.

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

It is for this reason that they are not in direct competition but more like occupying different segments, with x402 covering the long-tail needs of the open network and MPP handling high-frequency and commercial traffic. In a nascent Agent economy, this differentiation may be inevitable.

Below is the original article:

Since the late 1990s when HTTP status code 402 was defined in the HTTP/1.1 specification, it has been waiting for its moment. Its meaning is Payment Required. The original idea was to embed payment capabilities into the Web's protocol layer, allowing machines to purchase resources like requesting a web page.

However, this vision has largely not materialized. 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., but no one has truly built the micro-payment future it implies. Instead, we have credit cards, subscription-based paywalls, and API Key mechanisms, which are essentially designed for human-operated systems.

Today, this future has materialized into two competing implementation paths, both released on the same day. Next, I want to clarify what they are, their differences, and why Stripe is betting on both of these routes simultaneously.

x402: A Simpler Solution

In May 2025, Coinbase officially launched x402, whose core idea can be described as almost aggressively simple. A client requests a resource; the server responds with HTTP 402, informing the client of how much fee is required, which token to use, and on which chain to make the payment. The client completes the payment on the chain, attaches the payment receipt to a reinitiated request, and the server then delivers the resource.

That's it. No account system, no API Key, no subscription mechanism. Just a single round-trip HTTP request, with a payment in between.

Today, Stripe has natively supported x402 in its payment system, allowing merchants to directly receive such payments through their existing backend. However, fundamentally, x402 is still a protocol led by Coinbase, governed by the x402 Foundation established jointly by Coinbase and Cloudflare in September 2025. The protocol is fully open-source (Apache 2.0 licensed) and offers SDKs in multiple languages such as TypeScript, Go, and Python.

In terms of support, Coinbase's official documentation indicates that ERC-20 payments are currently supported on Base, Polygon, and Solana. Additionally, the ecosystem is exploring expanding it to other chains like Avalanche, Sui, and Near, among others, but with varying degrees of maturity.

Looking at adoption data, this part is a bit more complex. Coinbase has stated that x402 has processed over 50 million transactions through its Agentic Wallet infrastructure. While this may sound impressive, according to on-chain analytics data from Artemis cited by CoinDesk on March 11, the daily transaction volume is around 131,000 transactions, with a total amount of around $28,000, an average payment per transaction of only about $0.20, with roughly half of them seeming more like tests or gamified actions rather than actual commercial transactions.

However, this may not be a bad thing because the protocol was designed for a market that does not yet truly exist—a world of microtransactions (even below 1 cent) carried out by AI agents for API calls and data queries. The merchants serving this market are just beginning to emerge.

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

The core assumption behind it is: as long as we make payments as lightweight as an HTTP request, use cases will naturally emerge. Whether this is true remains to be seen.

MPP: Full-Stack Solution

Stripe and Tempo chose a different path. The Machine Payments Protocol (MPP) was released today alongside the Tempo mainnet. Unlike x402, which acts as a lightweight wrapper layer on top of an existing blockchain, MPP is designed specifically for the smart agent scenario of high-frequency transactions.

Its core mechanism is sessions. Unlike initiating an on-chain transaction for each request for resources, an agent can first authorize a spending limit in a single transaction and then continue with microtransactions within that limit. If you are an AI that needs to query thousands of data sources per 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 need. 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 pay transaction fees with stablecoins, eliminating the cumbersome step of having to purchase a random token before making 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 an extension mechanism of Stripe that can work in conjunction with it. SPTs allow an agent to securely pass a user's bank card or wallet credential to a merchant without exposing real data. These credentials are limited to a single transaction and have a time limit, serving as a programmable, self-destructing authorization. In practical use, this means an agent paying through MPP can use Tempo's USDC, a user's linked Visa card, or even a combination of both.

According to the Tempo mainnet launch blog post, its partners include Anthropic, DoorDash, Mastercard, Nubank, OpenAI, Ramp, Revolut, Shopify, Standard Chartered, and Visa. "The Block" reported that at the launch of MPP, the payment directory already had over 100 services, including Alchemy, Dune Analytics, Merit Systems, and Parallel Web Systems. Tempo's collaboration with Paradigm co-founder Matt Huang, in an interview with "Fortune," stated that this field is still in its early stages, and MPP is designed to potentially expand into more on-chain environments beyond Tempo in the future.

Why Stripe Supports Both

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

Stripe supports x402 and MPP through two separate integration paths instead of abstracting them into a unified interface. For x402, its documentation mainly covers the process of generating a recharge address, on-chain monitoring, and settling funds to the Stripe account—you are responsible for returning a 402 response, and Stripe handles the underlying encrypted payment infrastructure. Currently supported on Base is USDC, with future expansions planned. For MPP, merchants can use the same PaymentIntents API to receive session-based streaming payments.

Building on these two payment rails is Stripe's Agentic Commerce Suite, released in December 2025. Merchants only need to upload their product catalog, choose the AI agents they wish to integrate, and Stripe will take care of product discovery, checkout flows, anti-fraud, and tax handling. Currently, URBN, Etsy, Coach, Kate Spade, and Ashley Furniture are already using it, with platforms like Wix, WooCommerce, BigCommerce, Squarespace, and commercetools having completed integrations.

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

On Comparison

At a high level, these two protocols are doing the same thing: enabling machines to pay for resources via HTTP. However, the real differences lie in the details.

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

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

HTTP Mechanism
x402: Revives HTTP 402, initiates requests through the PAYMENT-REQUIRED header, and completes retries using PAYMENT-SIGNATURE.
MPP: Also uses a challenge-response mechanism but employs the Payment HTTP Authentication Scheme (an IETF draft) and binds the challenge ID with HMAC.

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

Payment Method
x402: Pure stablecoins, fully on-chain.
MPP: Supports USDC + SPT on Tempo (Stripe's mechanism), enabling a mix of crypto and fiat (credit cards, wallets, BNPL).

Settlement Method
x402: On-chain settlement (around 200ms to a few seconds), validated and settled by facilitators like Coinbase.
MPP: Sub-second finality on Tempo, Stripe auto-settlement with compliance handled.

Merchant Onboarding
x402: Open-source middleware (Express, Hono, Next.js, etc.), can be self-hosted or facilitated.
MPP: Direct integration with Stripe's PaymentIntents API, built-in risk management, tax handling, refunds, and reporting.

Core Innovation
x402: Extremely simple, vendor-agnostic, akin to the Unix philosophy in the payment space.
MPP: High throughput + fiat integration, enabling streaming payments, microtransaction aggregation through sessions, and programmable spending control based on SPT.

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

x402 seems more like the go-to solution when building open systems: indie developer APIs, decentralized data markets, or any service that prefers not to rely on payment processors. Its specification could fit into a single whitepaper, requiring just one middleware and a wallet address. This purity is quite appealing — although the limitations of being purely crypto also mean it has a narrower audience.

MPP, on the other hand, is a completely different paradigm. If your agent needs to perform hundreds or even thousands of transactions in a single session and you do not want each transaction to be on-chain every time, then it is a more reasonable choice. The session mechanism keeps most interactions off-chain until final settlement; Stripe's compliance system handles risk and taxation; and SPT's hybrid mode allows the agent to not be limited to stablecoins but also directly tap into the user's Visa or other payment methods. It is not as elegant, but it is closer to reality.

Interestingly, they are not completely competitive. x402 covers the long tail open scenario, while MPP covers enterprise-level high-frequency traffic. Stripe's strategy is also 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.

Reality Check: Where are we now in terms of development?

To be honest, there is almost no real-scale transaction happening at the moment.

According to Coinbase's x402 release notes, early partners include Hyperbolic (GPU Inference Pay) and Anthropic (MCP protocol integration). Stripe's blog mentions agent scenarios paid by API calls (such as CoinGecko). When Tempo launched, the directory had 100+ services. Cloudflare's Agents SDK natively supports x402, and some small projects on Base L2 are also attempting to use x402 as a payment gateway.

But overall, transaction volume is low, the number of merchants is limited, and most activities are still in the experimental stage.

This is not surprising. Any new payment infrastructure is like this in the early days. The so-called partner list sometimes has a big difference between signing an MOU and actually going live, and these releases usually do not distinguish particularly.

More noteworthy are the heavyweight participants behind the infrastructure. In 2025, Stripe processed $19 trillion in payments, with a total volume growing 34% year over year. At the same time, Coinbase, Cloudflare, Visa, Google, and a whole network of partnerships with Tempo have all entered the scene.

In other words, the track has been laid. The only remaining question is: in 2026, does an AI agent really need to transact at scale on this track? Or is this more like laying fiber optic cables in 1998—building the infrastructure before the demand arrives.

Which One Should You Choose?

If you are building an open, permissionless system, x402 is the more natural choice. No need for a registered platform, no need to integrate with payment processors, just import middleware, connect your wallet, and start receiving payments. The trade-off is that you have to handle compliance, risk management, and fiat settlement on your own.

If you are already within the Stripe ecosystem and want to tap into agent traffic, MPP is more suitable. Sessions, stream payments, fiat + crypto mix, and a complete compliance system essentially resemble a configuration upgrade rather than a system overhaul.

If you only care about one thing: being able to receive payments no matter which protocol the agent is using, then the answer is actually: use Stripe. It supports both sides.

HTTP 402 has finally found its purpose. It just took about 27 years.

[Original Article Link]