One 402, Two Protocols: x402 and MPP

Key Takeaways

• MPP inherits x402's 402 flow, but it is a separate protocol that redesigns sessions and settlement. If x402 is on-chain payment by request, MPP is session-based payment built on deposit, streaming, and batch settlement.

• MPP breaks down the "card versus crypto" frame through rail agnostic. Within a single task, an agent can move across stablecoins and cards, and MPP abstracts that shift at the protocol level.

• MPP and x402 differ in the depth of abstraction. MPP ties x402's components into a single layer. At the same time, it is part of Stripe's platform strategy to capture the value of agent payments within its own ecosystem.

• x402 and MPP have a complementary relationship. One is bottom-up and the other is top-down. The future of 402-based agent payments will depend on whether a flywheel emerges in which one side absorbs the other's innovations.

Source: mpp.dev

On March 18, Stripe announced MPP (Machine Payments Protocol) alongside its Tempo mainnet launch. The open standard for machine payments was designed jointly by Tempo and Stripe. It also drew attention because it was an agent payments protocol introduced by two major payment infrastructure players. One point stood out in particular.

Source: Stripe Docs

Instead of extending the existing x402 standard, Tempo built a separate protocol. x402 and MPP both use the same HTTP 402 primitive, so they are interoperable. Even so, Stripe's official documentation clearly treats them as distinct protocols.

1. MPP, a 402-based payment protocol

MPP and x402 share the same basic protocol structure. When a client requests a resource, the server returns a 402 Payment Required response with payment terms. The client then makes the payment, attaches proof, and sends the request again. The flow is the same in both protocols: request, 402 response, payment, proof attached, and retried request.

The difference appears in the elements built on top of that payment flow. The two protocols diverge in two places.

First, payment frequency and settlement model (session). x402 basically generates an on-chain transaction for each request. MPP, by contrast, prefunds capital, streams payments, and aggregates thousands of micropayments into a single settlement.

Second, rail agnostic. x402 focuses on on-chain payments, while MPP abstracts stablecoins, cards, wallets, and BNPL (Buy Now, Pay Later) into a single protocol through SPT (Shared Payment Tokens). SPT lets agents submit payment proof in the same way regardless of the payment method.

2. The Architecture of a Session: x402’s Memory vs. MPP’s Flow

2.1 x402 Session: The Memory of Paid Resources

Source: x402.org

The x402 Foundation announced V2 on December 11, 2025 and introduced a Foundation for Reusable Access. This structure uses wallet-based authentication so that on-chain transactions can be skipped when a user returns to a resource that has already been paid for. The Foundation explained that this can reduce latency and lower the cost of repeated calls in high-frequency workloads such as LLM inference and multicall agents.

This makes session-based access possible. More precisely, it lets a client prove that it has paid before and skip repeat payments for the same resource. If an agent calls a new resource that it has not accessed before, an individual on-chain transaction is still required.

The only payment model implemented today is exact, which means an on-chain payment for the precise amount of each request. A mode called upto has been proposed, but that model charges based on usage within a single request, for example by the number of tokens generated in one LLM call. It does not bundle multiple requests into one session.

2.2 MPP Session: The Streaming of Prefunded Value

At the protocol level, the meaning of a session in MPP is fundamentally different. When an agent opens a session for a specific service, it prefunds a payment channel with that service. After that, each new request to the same service, such as API calls, model inference, or data queries, is paid through off-chain vouchers without a separate on-chain transaction. Vouchers do not run into blockchain throughput bottlenecks, and they operate through signature verification alone. Thousands of micropayments can accumulate, and final settlement happens in a single on-chain transaction when the channel closes.

Source: tempo.xyz

Tempo describes this as "OAuth for money." OAuth shifted the unit of authentication from the request to the session and opened the web API ecosystem. MPP does the same for payment, shifting the unit from the transaction to the session.

Just as an agent that completes OAuth once in Claude Code can call APIs afterward without logging in each time, an MPP session can run continuously within the deposit limit after funds are posted once. Instead of an authentication token, it uses a payment voucher. Instead of an authentication limit, it uses a deposit limit, maxDeposit.

2.3 x402 by transaction, MPP by session: a branching point for agent payments

In x402, the session focuses on preventing duplicate payments for resources that were already purchased. In MPP, the session centers on off-chain payment streaming backed by prefunded deposits. x402 uses the session to skip repeat payments. MPP uses the session to make payments continuous.

This design difference follows from how each actor consumes services. People pay large amounts occasionally. Agents do the opposite. Their default pattern is micropayments, very small amounts paid at very high frequency. In the agent economy, payment is no longer just the purchase of a good or service. For agents, payment is computation itself.

Consider a concrete example. Suppose an agent is writing a research report with an LLM API. It uses Prompt A to generate a draft, Prompt B to fact-check it, and Prompt C to produce a summary. Each of these is a new request that has not been accessed before.

• x402 V2: An on-chain payment occurs for Prompt A, Prompt B, and Prompt C separately. If the same prompt is sent again, repeat payment can be skipped. Each new prompt still requires an individual on-chain transaction.

• MPP: Once a session is opened with an on-chain transaction, A, B, and C can all be accessed through off-chain vouchers within the deposit limit, and on-chain settlement occurs when the session closes. Even if the prompt is called hundreds of times, the on-chain count remains at two within the deposit limit.

If an agent needs hundreds of API calls to complete one task and each call triggers an on-chain transaction, blockchain throughput and fees become the ceiling on the agent's speed and cost. MPP removes this bottleneck at the protocol level by fixing the on-chain count to the number of sessions rather than the number of requests.

3. Rail agnostic: 402-based payment protocols are not competitors to cards

3.1 The flaw in the card replacement thesis: cards are financial products

One of the most common narratives around x402 was that stablecoins would replace credit cards. That narrative led some people to support x402, while others dismissed x402 because card replacement itself seemed unrealistic. In a recent article, Noah Levine of a16z crypto (@nlevine19) rejected that argument directly.

Source: X(@nlevine19)

His core point is that a card is a financial product. Payment is only one part of it. It combines unsecured credit, fraud protection, and chargebacks, and consumers have little reason to give up those protections. Card networks have also already adapted to micropayments. He rejects the claim that agents cannot use cards as well. Visa Intelligent Commerce and Mastercard Agent Pay already apply cards to agents through tokenized methods, and on March 18, Visa also announced Visa CLI for agents.

Source: x402.org

x402 itself never positioned card networks as competitors. As stated in the x402 V2 spec, the protocol is designed to accommodate card networks through facilitators. Card payments are technically possible. "Card replacement" was never the protocol's design intent. It came from overinterpretation by part of the community.

Where, then, can 402-based payment protocols, including x402, capture value? Levine's answer is merchants that do not yet exist. Services without a website, legal entity, or terms of service cannot pass underwriting by existing processors. In those cases, stablecoins are the only option.

3.2 Reality is multirail, and that is why abstraction matters

Not every service an agent accesses falls into the category of a merchant that does not yet exist. Within a single task, an agent moves across areas where cards are needed and areas where stablecoins are needed. How should an agent prepare for that? Consider one example. If a user says, "Prepare next week's business trip," the agent may follow these steps.

First, it calls data APIs dozens of times to compare flight and hotel prices ($0.001, USDC).

Second, once it finds the best combination, it books the flight ($500, credit card).

Third, it calls a document conversion API again to organize the confirmation documents ($0.01, USDC).

Why does the split look like this? Rail choice depends on more than the amount. It also depends on how much reversibility the transaction requires. Airline reservations carry a high risk of disputes, such as schedule changes, cancellations, or dissatisfaction with the service. In those cases, the consumer protection mechanism of chargebacks has economic value. API calls, by contrast, are atomic transactions in which the resource is consumed as soon as the request is made, so there is structurally no basis for reversal. Even a $500 API call can rationally use stablecoins if it is an atomic transaction that is consumed immediately. Even a $0.50 subscription can rationally use a card if refund disputes are expected.

In practice, rail selection is shaped by factors beyond reversibility, including regulatory jurisdiction, foreign exchange risk, corporate accounting, and tax treatment. What matters is the structural problem: agent developers have to implement this complex judgment directly.

This multirail switching has to be abstracted at the protocol level. If an agent has to choose the rail directly for each task, payment becomes a bottleneck rather than infrastructure that supports the agent's actions. As long as 402-based payment protocols treat cards only as competitors, that abstraction cannot be realized. MPP is designed around this exact issue.

3.3 MPP's design for rail agnostic

MPP provides two payment modes on top of this 402-based flow. x402 declared in V2 that it would accommodate card facilitators. MPP implements that idea in practice through SPT.

• tempo.charge() (Rail A): Micropayments with on-chain settlement.

• stripe.charge() (Rail B): Existing payment methods such as cards and wallets through SPT, settled through Stripe rails.

The initialization patterns differ, but the protocol flow is the same. The server returns 402, presents a payment request, verifies the payment proof, and unlocks the resource.

Returning to the travel scenario, the first and third tasks, API calls, use the stablecoin rail (Rail A), while the second task, flight booking, uses the credit card rail (Rail B). For the agent making the payment, however, the flow is exactly the same in all three cases. That is what it means for rail selection to be abstracted at the protocol level.

This suggests a clear design principle at Tempo: moving away from the long-standing Web3 fixation that crypto must replace existing credit cards. x402 declared card acceptance in the spec, and MPP implemented it through Stripe rails. The agent payments ecosystem is moving beyond the "card versus stablecoin" frame and toward coexistence based on the strengths of each rail.

Where does each rail fit? In a long-tail ecosystem with thousands of independent agent providers, building merchant agreements and batch settlement pipelines for every service combination simply to accept card payments is unrealistic. Per-transaction fees can be softened through batch billing, and a platform can act as the merchant to lower underwriting barriers. That solution works only inside the same platform. Outside that boundary, where immediate settlement is needed between agents without a prior contractual relationship, stablecoins become the only payment rail. Conditional payments through smart contracts, where payment is made only after the result is verified, also arise naturally on that layer. In areas where chargebacks and consumer protection are required, cards still have the advantage.

The point is to abstract both directions into a single protocol. Through MPP, Tempo shows the possibility of payment infrastructure built on rail agnostic.

4. x402 and MPP: a complementary relationship

When MPP and x402 are compared, the difference in features does not look dramatic at first glance. Attention is more likely to go first to the scale and symbolic weight of Stripe and Tempo as infrastructure providers. In fact, many of MPP's functions have already been implemented on x402 or are close to implementation at the proposal stage. Multirail support can be accommodated through the V2 facilitator structure, and the Payments Directory that MPP built into the protocol level has already been proposed in x402 through the x402 Bazaar discovery layer. Very little in MPP is impossible to implement on top of the x402 ecosystem.

The distinction lies in how far abstraction goes and who it is built for. Stripe lowered the payment barrier in internet commerce with the idea that payments could be added in seven lines of code. MPP applies a similar approach to agent payments. Instead of asking agent developers to choose and assemble sessions, multirail support, and discovery on their own, it makes them available as a single protocol. The parts were already present in x402. MPP tied them into one layer and made it possible, at the protocol level, for developers to stop thinking about payment infrastructure.

Value capture also deserves attention. Stripe supports x402 as well, yet it created MPP as a separate protocol. Since x402 is led by Coinbase, Stripe having its own protocol is also a platform strategy to keep the value of agent payment traffic inside its own ecosystem. The logic is similar to the way L1s such as Base and Solana onboarded their networks as settlement layers on top of x402 in order to activate transaction volume. By bundling cards, wallets, and other existing payment methods into SPT and routing them through its own payment network, Stripe is aiming to become the settlement hub of the agent economy. In practice, every agent payment that passes through Stripe rails is subject to Stripe's standard fees. The technical validity of MPP's abstraction and the question of who captures the value it creates are separate issues.

Within that value structure, the two protocols point in different directions. x402 is a bottom-up structure in which developers in the open-source community freely propose and build extensions. MPP is a top-down structure in which Stripe and Tempo resolve, at the protocol level, the problems companies encounter in practice: session settlement, multirail switching, and service discovery. They stand on the same 402 primitive, but they address different constituencies. x402 faces the developer community, and MPP faces enterprise payment infrastructure. This difference in direction makes them complementary. It amounts to a division of labor. If that division works, the final experience for agent developers becomes simpler. The protocol chooses the rail, and the session bundles settlement by service. The agent only calls the API and receives the result.

That division of labor alone is not enough. For the agent economy to move beyond experimentation and reach real adoption, it needs a flywheel in which one side introduces a new structure and the other absorbs and advances it. MPP's adoption of the x402 402 flow is the first example. The next may be x402 taking in MPP's session model or multirail structure. Each time one side presents a more efficient structure, the other can absorb it and evolve. A third 402-based protocol could also emerge and push both sides forward. The future of 402-based agent payments will depend on whether this flywheel actually works.