Agentic Commerce Protocols: How the Competing Standards Differ.

Agentic commerce protocols differ less in how an agent reads a catalogue than in who holds the payment credential and who owns the resulting order. Those two answers are what a merchant commits to.

The main specifications are public and dated. OpenAI and Stripe released the Agentic Commerce Protocol (ACP) in September 2025. Google announced the Agent Payments Protocol (AP2) on 16 September 2025, and on 11 January 2026 launched the Universal Commerce Protocol (UCP), co-developed with Shopify, Etsy, Wayfair, Target and Walmart. On 16 June 2026 Adyen announced Adyen Agentic as a “universal translator” across agent platforms and protocols, naming UCP, AP2 and ACP.

This article compares those specifications on four axes. A published specification shows how a protocol allocates payment custody, order ownership and proof of authority. It does not show how many shoppers use it. Almost everything published on agentic commerce adoption is vendor announcement or consultancy projection, so claims about adoption here are limited to what can be dated and attributed. The releases, and what each one assumes about the merchant, are catalogued in the 2026 agentic commerce releases.

What is an agentic commerce protocol, and why is there more than one?

An agentic commerce protocol is an agreed way for a software agent acting for a shopper to read a merchant's catalogue, select an item, submit an order and pay for it with no human at a browser. More than one exists because different parties wrote them for different surfaces: ACP for checkout in ChatGPT, UCP for Google's AI Mode and the Gemini app, and AP2 and the card-network specifications for the payment and identity steps that a commerce protocol carries.

Any such protocol has to specify, at minimum: how the agent discovers products; how it selects an item and variant; how it gets a quote for a delivery address, including shipping, tax and discounts; how it proves its own identity and the shopper's mandate; how it submits the order; how payment is authorised; and how confirmation returns. The quote comes before payment because a delegated credential is usually capped at an amount, so the total has to be known first. An ordinary checkout API covers only part of this, because web commerce assumes a human is present to supply what software cannot: a card typed into a form, consent to terms, and a step-up authentication challenge such as 3-D Secure, completed on a phone. Remove the human and each of those steps needs a delegated substitute.

What is settled is the shape of the exchange: HTTP requests against structured product data rather than rendered pages. The transport is a separate choice. UCP's checkout capability can be bound to a REST API, to the Model Context Protocol (MCP) or to Agent2Agent (A2A). MCP carries the calls; UCP defines what a checkout contains. That choice is covered in MCP versus API for ecommerce agents. What is not settled is which protocol prevails. Terms used throughout are defined in the agentic commerce glossary.

Four questions separate one protocol from another

Every agentic commerce protocol answers four questions: who holds the payment credential, who holds the order of record, how the agent proves it is authorised, and where the agent reads the catalogue. Compare protocols on those four and most of the remainder is implementation detail.

Credential custody and order of record carry the commercial consequence, because both can move something the merchant currently holds to another party, and both are written into a contract rather than into configuration. Agent identity and catalogue access are largely protocol-independent. Identity is a merchant policy question about which bots to trust. Catalogue access is data work that every protocol requires in much the same form.

What the published specifications say

The table summarises what each specification states about the four axes, from its own published text. It records design, not adoption.

Two things follow from the published text. UCP and ACP both keep the merchant as Merchant of Record and leave settlement with the merchant's own processor; neither, as written, has the agent platform charging the shopper and paying the merchant out. The payment and identity layers (AP2, Verifiable Intent, Trusted Agent Protocol, Agent Pay) are written to sit inside or alongside a commerce protocol rather than replace one. UCP's launch post lists more than 20 endorsers, including Adyen, Mastercard, Stripe and Visa. An endorsement list shows who signed up to a specification, not who is transacting through it.

Who holds the payment credential is the largest difference

Payment credential custody takes three forms, and each leaves the merchant in a different position.

• Reusable credential held by the merchant. The merchant receives a credential it can charge now and again later, as with a card on file. A spending limit set only in the agent constrains what the agent presents. Nothing on the payment rail stops a later merchant-initiated charge.
• Single-use, amount-restricted token. The merchant still authorises and settles through its own acquirer or payment provider and remains Merchant of Record. The token is capped at an amount and an expiry by whoever issued it, so the cap binds what the merchant can capture, and it cannot be reused. ACP's delegated payment works this way.
• Intermediary-settled payment. The intermediary charges the shopper through its own acquirer, is Merchant of Record, and pays the merchant out. The merchant receives funds from a charge it did not initiate. This is the marketplace model; neither UCP nor ACP takes it as published.

The authorisation path starts with delegated authority. The shopper grants the agent permission to spend, bounded by an amount, a merchant scope and a time window. Where that limit is enforced decides whether it binds the merchant: a limit held in the agent's application binds the agent, and a limit bound into the token binds the charge. In the first two forms, the step where a human would have passed a 3-D Secure challenge is replaced by evidence of delegation. AP2 carries that evidence as signed mandates covering what is being bought (the Checkout Mandate) and the payment for it (the Payment Mandate).

Liability for a purchase the shopper disputes is not settled. What has been published is evidence and coordination, not liability rules. AP2 states that its mandates and receipts can be combined into “a non-repudiable picture of the transaction” and that how this is used in dispute resolution is outside its scope. Verifiable Intent records what the cardholder authorised, so the parties to a dispute can refer to one audit trail. EMVCo's draft framework names Agentic Transaction Indicators, which would signal that an agent was involved in a payment, as a possible future addition. No source reviewed for this article states how issuers and acquirers allocate a chargeback when an agent buys the wrong item within a valid mandate. That is a question for an acquirer.

A merchant holding only single-use tokens or settled payouts gives up subscriptions, card-on-file reorders and post-purchase upsell, all of which need a credential it can charge again. EMVCo's draft focuses on this case: “scenarios where intent needs to be managed over time, such as recurring purchases, cumulative budgets and post-transaction activities”. Adyen lists token portability and merchant of record preservation among the functions of its Agentic Payments layer. A draft and an announcement establish direction, not how the rails behave today.

Who owns the order decides what happens after checkout

Order of record has two parts, and they can sit with different parties. The payment-rail part belongs to whoever settled the payment: that party receives chargebacks and is the only one that can refund to the shopper's card. The customer-facing part covers who sends the confirmation, who the shopper contacts when the parcel is late, who authorises a return, and who keeps the customer record for later marketing.

Under UCP and ACP as published, the merchant holds the payment-rail part. The customer-facing part depends on the platform's terms. If the agent platform runs the customer conversation while the merchant settles, return authorisation and refund execution sit with different parties, and the two have to agree who decides. The merchant receives the delivery address either way, because it ships the parcel. The question is whether it may keep the customer record for later use, which is a contract term rather than a protocol feature. A merchant that holds neither part is a fulfilment supplier.

Returns are where the difference bites hardest, because a buying decision made by software leaves no human account of intent. A shopper who says the agent chose wrongly is describing a defect in a selection they did not make. The party holding the customer-facing order has to adjudicate that.

Off-site selection removes page layout, on-site navigation and visual merchandising. It does not remove ranking or framing. In the ACES experiments (Allouah, Besbes and others, last revised December 2025), shopping agents showed strong position biases that persisted in text-only interfaces, penalised “sponsored” tags, rewarded platform endorsements, and shifted market share after small seller-side edits to product descriptions. The ABxLab experiments (Cherep and others, MIT Media Lab, last revised February 2026) found agent choices shifted “predictably and substantially” with prices, ratings and psychological nudges. Both are controlled experiments in mock storefronts, not measurements of live agent traffic. Price, availability, landed cost, delivery promise and return terms still decide a comparison; the order in which products are returned and the wording of the fields an agent reads also move it. McKinsey & Company argued on 29 May 2026 that luxury selling remains human-centred in the agentic age, which is a consultancy view rather than a measurement.

How does a merchant tell a shopping agent from a scraper?

A merchant tells them apart by what the client can prove rather than what it declares. A signed request, or a client certificate presented over mutual TLS, shows the request came from the holder of a specific private key. The weaker signals fail in different ways. A user-agent string is a header any client can copy. An entry in robots.txt is the merchant's own published directive, which a scraper can ignore while copying the user-agent token it names. A source IP address is hard to forge over a completed TLS connection, but agents run on shared cloud infrastructure where other clients rent addresses too, and an IP address proves neither the operator nor the shopper it acts for.

The specification for signed agent requests is Web Bot Auth, “HTTP Message Signatures for automated traffic”: an active Internet-Draft in the IETF webbotauth working group, by Thibault Meunier (Cloudflare) and Sandor Major (Google), and not yet an RFC. Visa's Trusted Agent Protocol and Mastercard's Agent Pay build on it. Agents register public keys in a directory, sign each request, and tag it as browsing or purchasing. Cloudflare validates the signatures for merchants on its network and rejects reused nonces, so a copied request cannot be replayed.

Most ecommerce stacks treat automated clients as hostile, so the first practical effect of any protocol is that the merchant has to let one class of bot through. Identification happens at the edge, in the web application firewall or bot mitigation layer, before the request reaches the checkout API. That layer blocks on request rate, IP reputation, header shape and absence of browser behaviour. A shopping agent is a fast, headless, datacentre-originated client fetching many product pages in sequence, so it trips every one of those. Seeing which clients actually arrive is a question of reading your own server logs.

Cryptographic proof does not settle the question by itself. Verifying that a request came from a specific keyholder still leaves the merchant deciding which keyholders it accepts. That decision is policy rather than protocol.

Agents also check price and availability far more often per order than shoppers do, so admitting one adds load. That load makes rate limiting on the inventory path a condition of letting them in.

Catalogue readability is the one requirement every protocol shares

Whatever protocol prevails, an agent has to read price, availability, variant attributes, shipping cost and return terms as data rather than as page layout. That work is the same under every competing protocol, which makes it the only part of agent readiness that is safe to complete before the protocols settle.

Agents do read prose: in ACES, rewording descriptions moved agent choices. A value that exists only in prose still has to be extracted before it can be compared, and ACES found agents from different providers weigh the same information differently. Supplying the value as a field removes the extraction step. The fields fall into two kinds.

• Static per product. Current stock at the variant level, base price, GTIN and a return window in days. These belong in the product feed and in schema.org Product and Offer markup, with OfferShippingDetails and MerchantReturnPolicy for baseline shipping and returns rules by region.
• Dependent on destination and basket. Total landed cost (shipping to an address, sales tax or VAT, duties) and a concrete delivery date. A feed cannot hold these. They come from a quote: an ACP checkout session returns taxes and fulfilment options once a fulfilment address is supplied, and UCP treats the totals the merchant returns as authoritative.

Feeds and markup fall short in two ways. Feeds go stale between refreshes, and variant granularity is often missing, so size, colour and pack quantity resolve to one price and one availability value. The markup side is the same work as making a storefront legible to LLMs, and how much of it you control depends on the platform underneath.

Google's UCP launch came with dozens of new Merchant Center attributes, such as answers to common product questions, compatible accessories and substitutes, and Google's UCP checkout requires a Merchant Center account with eligible products. The feed work pays back in fewer oversells and more accurate listings on the shopping surfaces the merchant already sells through, even if agentic traffic never arrives.

What is not settled yet

No agentic commerce protocol has a settled answer for liability on a purchase the shopper disputes, for a return initiated by software, or for what happens when an agent orders the wrong item. No protocol is dominant either, so an integration built now may need rebuilding.

Some order failures are ordinary engineering. Others have no agreed owner.

• Solvable in the API. A network retry that creates a duplicate order is prevented by an idempotency key, and ACP's checkout spec tells merchants to enforce idempotency and support safe retries. A stale price is prevented by binding the order to the quoted total and rejecting it if the live price has moved.
• No agreed owner. An agent that picks the wrong variant, or spends within its mandate on something the shopper did not want, produces a transaction that is valid and cryptographically authorised. So does an agent that loses track after an ambiguous timeout and starts a fresh checkout session, which a new idempotency key will not catch. Merchant, agent platform and payment intermediary can each argue the fault sits elsewhere. The dispute mechanisms available, chargeback and returns authorisation, were designed for a buyer who can describe their own intent.

Supporting more than one protocol means maintaining a translation layer for each one, which is a standing maintenance cost. Each layer is also somewhere for price and availability to drift out of agreement.

The evidence position: OpenAI and Stripe, Google, Visa, Mastercard and Adyen published specifications or products between September 2025 and June 2026, and EMVCo a draft framework in September 2026. That establishes what the protocols are designed to do. It does not establish that shoppers are buying through agents at volume. The unresolved failure modes are worked through in where agentic commerce still breaks.

Which commitments are reversible, and which are not?

Structured catalogue data, a quote endpoint and an enforced agent access policy are reversible and useful whichever protocol prevails. Handing payment credential custody or the customer record to one intermediary is not reversible, because recovering the customer relationship afterwards means renegotiating for it. As published, integrating UCP or ACP does not by itself hand over payment custody, since both keep the merchant as Merchant of Record. The irreversible terms sit in the platform agreement that comes with the integration.

The reversible work has an order. Complete feed and markup coverage first: variant-level price and availability, GTIN, delivery promise and return window, plus a quote endpoint that returns landed cost for a given address. Add real-time availability next, since a stale figure is what turns an agent order into an oversell. Then enforce an agent access policy at the edge: verify signed requests from the agents you admit, and rate-limit the inventory path. A written policy that admits agents changes nothing while the firewall still blocks them by default. Then monitor automated traffic. That sequence is the same one set out in what ecommerce platforms must change, read from the protocol end.

The irreversible commitments are the ones to slow down: who holds a credential that can be charged again, who owns the customer-facing order, and whether routing to one intermediary is exclusive. Ask a prospective partner the four axes as questions. Do I receive a credential I can charge again, a single-use token, or a payout? Who settles, who authorises returns, and who issues refunds? Do I keep the customer record? What identity proof will your agents present? What catalogue interface do you read, and how often? An exclusivity clause converts a reversible integration into an irreversible one, so read for it specifically.

What to do now

Complete the machine-readable catalogue before committing to any agentic commerce protocol: price, real-time availability, variant attributes, delivery promise and return window as structured data, and landed cost from a quote rather than a feed. Configure the edge to admit verified agents on signed requests and to rate-limit inventory calls, and publish the policy it enforces.

This belongs to whoever owns the product feed and merchandising data, jointly with whoever owns bot mitigation. Those two functions rarely speak, and this work needs both.

Defer credential custody, customer-record and exclusivity terms until one protocol shows demand the merchant can measure. Before any checkout integration, the merchant's logs can show only discovery: verified agent requests to product pages and inventory endpoints, requests for protocol files such as /.well-known/ucp, and referral visits from agent surfaces. Agents that read a syndicated feed, such as Merchant Center, do not appear in origin logs at all, so the feed platform's own reporting is the other half of the picture. Completed agent orders become measurable only after an integration, and UCP and ACP both allow one that keeps the merchant as Merchant of Record.

A specification release or an endorsement list is not that signal.