Which part of a purchase UCP, ACP, MCP and AP2 each define, who backs them, what status each specification gives itself, and where they overlap.
Four protocol names come up whenever AI shopping agents are discussed: UCP, ACP, MCP and AP2. Each one specifies part of what has to happen between an agent and a store, the parts differ from one protocol to the next, and in a few places they overlap. This article puts the four side by side: which part of a purchase each one defines, who backs it, what status its own specification gives it, and where they meet.
Where we explain a general term in plain words, the explanation is ours, not any specification's. Everything else comes from the documents linked in the text and listed under sources.
If you are new to the series, the hub article sets out why agents fail on most stores today. Two of the protocols here have their own articles: UCP explained and ACP explained. This one summarises them and links there for the detail.
01Four layers of one purchase
For an agent to buy something from a store for a shopper, several separate things have to work. We group them into four layers. The grouping is ours, made for this comparison.
Discovery: the agent finds out what the store supports, from a file at a known address.
Tools: the agent calls functions that some software offers it, such as a catalogue search. A tool here means a named action, with defined inputs and outputs, that an AI model can ask to run.
Checkout: the agent builds a basket, sets the delivery details and places the order.
Payment: the buyer's payment reaches the store's payment provider, within limits the buyer set or approved.
A protocol gets a layer in the table below when its own core specification defines that layer. Carrying another protocol's messages does not count, and neither does compatibility with a protocol that defines the layer. Optional extensions are not counted either. MCP's server-card extension is marked Final, yet MCP has no discovery layer in the table. UCP's payment layer rests on the payment handlers in its core profile, and its AP2 Mandates extension does not count. On the web page, buttons above the table filter it by layer.
Agentic commerce protocols, by the layer each defines
A cell is filled only where the protocol’s own specification defines the layer. Carrying another protocol’s messages does not count.
Discovery is defined by UCP.
UCP’s profile is at /.well-known/ucp. ACP’s discovery file is only a proposal. MCP’s server cards come from SEP-2127, an optional extension now marked Final, not from the core specification, so the cell stays blank.
MCP defines tools: “Functions for the AI model to execute”. UCP and ACP can carry their messages over MCP, which does not count as defining this layer.
UCP and ACP each define a checkout the store implements. AP2’s Checkout Mandate authorises a checkout, but AP2 leaves the checkout itself to a commerce protocol.
UCP’s cell rests on the payment handlers in its core profile; its AP2 Mandates extension is not counted. ACP has its Delegate Payment API, and AP2 defines Checkout and Payment Mandates.
No single row covers all four layers. UCP covers three, and it is the only one of the four whose core specification defines a discovery file. ACP covers checkout and payment, MCP covers tools, and AP2 covers payment.
02Who backs each one
For UCP, Google led its development, and Shopify writes that it "co-developed UCP with Google". The ucp.dev home page lists more co-developers and endorsers, but that list is the protocol's own claim and we have not checked it against each company, so we name Google and Shopify. Who governs the specification is not published: the footer reads "Copyright 2026 UCP Authors", and the specification refers to a "UCP governing body" without naming it.
For ACP, the sources disagree. The repository's MAINTAINERS.md lists OpenAI, Stripe and Meta as lead maintainers. The README in the same repository says the specification is maintained by OpenAI and Stripe, and agenticcommerce.dev says "Stripe and OpenAI developed the Agentic Commerce Protocol". Stripe's ACP page calls it "an open standard created by Stripe, OpenAI, and Meta". The table follows the maintainers file.
On 9 December 2025 Anthropic announced that it was donating MCP to the Agentic AI Foundation. The Linux Foundation's announcement of the same day lists "Anthropic's Model Context Protocol (MCP)" among the foundation's founding contributions.
Google announced AP2 on 16 September 2025 as "developed with leading payments and technology companies". On 28 April 2026 Google wrote that it was donating AP2 to the FIDO Alliance, and the FIDO Alliance confirmed the donation the next day.
03Discovery: where an agent learns what a store supports
Some files sit at fixed paths under /.well-known/ on a domain, so that software knows where to look without being told. UCP uses one of these paths. Its overview says: "Businesses publish their profile at /.well-known/ucp." The profile lists the store's services, capabilities and payment handlers, and UCP explained goes through it field by field.
ACP's discovery file exists only as a proposal. /.well-known/acp.json is defined in a discovery RFC, one of the repository's design documents (the README describes an RFC as a "Human-readable design doc with rationale, flows, and rollout plan"). It is marked "Status: Proposal" and "Version: unreleased", and it is not part of the released 2026-04-17 specification. The table therefore leaves discovery out of ACP's layers until that file is released.
The core MCP specification defines no file a store would publish for discovery. MCP server cards, which describe a server before an agent connects to it, come from SEP-2127, an optional extension that is now marked Final. The extension's discovery document, itself marked draft, lets a host list its cards in a catalogue at /.well-known/ai-catalog.json. Because the table counts only core specifications, MCP gets no discovery layer. AP2 does not define a discovery layer either. The wider practice of well-known files is the subject of how agents discover what a store offers.
04Tools: what MCP defines
The MCP specification says a server can offer three things to an AI application: "Resources: Context and data", "Prompts: Templated messages and workflows" and "Tools: Functions for the AI model to execute". Messages use JSON-RPC 2.0, a format where one side names a function and its arguments and the other replies with a result or an error. The table gives MCP the tools layer because that is the layer its own specification defines.
How a store can offer MCP tools, and how that relates to A2A and WebMCP, is the subject of MCP, A2A and WebMCP for stores.
05Where MCP meets UCP and ACP
UCP and ACP both name MCP as a transport, which we take to mean a channel their own messages can travel over.
UCP lists four transports a store can declare under services in its profile: rest, mcp, a2a and embedded. A2A, the Agent2Agent protocol, is another agent protocol and is not compared here.
ACP added an MCP binding in its 2026-04-17 release. The changelog records it as "Model Context Protocol (MCP) transport binding for ACP checkout operations", and the binding file in the released folder "Defines 5 MCP tools", each mapped one to one onto an ACP REST checkout operation. The tools are create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session and cancel_checkout_session. The binding document calls MCP "a second transport binding for ACP, alongside REST" and says the binding "is purely additive". (In a REST API, each web address stands for a thing, such as one checkout, and the request method says what to do with it.)
In both cases MCP carries the messages and the commerce protocol defines them. For ACP, the binding document says "the REST API, JSON Schemas, and protocol semantics are unchanged". That is why the table gives neither UCP nor ACP a tools layer, and gives MCP no checkout layer.
06Checkout: UCP and ACP side by side
UCP and ACP both define a checkout that the store implements and the agent calls.
UCP's checkout capability has five operations, Create, Get, Update, Complete and Cancel, and six statuses, from incomplete to completed and canceled. When the agent cannot go on by itself, the store returns requires_escalation and "MUST provide continue_url", an address where the buyer takes over in the store's own interface.
ACP's Agentic Checkout API has endpoints, web addresses that the store's software answers, to create, update, retrieve, complete and cancel a checkout session, and the 2026-04-17 file lists eleven statuses, requires_escalation among them. continue_url is an optional field there. The file describes itself as a "Merchant-implemented REST API for ChatGPT-driven checkout".
Both keep the store as the seller. The UCP checkout specification says "The business remains the Merchant of Record (MoR)", and agenticcommerce.dev says businesses "maintain their customer relationships as the merchant of record". That is the party that sells to the buyer and is responsible for the sale.
UCP's checkout page also says who confirms the purchase: "The checkout has to be finalized manually by the user through a trusted UI unless the AP2 Mandates extension is supported." The payment section below returns to that extension. ACP explained walks through the ACP session step by step.
07Payment: delegated tokens, mandates and handlers
Three of the four protocols define a payment layer: ACP, AP2 and UCP.
ACP has a Delegate Payment API with one endpoint, POST /agentic_commerce/delegate_payment. It "Tokenizes a credential for controlled usage by the merchant's PSP per the Allowance constraints". Tokenizing replaces card details with a stand-in value. The PSP is the payment service provider that processes the store's payments. The allowance sets a maximum amount, a currency, an expiry, the checkout session and the merchant the token is for, and "Exactly one credential type is currently supported: card". The released file does not say who calls the endpoint or who hosts it. The draft Payment Handlers RFC does: "Agent calls delegate_payment with the Seller's PSP", the PSP "creates vault token (SPT) scoped to the Seller's merchant account", and the agent submits that token to the seller. A vault token is that stand-in value, created by the PSP. ACP's MCP binding document says the same endpoint is "served by a different party (payment provider, not merchant)" and that it "should be addressed in a follow-up".
AP2 works with mandates. Its specification, titled "Agentic Payment Protocol (v0.2)", defines two: a Checkout Mandate, which captures the items and purchase details and goes to the merchant, and a Payment Mandate, which authorises a payment against an instrument and goes to the credential provider, the networks and the merchant's payment processor. Think of a mandate as a signed record of what someone agreed to. The specification describes a Human Present flow, in which the user approves the closed checkout and payment, and a Human Not Present flow, in which the user approves constraints and the agent signs closed mandates within them. "Closed" is the specification's word; we read it as final, with nothing left to change. It says "AP2 is agnostic to the particular payment instrument used". Google's launch post described Intent and Cart mandates. Those were version 0.1, and version 0.2 replaced them.
The figure below walks through both v0.2 flows in the order the specification gives. In our words: the Trusted Surface is the screen where the user sees and signs a mandate, the Checkout JWT is the merchant's signed copy of the checkout, and the cnf claim is the field in an open mandate that carries the agent's public key.
AP2 v0.2 mandates, with the user present and not present
SA
Shopping Agent
TS
Trusted Surface
M
Merchant
CP
Credential Provider
MPP
Merchant Payment Processor
Human present
1Merchant to Shopping AgentMerchant-signed Checkout JWTThe merchant must give the shopping agent a merchant-signed JWT containing the checkout; Human Present starts once the agent has it.Source: AP2 specification (v0.2)
2Shopping Agent to Trusted SurfaceMandate content to show and signThe agent builds the Checkout and Payment Mandate content and passes it to a Trusted Surface for display to the user and signing.Source: AP2 specification (v0.2)
3Shopping Agent to Credential ProviderPayment Mandate for verificationWith the mandates signed, the agent forwards the Payment Mandate to the Credential Provider (and possibly the network). It is bound to the checkout by the hash of the Checkout JWT.Source: AP2 specification (v0.2)
4Credential Provider to Shopping AgentPayment credentialUpon successful verification the agent receives a payment credential. The spec has the Credential Provider (or, if applicable, the network) return it after receiving the Payment Mandate.Source: AP2 specification (v0.2)
5Shopping Agent to MerchantCredential + Checkout MandateThe payment credential and the Checkout Mandate go to the merchant, which checks the checkout against the one it created.Source: AP2 specification (v0.2)
6Merchant to Merchant Payment ProcessorInitiate paymentFor a merchant-initiated charge, the merchant initiates payment with its Merchant Payment Processor. If the payment method pushes funds, the merchant instead confirms the funds it received.Source: AP2 specification (v0.2)
7Merchant to Shopping AgentCheckout ReceiptOnce it has accepted or rejected the Checkout Mandate, the merchant must return a Checkout Receipt. A Payment Receipt goes to the agent, the Credential Provider and, if applicable, the network.Source: AP2 specification (v0.2)
Human not present
1Shopping Agent to Trusted SurfaceOpen mandates to authorizeTo act autonomously the agent creates open Checkout and Payment Mandate content, constraints the user approves, and has the Trusted Surface authorize it. Open mandates must carry the agent’s public key as a cnf claim.Source: AP2 specification (v0.2)
2Shopping Agent to Credential ProviderOpen + closed Payment MandateThe agent must give verifiers both the user-signed open mandate and its closed one “as described in the Direct case”, which sends the Payment Mandate first. Its verifiers are the Credential Provider and, if applicable, the network and the Merchant Payment Processor.Source: AP2 specification (v0.2)
3Shopping Agent to MerchantOpen + closed Checkout Mandate, which the agent may sign itselfThen, as in the Direct case, the Checkout Mandate goes to the merchant. The agent may sign the closed mandate with its own key instead of getting approval on a Trusted Surface; verifiers always receive closed mandates.Source: AP2 specification (v0.2)
AP2 does not define a checkout. Its specification says: "AP2 operates as a security feature within a Commerce Protocol. The exact details of the Commerce Protocol (e.g., catalog APIs, checkout updates, and specific APIs for communication between the different roles) are outside the scope of AP2." It continues: "AP2 is designed explicitly to be compatible with the Universal Commerce Protocol (UCP)". The AP2 home page says it is available as an extension for A2A and UCP.
UCP meets AP2 from its own side. Its payment group includes Payment Handlers and an AP2 Mandates extension, next to extensions for payment authentication, payment terms and split payments. Payment handlers "are discovered from the business's UCP profile at /.well-known/ucp". The AP2 Mandates extension is the one named in the checkout sentence quoted earlier.
ACP and AP2 do not refer to each other in the documents we searched. The AP2 specification and home page do not mention ACP. The ACP README, its MCP binding document, and its checkout, delegate payment and payment handlers RFCs do not mention AP2 or mandates, so neither side describes whether the two can be used together.
In ACP's examples the PSP is Stripe, and the draft Payment Handlers RFC calls the token an SPT, Stripe's term for a shared payment token. Stripe offers Shared Payment Tokens as a preview. Payment tokens across providers are the subject of how an agent pays without seeing your card.
08Status, as each specification labels it
The status column in the table repeats each specification's own label. The labels are not on a common scale, so the table does not rank them.
UCP: the GitHub release v2026-08-25 is marked "Latest" and not marked as a pre-release. The specification itself carries no "draft" or "released" label.
ACP: the README marks 2026-04-17 as "Latest Stable" and says the specification "is currently in beta". The checkout, delegate payment and payment handlers RFCs are labelled Draft; the discovery RFC is a Proposal.
MCP: the versioning page says "The current protocol version is 2026-07-28". It marks revisions as Draft, Current or Final, and a version's date is "the last date backwards incompatible changes were made".
AP2: the specification page is titled "v0.2" and carries no draft or final label. The repository's GitHub releases list v0.2.0, published on 28 April 2026 and marked "Latest", and v0.1.0, from 16 September 2025.
UCP, ACP and MCP version by date, and AP2 by number.
09What a store owner can take from this today
The table does not say which protocol to adopt, and this article gives no adoption figures.
Open https://your-domain/.well-known/ucp in a browser. A JSON document with a ucp member means something already publishes a UCP profile for your store. UCP is the one protocol here whose core specification gives you a file to check.
For ACP there is no released file to check, so ask your platform, or whoever maintains your checkout, whether they implement the ACP checkout endpoints and which API-Version they accept.
If someone offers an MCP server for your store, ask which checkout it carries: UCP over its mcp transport, ACP over its MCP binding, or neither. In the table, MCP's own layer is tools.
Ask your payment provider whether it accepts ACP delegated tokens.
Ask your platform whether your store's UCP profile declares the AP2 Mandates extension.
10What is not settled
Several questions stay open in the published sources:
ACP's discovery file is a proposal, so an agent has no released way to find out whether a store supports ACP.
ACP's maintainers are listed as OpenAI, Stripe and Meta in one file and as OpenAI and Stripe in the README and on agenticcommerce.dev.
UCP's governing body is not named.
The caller of ACP's delegate_payment is named in a draft RFC, not in the released file, and the MCP binding defers delegated payment to a follow-up.
AP2's mandate types changed between versions 0.1 and 0.2, so descriptions written for 0.1 no longer match the specification.
The ACP and AP2 documents do not describe how, or whether, the two fit together.
MCP's core specification defines no discovery file a store would publish. Server cards come from an optional extension, and the document that gives their catalogue address is marked draft.
The sources below were last checked on the date shown.