x402 vs MPP - Agentic Payments Compared

AI agents are no longer just answering questions. They are buying services, consuming APIs, and transacting autonomously. As this shift accelerates, a wave of agentic commerce protocols has emerged, but they are not all solving the same problem.

Quick answer

x402 and MPP both let software pay for services through HTTP 402, but they use different wire formats and payment ecosystems. Choose x402 for its broad facilitator and multi-network ecosystem; choose MPP for its HTTP-auth payment methods and session model. PayAI's experimental Agent Payments SDK demonstrates both challenges in one TypeScript middleware, but it is not under active development at this time.

This article maps the landscape across the four major standards: x402, MPP, ACP, and UCP. It draws a distinction that most comparisons miss: two of these protocols handle machine-to-machine API payments, while the other two handle human-directed shopping through AI agents. Understanding which layer you are building for is the first decision every developer and merchant needs to make.

PayAI's experimental Agent Payments SDK demonstrates one TypeScript middleware that can expose both x402 and MPP payment challenges. The SDK is not under active development at this time, so treat it as a reference implementation rather than a maintained production dependency.

In a nutshell

• AI agents are becoming economic actors, but the infrastructure supporting them has split into two layers serving fundamentally different use cases.
• Machine-to-machine API payments (x402 by Coinbase, MPP co-authored by Tempo and Stripe): autonomous agents pay for services they consume directly. These are the protocols relevant to API builders and service monetizers.
• Human-directed agentic checkout (ACP by Stripe and OpenAI, UCP co-developed by Google and Shopify with Walmart, Target, Etsy, and Wayfair): a human buyer uses an AI agent to shop on their behalf. These are the protocols relevant to e-commerce merchants.
• The real pain point for API builders is fragmentation: networks, supported schemes, merchant credentials and discovery catalogs vary. A shared protocol can provide compatibility across facilitators; separate catalogs do not make payment clients incompatible.

The rise of agentic payments

What began as information retrieval - summarizing documents, answering queries - has evolved into autonomous purchasing and service consumption. The global AI agent software market is projected to reach $52.62 billion by 2030, a 46.3% CAGR from 2025 to 2030.

API builders need to compare onboarding, spending authority and transaction economics. Merchant accounts and API keys do not inherently require a human to approve every payment. For a $0.002 API call, evaluate fixed fees, aggregation and prepaid options alongside low-fee payment schemes.

Enter agentic payment protocols. These systems embed payment directly into the web's native request–response flow, enabling pay-per-request micropayments settled in stablecoins on low-cost blockchains. The concept is not entirely new: HTTP status code 402 ("Payment Required") was reserved in RFC 7231 back in 2014, but no interoperable payment protocol was standardized for it until 2024–2025. Now the infrastructure is catching up to the vision. But as multiple protocols race to define the standard, the ecosystem is fracturing faster than it is consolidating.

Agentic payment protocols compared: x402 vs. MPP vs. ACP vs. UCP

The four major protocols are not all playing the same game. Before evaluating them, it is essential to understand the two distinct layers they operate on.

Layer 1: Machine-to-machine API payments. An autonomous agent pays for a service it consumes directly: an API call, a data feed, a compute task. Payment happens in milliseconds, without human involvement, at sub-cent scale. The protocols here are x402 and MPP.

Layer 2: Human-directed agentic checkout. A human buyer delegates a purchase to an AI agent. "Buy me a large black t-shirt under $40." The human authorizes the action; the agent executes it. The protocols here are ACP and UCP.

PayAI operates in Layer 1. The fragmentation analysis later in this article focuses specifically on that layer. But understanding all four protocols helps developers and merchants decide which parts of the agentic economy they are building for.

x402: The HTTP-native open standard

The x402 protocol is a leading open standard for agentic payments, with a growing multi-facilitator, multi-network ecosystem. Its design philosophy is simple: leverage the HTTP 402 status code to create a native request–response payment flow that any web server can implement.

How it works: An x402 v2 resource returns HTTP 402 with PAYMENT-REQUIRED. The client selects supported terms, signs a payload and retries with PAYMENT-SIGNATURE. For exact payments, the server verifies and settles before releasing the paid response. Batch settlement accepts a commitment that is redeemed later.

Strengths:

• Simplicity of integration. Adding x402 to an Express or FastAPI server requires as few as 5–15 lines of middleware code.
• Open and neutral. x402 is not owned by any single company. There is no vendor lock-in, and the protocol specification is freely available.
• Growing multi-network ecosystem. x402 has independent and hosted facilitators across Solana, Base, Polygon, Arbitrum, World and other networks. The protocol supports pay-per-request and usage-based pricing, while each facilitator advertises the networks, schemes and assets it actually settles.
• Pay-per-request and usage-based pricing with stablecoins like USDC are natively supported.

Limitations:

• Ecosystem fragmentation. Providers differ in network and scheme support, operational requirements and catalogs. A compatible client can pay a resource without integrating with every facilitator: the resource server selects its facilitator. Compatibility still requires matching versions, schemes, assets and networks.
• Payment-method availability. Many integrations use stablecoins, but x402 is extensible and batch-settlement bindings can use credit-backed billing. Check deployed client and provider support rather than treating every proposed rail as available.
• Discovery is facilitator-specific. Being listed on one facilitator's catalog does not guarantee visibility on another's.

MPP: Machine Payment Protocol

MPP is an open standard for machine-to-machine payments co-authored by Stripe and Tempo Labs, launched on March 18, 2026. Like x402, it uses the HTTP 402 status code, but rather than inventing new header conventions, it plugs into the existing HTTP authentication framework via a WWW-Authenticate: Payment challenge-response pattern. This is the same model used by Basic, Bearer, and Digest auth.

How it works: A client requests a resource. The server responds with 402 and a WWW-Authenticate: Payment challenge describing what payment is needed. The client fulfills the payment via the specified payment method, then retries with an Authorization: Payment credential proving payment. The server verifies and returns the resource with a Payment-Receipt header.

Strengths:

• Payment-method breadth. MPP now has more than ten live payment methods across stablecoins on EVM networks, cards and Bitcoin, and one discovery document can advertise multiple methods, currencies and intents for the same endpoint.
• Sessions for high-frequency micropayments. MPP sessions let a client authorize once, meter usage through cumulative vouchers, and settle accepted usage later. Sessions are now a formal cross-network intent; Tempo ships the production implementation today, while the shared model is designed to map onto additional payment methods and settlement layers.
• Production-grade primitives. Built-in idempotency, expiration, and request binding.
• IETF Internet-Draft. The Payment HTTP authentication proposal is an individual Internet-Draft. Its intended Standards Track status is not IETF endorsement, an approved RFC or an official exclusive implementation of HTTP 402.
• Significant institutional backing. Tempo raised $500M at a $5B valuation (led by Thrive Capital and Greenoaks). Stripe co-authored the protocol, and design partners include Anthropic, DoorDash, Mastercard, OpenAI, Revolut, Shopify, Standard Chartered, and Visa. The current MPP directory contains 142 active entries, including OpenAI, Anthropic, Parallel, Alchemy and many independent services. Directory metadata is advisory; the target endpoint's live 402 challenge remains the authoritative payment offer.

Limitations:

• Newer ecosystem. MPP launched in March 2026, so developer tooling is less mature than x402's, which has had a year-long head start building facilitators, SDKs, and catalog infrastructure.
• Deployment still varies by method and intent. Tempo currently ships the documented session implementation; the cross-network session specification does not by itself prove that every payment method or network has deployed sessions.
• Stablecoin acceptance is currently for US-businesses only via Stripe. Customers can use stablecoins as payment globally, but currently only US businesses can accept stablecoin payments.

ACP: Agentic Commerce Protocol

ACP is an open standard co-developed by Stripe and OpenAI for human-directed e-commerce checkout through AI agents. This is a critical distinction: while x402 and MPP handle machine-to-machine API payments (an agent pays for a service it consumes), ACP handles the scenario where a human says "buy me a large black t-shirt under $40" and an AI agent executes that purchase with a merchant.

ACP launched on September 29, 2025 with Instant Checkout for US Etsy purchases and Shopify support announced. The protocol has since expanded well beyond that launch surface: its April 17, 2026 stable specification adds cart, catalog feed, orders, authentication and MCP support. ChatGPT now uses ACP most visibly for product discovery, catalog feeds and promotions while merchants complete purchases through their own checkout experiences.

How it works: ACP defines two complementary specifications. Agentic Checkout is a REST API between agents and sellers that manages checkout sessions: creating a cart, selecting fulfillment options, applying discounts, and completing payment. Delegate Payment handles secure tokenization of the buyer's payment credentials via Shared Payment Tokens (SPTs), which are scoped to a specific merchant and cart total, so the agent can relay payment without ever holding raw card data. The human buyer authorizes payment; the seller remains the merchant of record.

Strengths:

• Solves the real e-commerce agent problem. Rather than agents scraping websites and battling CAPTCHAs, ACP gives them a deterministic, programmatic checkout interface.
• Capability negotiation. Agents and sellers exchange a capabilities object at session creation, so incompatibilities surface before payment, not during.
• Discovery at scale. Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot and Wayfair have integrated with ACP for discovery, while Shopify Catalog makes millions of Shopify merchants discoverable in ChatGPT.
• PSP-agnostic. Businesses not on Stripe can still implement ACP with their existing payment providers.

Limitations:

• Not relevant for API/service monetization. ACP is built for physical and digital goods checkout with a human buyer in the loop. It does not address machine-to-machine micropayments.
• Product rollout differs from protocol capability. ChatGPT's original Instant Checkout began with US single-item Etsy purchases. ACP's current specification supports carts and broader commerce primitives, while OpenAI's present shopping focus is product discovery and merchant-owned checkout.

PayAI does not currently operate in the ACP layer. It is included here for market context.

UCP: Universal Commerce Protocol

UCP is an open-source standard co-developed by Google and Shopify, with Walmart, Target, Etsy, and Wayfair as co-developers, and endorsed by more than 20 global partners including Visa, Mastercard, Amex, PayPal, Stripe, Adyen, Best Buy, The Home Depot, Macy's, and Zalando. It launched at the National Retail Federation conference on January 11, 2026.

Like ACP, UCP targets human-directed agentic checkout, not machine-to-machine API payments. But where ACP focuses on the checkout moment, UCP is substantially more ambitious, as it aims to cover the entire commerce lifecycle from product discovery through post-purchase order management.

How it works: UCP defines a capability-based architecture where businesses and platforms declare what they support and negotiate the intersection dynamically. Its August 25, 2026 release spans catalog, cart, checkout, identity, orders, fulfillment, post-purchase adjustments and loyalty. UCP supports REST, MCP, A2A and embedded-protocol bindings; AP2 Mandates is a checkout extension that can authorize completion without manual finalization.

Strengths:

• Full commerce lifecycle. UCP now covers catalog discovery, cart, checkout, identity, orders, fulfillment, returns and refund adjustments, and loyalty—one negotiated protocol surface across the shopping journey.
• Massive industry coalition. The broadest co-development and endorsement list of any agentic commerce standard, spanning retailers, payment networks, and platforms.
• Layered extensibility. Merchants implement only the capabilities they need. Extensions are independently versioned, so the core protocol stays stable while the ecosystem evolves.
• Shipping into major commerce surfaces. Google has introduced UCP-powered Universal Cart and is rolling out additional checkout experiences across Search, Gemini and major retail partners.

Limitations:

• Different job from API metering. UCP targets retail commerce rather than pay-per-call API access. Checkout is manually finalized through a trusted UI unless the implementation supports the AP2 Mandates extension.
• Complexity at scale. The ambition of covering every commerce vertical introduces real integration complexity for merchants with specialized requirements.

PayAI does not currently operate in the UCP layer. It is included here for market context.

The two layers of agentic commerce

Understanding which layer applies to your use case is the most important decision before choosing a protocol.

Layer 1 deep-dive: x402 vs. MPP

For API builders and service monetizers operating in the machine-to-machine payment layer, here is how the two protocols compare.

The fragmentation problem

The protocol comparison above reveals an important truth: the biggest challenge facing agentic payments is not choosing the right protocol. It is dealing with the fragmented ecosystem that has grown around them.

Within x402, merchants can choose among multiple facilitators with different network support, operating policies and discovery services. Standard SDKs can interoperate when versions, schemes, assets and networks match. Discovery coverage is a separate issue: a missing catalog listing does not make an otherwise compatible payment impossible.

The merchant's dilemma

Consider a developer monetizing an image-analysis API. The resource server chooses supported terms and a facilitator. A client that knows the endpoint and supports those terms can pay it; the client does not need to use the same discovery catalog. A Solana-only wallet still cannot satisfy a Base-only payment requirement without another supported payment option.

Adding networks, schemes or catalog integrations can require development and maintenance. Being listed in one catalog does not guarantee listing in another, but clients may also discover endpoints through documentation, search, direct links or other tools. Measure where qualified traffic comes from before prioritizing catalog work.

Every hour spent on payment plumbing is an hour not spent improving the core product. The demand side suffers equally: an agent with a Solana wallet cannot pay a merchant who only accepts on Base. An agent querying one catalog sees an incomplete picture of available services.

The market cannot reach critical mass while it remains this fragmented.

What the market needs: Abstraction, not another protocol

The temptation in a fragmented market is to propose yet another standard. But history suggests a different path.

Before Stripe, merchants accepting online payments had to integrate with Visa, Mastercard, American Express, Discover, and regional processors individually. Stripe unified those fragmented integrations into a single developer experience. Critically, Stripe did not replace Visa or Mastercard, it abstracted them. The underlying networks continued to operate; the aggregator removed the friction of dealing with each one individually.

Agentic payments are at the same inflection point. x402 and MPP are the underlying machine-to-machine payment networks. And tomorrow may bring yet another protocol. What is missing is the aggregation layer. That is where PayAI operates.

The agentic payment landscape will consolidate: position yourself now

The agentic commerce landscape is innovating across two distinct layers. ACP and UCP are redefining how humans shop through AI agents, with massive institutional backing and live rollouts underway. x402 and MPP are redefining how autonomous agents pay for the services they consume. This is where fragmentation is most acute and where abstraction delivers the most value.

The merchants who establish presence across all networks and catalogs while the ecosystem is still forming will capture disproportionate agent traffic as the market scales. The question is not whether consolidation will happen. It is whether you will be positioned to benefit when it does.