The Agentic Commerce Protocol Stack: ACP vs AP2 vs UCP vs MCP vs x402 vs MPP

If you have tried to follow agentic commerce, you have hit a wall of acronyms: ACP, AP2, UCP, MCP, A2A, x402, and now MPP. They are not competing versions of the same thing. They solve different parts of one problem: how an AI agent can discover a product, agree on a cart, prove a real person authorized the purchase, and move the money, all without a human clicking a checkout button.

This page is a neutral map. It explains what each protocol does, who is behind it, and how they stack together.

The mental model: four layers, not one standard

The cleanest way to make sense of the acronyms is to separate them by the job they do. Each layer is a distinct step in a single agentic purchase, and most protocols sit mainly in one.

Discovery

Discovery is how an agent finds what you sell and learns what it can do. Before anything is bought, the agent has to locate a merchant’s products and the tools or endpoints it can call, the machine-readable equivalent of finding the right shop and reading the shelves. This is the job of MCP.

Commerce and checkout

Commerce, or checkout, is how an agent browses, builds a cart, and completes the purchase with a merchant: selecting items, applying the cart, and running the checkout conversation. It is the heart of the transaction, and the layer where the two rival standards, ACP and UCP, compete.

Payment authorization

Payment authorization is how the agent proves a real person approved this specific purchase, and where the question of who is liable is settled. Removing the human from the checkout creates a new trust problem: a merchant or bank needs cryptographic confidence that the buyer actually consented, not just that software decided to spend. AP2 is the standard for this layer.

Settlement

Settlement is how the money actually moves once a purchase is authorized. It spans the familiar card rails and machine-native options for software paying software, including stablecoin settlement. x402 and MPP are the machine-native standards here, alongside the card networks.

Most of the protocols below sit mainly in one of these layers. They overlap at the edges, which is the source of most of the confusion.

DiscoveryHow an agent finds a merchant's tools

MCP

Commerce / checkoutBrowsing, cart, and completing the purchase

ACPUCP

Payment authorizationProving the user approved this purchase

AP2

SettlementMoving the money

Card railsx402MPP

The protocols

ACP: Agentic Commerce Protocol

Launched by OpenAI and Stripe, ACP is an open standard (Apache 2.0) for agent-to-merchant checkout. Its README describes OpenAI and Stripe as founding maintainers, while MAINTAINERS.md lists OpenAI, Stripe, and Meta as lead maintainers. A merchant implements it once, and any ACP-compatible agent can then browse, build a cart, and complete a purchase. It powered ChatGPT’s original in-conversation buying. ACP describes itself as compatible with both REST and MCP.

Layer: commerce semantics (checkout). As of August 2026: still in beta, with 2026-04-17 the latest stable spec revision (it added cart, feed, orders, authentication, and MCP). Etsy was live from launch and Walmart announced support, but the widely cited “million Shopify merchants” never materialized, and trade reporting indicates OpenAI scaled back native in-chat checkout in early 2026. See ACP explained.

AP2: Agent Payments Protocol

Announced by Google in September 2025 with 60+ launch partners (including Mastercard, PayPal, American Express, Coinbase, and Salesforce), AP2 is a vendor-neutral standard for payment authorization. It represents each purchase as three cryptographically signed mandates: an Intent Mandate (what the user wanted), a Cart Mandate (what the agent assembled), and a Payment Mandate (what gets charged). The point is trust: proving to a merchant or network that a real user consented to a specific amount.

Google donated AP2 to the FIDO Alliance on 28 April 2026, alongside a v0.2 release, and FIDO now develops it through a Payments Technical Working Group that Visa co-chairs. AP2 remains at v0.2 and is described as pre-production. Note that Stripe is not an AP2 backer; it supports ACP and MPP instead.

Layer: payment authorization and trust. Backed by: Google and the FIDO Alliance, plus major networks and PSPs.

UCP: Universal Commerce Protocol

Launched by Google in January 2026 with backers including Shopify, Etsy, Target, Wayfair, and Walmart, UCP standardizes the broader shopping journey, from discovery through checkout to post-purchase, rather than checkout alone. It is the main rival to ACP at the commerce-semantics layer, and Google pairs it with AP2 as the payments half of its stack.

UCP is governed by a Governance Council that oversees overall adoption and health (Google, Shopify, and Stripe, which joined in April 2026, with two seats open for election) sitting over per-domain Tech Councils that lead technical direction. The Shopping Tech Council expanded to 16 seats on 24 April 2026 and all of them are filled, across ten companies: Google, Shopify, Etsy, Target, and Wayfair, joined by Amazon, Meta, Microsoft, Salesforce, and Stripe. A second body, the Food Tech Council, was seated on 16 July 2026 with Block (Square), DoorDash, Google, Toast, and Uber Eats, and a third, the Lodging Tech Council, on 11 August 2026 with Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, and Trip.com. The current spec revision is v2026-08-25, released 25 August 2026, which reorganized the specification into Common, Shopping, and Payment groups so the payment layer is shared across verticals rather than living under shopping, added EMV 3-D Secure payment authentication, and carries breaking changes.

Layer: commerce semantics. Backed by: Google and Shopify, with a Tech Council spanning major retailers, platforms, and Stripe.

MCP: Model Context Protocol

Created by Anthropic and now held by the Agentic AI Foundation, a directed fund under the Linux Foundation, MCP is not a commerce protocol at all. It is the broader standard for how agents discover and call tools and data sources. In commerce, it acts as the discovery layer: an ACP-aware merchant can advertise its checkout as an MCP tool, so agents find it the same way they find any other capability.

MCP uses date-versioned revisions, and the current specification is 2026-07-28, published on 28 July 2026. It is the largest change since the protocol launched: the initialize/initialized handshake and the Mcp-Session-Id header have been retired, so the protocol core is now stateless and each request carries its own protocol version, client identity, and capabilities. If you read a description of MCP as a stateful, session-based protocol, it predates this revision.

Layer: discovery and capability. See MCP explained.

A2A: Agent-to-Agent

A2A standardizes how independent agents talk to each other and delegate tasks. In a commerce flow, it matters when a buyer’s agent negotiates or coordinates with a merchant’s agent rather than calling a fixed endpoint. It originated at Google, was donated to the Linux Foundation in 2025, and reached v1.0, its first stable specification, in March 2026. On 17 August 2026 it became a hosted project of the Agentic AI Foundation, the Linux Foundation body that also holds MCP, so coordination and discovery now share one governance home.

Layer: agent coordination. See A2A explained.

x402: machine-native payments

x402 revives the long-dormant HTTP 402 Payment Required status to let software pay for resources programmatically, typically with stablecoins, in amounts and at frequencies that card rails handle poorly. It is the settlement option for machine-to-machine and micro-transaction use cases rather than consumer retail checkout. The protocol itself is network, token, and currency agnostic by design, so “stablecoins” describes current practice rather than a limit in the spec.

x402 was contributed by Coinbase and is now stewarded by the x402 Foundation, which launched operationally under the Linux Foundation on 14 July 2026 with 40 members. Its premier tier spans the card networks and payment providers (Visa, Mastercard, American Express, Stripe, Adyen, Fiserv), platforms (Google, Shopify, AWS, Cloudflare), and crypto infrastructure (Coinbase, Circle, Ripple, and the Solana and Stellar foundations).

Layer: settlement. See x402 explained.

MPP: Machine Payments Protocol

Launched in March 2026 and co-authored by Stripe and Tempo, MPP is a second machine-native standard in the same lane as x402. An agent requests a resource from a service, API, or MCP endpoint, the service returns a payment request, the agent authorizes it, and the resource is delivered. It is built for microtransactions, recurring payments, and paying per API call, and it can settle in stablecoins as well as the cards, wallets, and other methods carried by Shared Payment Tokens. Stripe supports both MPP and x402.

Layer: settlement. See MPP explained.

Side-by-side

Protocol	Primary layer	Backed by	Best thought of as
ACP	Commerce semantics (checkout)	OpenAI and Stripe (Meta also a lead maintainer)	The agent-to-merchant checkout standard
AP2	Payment authorization	Google, now the FIDO Alliance, plus networks and PSPs	The proof that a user authorized the purchase
UCP	Commerce semantics	Google and Shopify, plus a Tech Council of retailers, platforms, and Stripe	The broader discover-to-post-purchase layer
MCP	Discovery / capability	Anthropic, now the Agentic AI Foundation (Linux Foundation)	How agents find the checkout in the first place
A2A	Agent coordination	Google, now the Agentic AI Foundation	How buyer and merchant agents talk
x402	Settlement	Coinbase, now the x402 Foundation (Linux Foundation)	Machine-native, stablecoin micropayments
MPP	Settlement	Stripe and Tempo	Machine-native agent payments for APIs and services

How they fit together

In practice these are complementary, not rivals. A realistic flow: an agent discovers a merchant’s checkout via MCP, runs the checkout via ACP or UCP, attaches an AP2 mandate to prove the user authorized it, and settles over card rails or, for machine-to-machine cases, x402. The reason there is no single winner is that no one standard spans discovery, semantics, authorization, and settlement at once.

What it means for you

Merchants: you do not have to bet on one acronym. The pattern emerging is checkout (ACP/UCP) plus authorization (AP2). Implementing ACP gets you into ChatGPT’s buying surface today; supporting AP2 mandates prepares you for the liability and trust questions that follow.

Builders: treat the stack as layered. Use MCP for discovery, a commerce protocol for the cart, AP2 for signed authorization, and pick a settlement rail per use case.

Decision-makers: the strategic question is not “which protocol wins” but “which layer is your moat.” Networks are fighting over authorization; model providers are fighting over the checkout surface; the merchant’s job is to be present and verifiable across both.

FAQ

Is ACP or AP2 going to win? They address different layers, so the likely outcome is coexistence: ACP/UCP for checkout, AP2 for authorization. Watch for convergence at the edges rather than a single victor.

Do I need all of these protocols? No. Most real deployments touch two or three: a discovery layer, a checkout layer, and an authorization layer. Settlement depends on your use case.

Where does MCP fit if it is not a commerce protocol? It is the discovery plumbing. Agents use MCP to find capabilities, including a merchant’s checkout, before any commerce protocol runs.