Three competing payment protocols are emerging to handle transactions between AI agents and digital services, but the future of agentic commerce may depend on them working together rather than one winning outright. x402, the Machine Payments Protocol (MPP), and the Agent Payments Protocol (AP2) each solve different parts of the payment puzzle: how agents discover prices, how value moves between parties, and how users maintain control over what their AI assistants can buy.

What's the Difference Between These Three Payment Protocols?

The three protocols are often described as competitors in a "protocol race," but that framing misses something crucial. They operate at different layers of the transaction lifecycle and address distinct problems.

x402 revives an obscure HTTP status code to create a machine-readable payment flow. When an AI agent requests a digital resource, the service responds with a price and payment requirements. The agent signs the payment using cryptocurrency, and the service delivers the resource. The breakthrough is simplicity: agents can purchase individual API calls, data queries, or tool access without opening accounts, choosing subscription tiers, or storing credit card information. Coinbase's implementation has processed more than 100 million x402 payments across the Base and Solana blockchains, demonstrating real transaction volume.

MPP, introduced by Stripe and Tempo in March 2026, takes a different approach by remaining payment-method agnostic. It supports stablecoins, traditional credit cards through Stripe, and custom payment methods. MPP also defines three commercial intents: one-time charges, metered sessions, and recurring subscriptions. This breadth makes it applicable to more than just tiny micropayments. Cloudflare's implementation describes MPP as a formal payment authentication scheme built around HTTP 402, and it's designed to be backward-compatible with existing x402 services.

AP2, released by Google in September 2025 and donated to the FIDO Alliance in April 2026, tackles a harder problem: proving that a user actually authorized a purchase. The protocol uses verifiable digital credentials called "mandates" that record what the user approved and under which conditions. A checkout mandate captures what is being purchased. A payment mandate authorizes the payment instrument and amount. Open mandates can define budgets and conditions for autonomous execution, allowing users to set rules like "my agent can spend up to $50 per day on data queries".

Why One Protocol Winning Isn't the Real Story?

The core insight from industry analysis is that these protocols solve four separate functions that have been compressed into one category: intent, negotiation, settlement, and fulfillment.

• Intent: What did the user authorize the agent to buy, and under which conditions?
• Negotiation: How does a service communicate its price and accepted payment methods?
• Settlement: How does value move, and how is payment verified?
• Fulfillment: Did the buyer receive the promised data, computation, tool result, or physical product?

x402 and MPP focus heavily on negotiation and settlement through HTTP. AP2 creates cryptographically verifiable records of delegated intent and transaction accountability. Neither x402 nor MPP alone can prove that a user actually wanted their agent to make a purchase, or that the service delivered what it promised. AP2 doesn't handle the payment settlement itself but ensures the authorization is legitimate and auditable.

How to Evaluate Which Protocol Fits Your Use Case

• x402 for crypto-native businesses: If you're building APIs, data services, or inference endpoints that want rapid stablecoin settlement without account creation, x402 is the strongest fit. It's especially natural for small, frequent purchases of digital resources and services that want payment without requiring users to sign up.
• MPP for hybrid payment methods: If your business needs to accept both stablecoins and traditional credit cards, or if you're offering metered sessions and recurring subscriptions, MPP's payment-method neutrality and billing-model flexibility make it applicable to more than atomic micropayments.
• AP2 for high-stakes purchases: If you're selling retail goods, higher-value services, or anything where user intent and dispute resolution matter, AP2's mandate system provides verifiable proof that the user authorized the transaction and understood the terms.

The likely winner, according to industry analysis, is a composed stack where all three protocols work together. x402 handles the HTTP payment negotiation for crypto-native digital goods. MPP provides a unified interface for businesses that need card and stablecoin support. AP2 sits above both, ensuring that every transaction is tied to a verifiable user mandate.

What Problems Remain Unsolved?

Even with all three protocols in place, a critical gap persists: payment does not prove fulfillment. A valid authorization and successful settlement do not establish that the data was accurate, the tool completed its task, or the purchase reflected unmanipulated user intent. An agent could be tricked into buying useless data, or a service could accept payment and deliver nothing.

x402 also faces structural risks around facilitators. A July 2026 research study examining 15 major x402 facilitators reported rule violations across all evaluated facilitators and described risks including unauthorized free access, asset theft, service denial, and gas abuse. A later fix can mitigate a disclosed implementation flaw, but it does not remove the structural need to audit facilitator behavior, idempotency, replay protection, and settlement assumptions.

MPP's payment-method breadth, while strategically valuable, does not eliminate payment-method differences. Cards, stablecoins, and custom rails have different finality, dispute, fraud, fee, and identity properties. A unified interface can simplify integration while leaving materially different risk beneath the abstraction.

The most valuable agent-payment infrastructure will bind user intent to price, settlement, and verifiable fulfillment across the entire transaction lifecycle. That binding is not yet complete, and it likely requires all three protocols working in concert rather than one replacing the others.