Agentic Commerce Protocols: How the Competing Standards Differ.

Several agentic commerce protocols are being pushed at once, and they 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 actually commits to.

The context is dated and public. Adyen announced Adyen Agentic on 16 June 2026 and described it as a universal translator between AI agents and merchant checkout. A translator only makes commercial sense if more than one protocol exists. Google published retailer tooling for agentic shopping on 11 January 2026.

This article compares the protocols on four axes and stops there rather than arriving at a product. One caveat stated up front: almost everything published on agentic commerce is vendor announcement or consultancy projection, so claims about adoption here are limited to what can be dated and attributed. The releases themselves, and what each one assumes about the merchant, are catalogued in what shipped in 2026.

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 the parties defining them each want a different party holding the payment credential. Those parties include model providers, card networks, payment processors and marketplace platforms.

Any such protocol has to specify five things at minimum: how the agent discovers products, how it selects a specific item and variant, how it submits an order, how payment is authorised, and how confirmation returns. An ordinary checkout API covers only part of that, 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 every one of those steps needs a delegated substitute.

What is settled is the shape of the exchange, which is ordinary HTTP against structured product data rather than rendered pages. That is a different question from whether to expose it as a protocol or a plain integration, which is covered in MCP versus API for ecommerce agents. What is not settled is which protocol prevails. This article does not name protocols as adopted, because no source available to it establishes their status. The terms used throughout are defined in the agentic commerce glossary.

Four questions separate one protocol from another

Every agentic commerce protocol answers four questions, and the answers are what differ: 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 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, and the answer barely changes with the protocol that asks. Catalogue access is data work that every protocol requires in much the same form.

The table above deliberately compares axes rather than named protocols. Naming protocols and characterising their positions would mean repeating vendor framing as industry fact, and no source available here supports it.

Who holds the payment credential is the largest difference

Agentic commerce protocols split into those where the merchant receives a payment credential it can charge, and those where an intermediary holds the credential and hands the merchant a restricted token or an already settled payment. That split decides who carries the dispute, who sets the spending limit, and whether the merchant can bill the customer again later.

The authorisation path starts with delegated authority. The shopper grants the agent permission to spend, normally bounded by an amount, a merchant scope and a time window. A limit constrains what the agent may present, not what the merchant may capture. A merchant holding a chargeable credential is therefore in a different position from a merchant holding a single-use network token restricted to one amount.

Under merchant-held custody, the merchant authorises through its acquirer as usual. The step where a human would have passed a 3-D Secure challenge is replaced by whatever evidence of delegation the protocol carries. Under intermediary-held custody, the intermediary authorises against the shopper and the merchant sees a payment it did not initiate.

Liability is genuinely unresolved. Card scheme rules were written around a cardholder who is either present or has previously agreed to a merchant-initiated transaction. No source available here states how the schemes currently treat an agent-initiated purchase. Treat it as a question for an acquirer rather than an assumption.

A merchant that never sees a chargeable credential also gives up subscriptions, card-on-file reorders and post-purchase upsell, all of which need a stored card. Adyen's 16 June 2026 announcement signals that payments vendors are positioning around exactly this point. An announcement establishes intent rather than how the rails behave.

Who owns the order decides what happens after checkout

If the agent's platform is the order of record, the merchant becomes a fulfilment supplier: it ships the goods while another party holds the customer relationship, the returns conversation and the transaction data. If the merchant is the order of record, it keeps all three and takes on serving a buyer who was never on its site.

Order of record is a practical question rather than a technical one. It determines who sends the confirmation email, who the shopper contacts when the parcel is late, who authorises the return, who issues the refund, and who holds the delivery address and the payment relationship afterwards. 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 order has to adjudicate that.

Merchandising narrows under either model once selection happens off-site. What still influences the outcome is price, real-time availability, total landed cost, delivery promise, return terms and the structured attributes an agent can compare. Presentation, sequencing and persuasion do not survive the move. McKinsey & Company argued on 29 May 2026 that luxury selling remains human-centred in the agentic age. That is a consultancy view rather than a measurement, and it is worth reading as a claim about categories where the agent is not the decider.

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 that the request came from a party holding a specific private key, which an impostor cannot reproduce, whereas a declared user-agent string, a published IP range and an entry in robots.txt are assertions any client can copy. Most ecommerce stacks already treat automated clients as hostile, so the first practical effect of any agentic commerce protocol is that the merchant has to let one specific class of bot through, and protocols differ in what proof the agent offers.

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 the signals available to it: request rate, IP reputation, header shape, 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, and no protocol removes that obligation. 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 identical across every competing protocol. It is therefore the only part of agent readiness that is safe to complete before the protocols settle.

A human shopper infers a great deal from a page. An agent infers nothing, so it needs each of those inferences supplied as a field: current stock at the variant level, total landed cost including shipping and tax, a delivery date rather than a shipping class, and a return window in days. The read path runs from a product feed or an inventory API into structured attributes, and only the fields it exposes can influence selection.

A product feed and schema.org Product and Offer markup are the machine-readable surface most merchants already have. Both fall short in the same 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. Attributes stated only in prose descriptions are invisible to comparison. The markup side of this 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 11 January 2026 retailer tooling release points at the same feed-side requirements. This 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 no human approved, for a return initiated by software, or for what happens when an agent orders the wrong item. Nor is there a dominant protocol, which means an integration built now is likely to be rebuilt.

Order accuracy is the first unresolved failure path. An agent creates a loss with no agreed owner in several ways: when it selects the wrong variant, buys at a stale price, spends beyond what the shopper understood it to be authorised for, or submits a duplicate order on retry. Merchant, agent platform, and payment intermediary can each argue the fault sits elsewhere. The dispute mechanisms available are chargeback and returns authorisation, both 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 deserves stating plainly. The available material on this topic is vendor announcement and consultancy publication. That is enough to establish that Adyen and Google announced agent-facing tooling in the first half of 2026. It is not enough to establish that anyone is buying 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 and a documented agent access policy are reversible and useful whichever protocol prevails. Handing payment credential custody or the order of record to one intermediary is not reversible, because recovering the customer relationship afterwards means renegotiating for it.

The reversible work has an order. Complete feed and markup coverage first. That coverage includes variant-level price and availability, GTIN, total landed cost, delivery promise and return window. Add real-time availability next, since a stale figure is what turns an agent order into an oversell. Then publish an agent access policy stating which automated clients are permitted and what proof they must present. Then monitor automated traffic, so that when volume arrives it is visible in the merchant's own logs. 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 the chargeable credential, whose system is the order of record, 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, or a token I cannot? Whose system is the order of record, and who issues refunds? 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 surface before committing to any agentic commerce protocol. That surface carries price, real-time availability, variant attributes, total landed cost, delivery promise and return window as structured data rather than page copy. Publish a written policy alongside it, naming which automated clients are permitted and on what proof.

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.

Catalogue readability is worth doing now because every protocol requires it. Credential custody and the order of record are worth deferring until one protocol shows buyer volume the merchant can measure in its own logs, because those terms differ between protocols and are hard to reverse.

A vendor announcement is not that signal.