Agentic Checkout and the Protocol Stack

Why this module exists

In eighteen months, agent-initiated checkout went from a demo to two competing open standards backed by the largest commerce and payment companies in the world. Retail leaders are now being asked to commit engineering to something whose addressable volume is, today, small.

That is a genuinely hard decision, and it is made badly in both directions: by teams that implement everything because it is in the trade press, and by teams that dismiss it because the volume is small this quarter.

This module gives you the landscape as it stands, the questions that decide it for your business, and a way to hold a position that survives the next announcement.

7.1 What a protocol standardises

Strip the branding and every agentic commerce protocol addresses the same four problems:

Problem	What the protocol defines
Discovery	How an agent learns what you sell, at what price, in what stock
Cart and intent	How a selection is assembled and confirmed on behalf of a buyer
Payment	How value moves, and with what credential — usually scoped to this purchase
Fulfilment and after	How order status, delivery, returns and support flow back to the agent

What none of them standardises: your margin, your inventory truth, your returns policy, or who is liable when it goes wrong. Those remain yours, and Module 8 is about the last one.

Three layers. Most of the noise is at the top; most of the durable requirements are in the middle.

7.2 The landscape, as at August 2026

Agentic Commerce Protocol (ACP). Published by OpenAI and Stripe on 29 September 2025 under Apache 2.0 and maintained in the open. It defines how an agent and a merchant complete a purchase, with the merchant remaining merchant of record. PayPal joined as a payment provider in October 2025; Stripe shipped supporting tooling in December 2025; purchasing inside ChatGPT relaunched for US users on 16 February 2026.

Then, on 4 March 2026, OpenAI withdrew in-chat checkout — retaining product discovery, and routing the purchase itself back to merchants and third-party apps. The reasons given were sales tax, fraud prevention and real-time inventory synchronisation.

What the withdrawal does and does not mean

It does not mean ACP is dead. The specification is permissively licensed, published, and used beyond ChatGPT; the payment rails underneath kept shipping; UCP launched five weeks earlier and is unaffected.

It does mean two things you should carry into the decision below. First, the surface that gets to withdraw is not the surface you should build a single-vendor integration for — §7.5. Second, and more importantly, the capability was not blocked by anything exotic. It was blocked by tax, fraud and inventory accuracy: three items on the six-requirement list in §7.3, all of which are yours to fix and none of which becomes unnecessary if a checkout button disappears.

If you took a "prepare, not implement" position in 2025, this validated it. If you took "wait," it did not — the preparation work is what makes the next launch cheap.

Universal Commerce Protocol (UCP). Announced by Google at NRF on 11 January 2026, co-developed with Shopify, Etsy, Wayfair, Target and Walmart, released as an open specification under Apache 2.0 and offered to a standards body, and endorsed by a long list including Adyen, American Express, Mastercard, Visa, Stripe, Best Buy, Macy's, The Home Depot and Zalando. Microsoft announced Copilot support in the same period, which matters: UCP is not confined to Google's own surfaces. It covers discovery through checkout and post-purchase, and adds a cross-retailer cart with Google Pay, PayPal and buy-now-pay-later options.

The payment layer. Distinct from both, and moving on its own track. Visa Intelligent Commerce and Mastercard Agent Pay shipped agent-scoped credentials during 2025; Visa followed with a Trusted Agent Protocol, and Mastercard has continued with agent-identity and intent-verification work through 2026. Google's Agent Payments Protocol (AP2), published in September 2025 with sixty-plus payment and commerce partners, sits underneath UCP and contributes the piece the others leave implicit: a cryptographically signed mandate recording what the human actually authorised. Remember that word — Module 8 turns it into your dispute defence.

The direction across all of them is consistent: make an agent-initiated transaction distinguishable at the network level, so it can be scored, authorised and disputed differently.

7.3 The requirements that are common to all of them

This is the practical core of the module, and the reason a wait-and-see position is not the same as doing nothing.

Whichever protocol matters in your market, an agent transacting with you needs the same six things — and every one of them also improves your existing business:

A machine-readable catalogue with reliable price and stock. Module 4, unchanged.
Real-time availability. Not nightly. An agent that buys an item you cannot ship creates a refund, a dispute and a delisting risk.
A programmatic path to create an order with an idempotency guarantee, so a retried request does not become two orders.
Order status a machine can read — accepted, shipped, delivered, refunded.
A returns and cancellation path that is not a phone call. Agents cannot use your call centre.
An identity and authorisation model for who may transact on a customer's behalf, and within what limits.

Numbers 1, 2 and 4 you very likely need anyway. Numbers 3, 5 and 6 are the genuinely new engineering, and they are the ones to scope now even if you implement nothing.

The European seventh requirement

If you take payments in the EEA or the UK, strong customer authentication under PSD2 applies to the transaction regardless of who initiated it, and no protocol removes it. In practice this means agent flows have to resolve to one of the routes the regulation already provides — a merchant-initiated transaction under a mandate established with SCA, a delegated-authentication arrangement with your PSP, or an applicable exemption under your acquirer's fraud rates — and that resolution is a conversation with your PSP and acquirer, not with a protocol maintainer.

Have it before you enable anything. A European retailer that implements an agentic checkout without an SCA answer has built a flow that either declines or is unenforceable, and will discover which one in production.

7.4 The decision

Five questions, in order. The first two usually settle it.

1. Where are your customers already transacting? If a meaningful share of your category's demand is already reaching a surface that has shipped agentic checkout in your market, this is a channel decision. If not, it is a roadmap decision. Answer with the Module 2 surface map, not with the trade press.

2. What does your platform already give you? If you are on a commerce platform that has implemented protocol support, your cost is configuration and policy rather than engineering. That single fact moves many retailers from "wait" to "enable and learn." Ask your platform vendor a specific question: what is live, in which markets, and what do we have to do?

3. What is the marginal order worth? Agent-sourced orders may carry different mix, different basket composition and different return rates. If you cannot yet know, say so — and instrument the order source before you have any, so the first hundred are countable.

4. What breaks first? Usually inventory accuracy or returns handling, not payments. Find your weakest of the six requirements above; that is your real project.

5. What would change your mind? Write the trigger down. "When a surface in our top-two markets ships agentic checkout in our category with real transaction volume, we move from prepare to implement." A position with a trigger is a decision. A position without one is a delay that nobody revisits.

::: case Marlowe & Finch — the decision, and the thing it actually exposed The board wants "an answer on ChatGPT checkout." The e-commerce director works the five questions.

Where are the customers. European markets, home and lifestyle. Agentic checkout availability is patchy in their categories and markets. Present addressable volume: small.

What does the platform give. Their commerce platform has protocol support on its roadmap, partially available. Cost to enable is configuration plus a policy decision, not a build.

What is the marginal order worth. Unknown. They add order-source tagging anyway, in a week, so the answer exists when the volume does.

What breaks first. The audit is uncomfortable. Real-time availability is nightly, not live. There is no programmatic returns path — every return starts with a form and a human. Idempotency on order creation has never been tested. Payments, the thing the board was worried about, is the one part that already works.

The trigger. Written down: when either agentic checkout ships in home and lifestyle in Germany or the UK with observable transaction volume, or the platform makes it a configuration toggle, we move to implement. Reviewed at every quarterly business review.

The decision is prepare, not implement. But the preparation is real work with a name: move availability to near-real-time, build a programmatic returns endpoint, test idempotency. All three would be on the roadmap anyway — the protocol question simply exposed that they had never been prioritised.

That is the pattern to expect. The protocol conversation rarely produces a protocol project; it produces an honest audit of your commerce operations.

7.5 What not to do

Do not build to a single vendor's proprietary integration unless the volume already exists. Open standards under permissive licences are a materially better bet than bespoke connectors.

Do not treat endorsement as adoption. A logo on an announcement slide tells you a company signed a press release. Ask the two questions from §7.2 — live or endorsing, and can a shopper complete a purchase in my market today — and note that OpenAI itself was live and then was not.

Do not let the protocol decision block the legibility work. Modules 3 and 4 pay off against demand that exists today, at every level of protocol adoption.

Do not skip the identity model. Of the six requirements, "who may transact on this customer's behalf, within what limits" is the one with legal consequences, and it is the one most often deferred.

Exercise — Take a position

Time: 90 minutes. Produces the artefact for this module.

Answer the five questions in writing, with evidence for the first two rather than impressions.
Score the six common requirements — have it, partial, do not have it — and identify your weakest.
Write the position: implement, prepare, or wait, with the date it was taken.
Write the trigger that changes it, and name who watches for it.
Name the review date, and put it in the same governance forum as everything else.
Ask your platform vendor the specific question from step two, in writing, this week.

Self-check

What do agentic checkout protocols standardise, and what do they explicitly leave with you?
Which of the six common requirements would you most likely fail today, and who owns it?
Why is "prepare" a decision rather than a delay, and what makes the difference?
A vendor cites forty named partners. What two questions establish what that means?
What is your written trigger, and who is watching for it?