Agentic commerce is commerce in which an AI assistant does the buying work: it interprets a request, compares options, assembles a cart and — on some surfaces — completes the checkout on the shopper's behalf. The store is no longer serving a person clicking through a page template. It is serving software that reads structured product data, calls an endpoint, and presents a payment credential scoped to a single transaction. That shifts the burden from presentation to accuracy: data completeness, availability freshness, machine-readable policies and a checkout that can be initiated from outside the store.
TL;DR
- Agentic commerce is a transaction layer, not a visibility tactic. Being named in an AI answer and being able to accept an order from an agent are separate problems.
- Two main shapes exist. An assistant can hand the shopper to the store checkout or, for eligible merchants on supported surfaces, conduct checkout within the assistant interface.
- Open standards are emerging, but implementations differ. ACP describes commerce integration in the OpenAI ecosystem, UCP covers a wider agentic-commerce lifecycle, and AP2 secures authorisation and payment inside a commerce protocol.
- Price and availability must be validated at checkout. A feed supports discovery, while the merchant remains responsible for current totals, stock, tax and fulfilment terms when it accepts an order.
- In the current OpenAI and Google implementations, the merchant remains merchant of record. Fulfilment, returns, complaints and transaction responsibilities do not automatically transfer to the assistant platform.
- Attribution depends on the path. A handoff can create a conventional store session. A native API checkout may not, so partner and source metadata should be recorded when the checkout is created.
- Blanket bot blocking is the wrong instrument. Crawler policy governs reading; API authentication and rate limits govern transacting.
- The failure modes are operational: a wrong quoted price, stale availability, promotions that exist only in the front end, and support tickets for an order the customer never clicked through.
This article covers the transaction layer. For the layer above it — how a product gets named, compared and cited in an AI answer at all — see GEO for e-commerce: product visibility in AI Overviews, ChatGPT and Perplexity. The umbrella view of how AI search changes organic acquisition sits in AI SEO: optimising for search engines, AI Overviews and LLMs, and the Google-specific mechanics are in Google AI Mode: what it means for brands.
What Changes When an Assistant Buys Instead of Recommending
The buyer becomes a program with a timeout. A human tolerates a slow product page, a variant selector that needs two clicks and a shipping cost that appears at step three of checkout. An agent calls an endpoint, waits a defined number of seconds, and either gets a structured answer or moves to a seller that gives one. Everything a store currently hides behind interaction — computed shipping, stock per warehouse, the real price after a cart-level promotion — has to exist as data before the interaction.
Inconsistent price or availability becomes a transaction risk. A stale feed can produce a rejected cart, a cancelled order or a difference between the offer shown to the shopper and the checkout total. The feed supports presentation and selection; the merchant validates price, stock, fulfilment and tax again before accepting the order. That is the responsibility split described in OpenAI's commerce documentation.
Not every order has a conventional session. A handoff to the store can preserve campaign parameters and analytics identifiers. With a native API checkout, there may be no browser visit on the merchant domain. Those paths need different measurement designs, covered below.
Two shapes of agent purchase
Most internal confusion comes from treating these as one thing.
| Agent-assisted purchase | Agent-completed purchase | |
|---|---|---|
| Who completes checkout | The shopper, in the store's checkout | The agent, through the store's checkout API |
| What the store must expose | Accurate product data, durable links, correct price and stock | Feed plus checkout-session endpoints and a delegated-payment path |
| Payment | Normal store payment methods | Credential delegated to the merchant or its PSP, scoped by amount and expiry |
| Session data | Handoff parameters can be retained in the store checkout | A browser session may not exist on the store domain |
| Typical failure | Link lands on a sold-out variant or a different price | Cart rejected, order cancelled, price mismatch |
| Effort to support | Feed and page hygiene | Engineering on API, auth, idempotency, order flow |
A store that only wants the first shape still has real work to do, and that work is a subset of the second. Nobody skips the data layer.
The Protocol Layer: How Agent Purchases Are Wired
There is no single protocol used by every assistant and merchant. As of July 2026, three complementary pieces matter most: ACP, UCP and AP2. Read the current documentation for the platform you are integrating because feature availability, partner programmes and endpoint scope continue to change.
Agentic Commerce Protocol (ACP)
ACP is an open specification for connecting buyers, their agents and businesses, maintained by OpenAI and Stripe. It defines composable pieces rather than one monolithic integration:
- A product feed. A regularly refreshed feed — CSV or JSON — carrying identifiers, descriptions, pricing, inventory, media and fulfilment options. Required fields exist so price and availability can be shown accurately; recommended attributes such as media, reviews and performance signals influence relevance.
- Agentic checkout. The agent calls merchant endpoints to create, update and complete a checkout session. The merchant independently validates the data, determines fulfilment options, calculates sales tax, evaluates payment signals and processes the charge.
- Delegated payment. Instead of handing over a raw card, the agent platform prepares a one-time delegated payment request constrained by a maximum chargeable amount and an expiry. Stripe's Shared Payment Token is described as the first implementation compatible with that spec.
The division of responsibility matters more than the wire format. OpenAI's documentation states that OpenAI is not the merchant of record: the store validates, charges, fulfils and handles tax — including the parts nobody enjoys, like returns and chargebacks.
Separate the public specification from product access. OpenAI's documentation says Instant Checkout is currently available to approved partners. Publishing a product feed alone does not enable native sales in ChatGPT; a merchant must meet the programme requirements and complete the relevant integration process.
Universal Commerce Protocol (UCP)
UCP is an open standard covering a broader agentic-commerce lifecycle: discovery and catalogue access, cart operations, identity linking, checkout, order management and post-purchase support. Google uses UCP for direct-buying capabilities in AI Mode and Gemini, with documentation describing native checkout and an optional embedded merchant checkout.
UCP can build on existing Merchant Center data and interoperate with AP2, A2A and MCP. It is not automatically available to every store: Google operates an expression-of-interest process, and parts of the roadmap — including richer multi-item carts, account linking and post-purchase capabilities — are being introduced in stages. The merchant remains merchant of record in Google's documented model.
Agent Payments Protocol (AP2)
AP2 is Google's open protocol for payment authorisation and security: it provides evidence that an agent was authorised to make a particular purchase with a particular payment instrument. The specification describes signed mandates, including a Checkout Mandate recording agreed items and terms and a Payment Mandate authorising the payment.
AP2 does not replace catalogue, cart or checkout APIs. Its specification describes it as a security feature within a commerce protocol and states that it is compatible with UCP. The commerce protocol conducts the purchase; AP2 provides a verifiable authorisation trail. That evidence can support settlement and dispute handling, but it does not remove the merchant's duty to validate the order or meet applicable consumer obligations.
Provider details in this space change fast. This is the state as of July 2026 — protocol versions, endpoint shapes, crawler names and merchant programmes are revised regularly, so check the vendor documentation linked at the end before implementing.
Where the assistants sit
For ChatGPT shopping, OpenAI's help documentation describes product results shown for shopping-intent questions, selected independently rather than sold as ads, using structured metadata from first-party and third-party providers alongside details such as price and reviews. Merchant selection can consider availability, price, quality, and whether the seller is the maker or primary seller — a strategic point for brands selling through resellers.
For Perplexity shopping and other answer engines, treat behaviour as something to measure rather than read off a specification: shopping-style answers, product cards and merchant programmes change over time. Use a representative prompt set and server-log inspection instead of assuming one setting controls it. For Google, product visibility still depends in part on accurate Merchant Center data and eligibility across Google surfaces. UCP adds a transaction layer for supported programmes; it is not AI-specific SEO markup that improves visibility by itself.
Glossary
- Agentic commerce — commerce where an AI agent performs the buying steps, up to and including completing checkout, on a shopper's behalf.
- Agentic checkout — a checkout flow created and driven through API calls from outside the store rather than by a human in the front end.
- Checkout session — the server-side object holding cart, buyer details, fulfilment options, tax and totals for one agent-driven purchase attempt.
- Delegated payment token — a single-use payment credential constrained by a maximum amount and an expiry, passed to the merchant or its payment service provider instead of raw card details.
- Mandate — in AP2, a signed record of what was agreed: which items and purchase details, and which payment instrument is authorised.
- Merchant of record — the party responsible for processing the sale and the transaction obligations allocated by contract and law; in the OpenAI and Google implementations described here, it remains the merchant.
- Idempotency key — a client-supplied identifier that lets a retried API call be recognised as the same request, so a network failure does not create two orders.
- Machine-readable policy — delivery, returns and warranty rules expressed as structured fields an agent can evaluate, rather than prose on a page.
What a Store Needs Before an Agent Can Transact
Each row is a capability, not a tool purchase.
| Capability | Why an agent depends on it | What "ready" looks like |
|---|---|---|
| Product data completeness | It must know whether two listings are the same item and whether this variant fits | Stable identifiers (GTIN, MPN, SKU, brand), attributes in fields not titles, complete variant matrix |
| Price and availability freshness | A feed-to-checkout mismatch can stop the purchase | Defined refresh interval, monitored lag and a declared system of record for each field |
| Machine-readable delivery rules | Options and cost must be returned during the session | Shipping methods, cost logic, cut-off times, destination coverage as data |
| Machine-readable returns rules | An agent needs the return window before it commits | Window, conditions, who pays return shipping, exclusions — per category if they differ |
| A stable API | Scraping a JS-heavy page is not a contract; an endpoint is | Versioned endpoints, documented errors, predictable latency, idempotency |
| Externally initiated checkout | The purchase begins outside the store | Create/update/complete session flow, server-side tax and totals, orders in the normal order system |
| Authentication and abuse control | The store must know which agent is calling and be able to revoke it | Per-partner credentials, rate limits, amount ceilings, replay protection |
Product data completeness is the gate
Most stores fail here first, and it rarely looks like a data problem. It looks like a product whose size lives only in the title, a variant whose colour exists in the front end but not in the feed, or a bundle that exists only as a front-end rule. An agent cannot infer any of that: if the attribute is not a field, the product is not comparable, and a product that is not comparable does not get chosen. Feed mechanics are covered in what a product feed is and how to use it, the wider sweep in how to audit an e-commerce store.
Freshness needs a number and an owner
"Near real time" is not a specification. Two questions decide readiness: what is the maximum acceptable lag between the system of record and the value an agent can read, and who owns each field. An agent may read from a properly synchronised feed, cache or API read model rather than the system that performs the write, but the lag and synchronisation errors must be measured.
Externally initiated checkout is an engineering commitment
Creating an order from an authenticated external call means applying the same domain rules for tax, fulfilment, promotions, stock reservation, idempotent retries, cancellation and refunds that the front end uses. Otherwise the store runs two order flows with two sets of bugs. In custom e-commerce development, those rules should be separated from the interface from the start. This does not mean every merchant needs a platform written from scratch; integration capability, data ownership and control of the checkout are what matter.
Agentic Order Attribution: GA4 Is Only Part of the Picture
Start by identifying the purchase path. If an assistant redirects the shopper to the store, campaign parameters and a normal analytics session can be retained. If checkout is completed natively through an API, there may be no visit, referrer or browser identifier on the merchant domain. A better UTM convention cannot repair a session that never existed.
GA4 Measurement Protocol can send a purchase event from a server, but it is designed to supplement measurement. Reliably joining the event to an existing user or session requires genuine identifiers such as client_id and, where appropriate, session_id. If the partner did not provide them or consent does not permit their use, do not invent them. The event may still support limited technical reporting, but the order system remains the source of truth for partner and revenue.
The workable approach is to stop expecting analytics to discover the channel and stamp it at the source instead:
- Label the order at checkout-session creation. The store knows which credential made the call; derive a channel value from the authenticated caller and write it onto the order as a first-class field.
- Keep one order per agent purchase, keyed idempotently. Retries are normal in API commerce, and duplicates destroy every downstream number.
- Reconcile in the order system. Revenue by partner for native agent checkouts is primarily an order-database question; GA4 can be an additional layer.
- Do not fabricate identifiers. A synthetic
client_idorsession_iddoes not recreate a real visit and distorts reporting. - Separate evidence from hypotheses. Branded search or direct traffic can move alongside AI exposure, but those changes do not prove its effect.
| Question | Where the answer actually lives | What it cannot tell you |
|---|---|---|
| How many orders came from agents? | Order database, channel field stamped at session creation | Which prompt or comparison led to it |
| Which products do assistants select? | Order data plus a fixed prompt-check routine | Full impression volume — no platform exposes it |
| Are agent-driven sales growing? | Trend of orders carrying partner and checkout-type fields | The full effect of recommendations completed outside the integration |
| Why did an agent stop choosing us? | Feed error logs, availability history, API error rates, session rejection reasons | The platform's ranking weights |
| What did the shopper agree to? | The signed purchase record and the store's own session log | Anything the store did not persist at the time |
The last row is the one to design for before it is needed. A dispute six weeks after an agent purchase is answerable only if the store kept what it quoted, when it quoted it, and against which stock state.
Where This Breaks
A price the assistant got wrong. The quote can come from a cached feed, a stale category price, or a promotion the front end computes but the API does not. The store then chooses between honouring a figure it did not set and rejecting a purchase the shopper believes is complete. The mitigation is one pricing source, promotions computed server-side, and a defined rule for what happens when the session total disagrees with the feed price.
Availability that was true an hour ago. Overselling in a normal store produces an apologetic email. Overselling to an agent produces a cancelled agent order — and availability is explicitly among the merchant considerations OpenAI describes for product results. Stock accuracy stops being a warehouse concern and becomes a distribution concern.
Support for a purchase the customer never clicked through. The shopper remembers the assistant, not the shop. They may have no account, may not recognise the store name on their statement, and may contact the assistant platform first. Support needs a way to locate the order without the usual session or account trail, and staff need to know the store owns the return, the complaint and the refund regardless of where the purchase began.
Consumer rights on an agent purchase. Applicable distance-selling and consumer-protection duties do not disappear because software operated the interface. The integration must present the required pre-contract information, capture valid confirmation and preserve evidence of what was agreed. The exact requirements vary by product, market and transaction design, so technical protocol compliance needs a separate legal review.
Abuse arriving through a legitimate door. Automated carting, card testing and scalping look like agent traffic. The instrument is per-partner credentials with rate limits and amount ceilings plus monitoring on rejection rates, not a robots.txt rule.
How Space Ads Approaches Agentic Commerce Readiness
Our starting point is a map of the merchant's systems: the owner of price, stock, attributes, promotion rules and order status, plus the acceptable lag for each synchronisation. We then compare feed, product page and checkout calculations and verify that the front end and API use one set of commerce rules. Only after the data layer is controlled does integration with a supported merchant programme make sense. Visibility work — brand entity, citable content, crawler policy and citation monitoring — remains a separate layer described on our AI SEO service page. Partner and checkout type belong on the order; a GA4 event is added only where the implementation has valid identifiers and an appropriate consent basis.
Readiness Plan
- Decide the field owners. For price, stock, attributes, order status and returns, name one system of record per field and write it down. Ambiguity here defeats every later step.
- Instrument freshness. Measure the real lag between the true value and the externally exposed value, set a threshold, and treat breaches as incidents.
- Close the data gaps. Fill identifiers, move attributes out of titles into fields, complete the variant matrix, express delivery and returns rules as structured fields.
- Make policy machine-readable per category. Where return windows or delivery constraints differ by product type, they must differ in the data too.
- Audit the checkout surface. Can an order be created, taxed, totalled and cancelled from an authenticated external call, through the same code path as the front end?
- Add credentials, limits and idempotency. One credential per partner, rate limits, amount ceilings, replay protection, and logging that retains what was quoted.
- Stamp channel at session creation. Order-level attribution, not analytics archaeology.
- Brief support and finance. Who owns the return, how an agent order is located, what the statement descriptor says, and the escalation path to the platform.
- Monitor a representative prompt set. Choose the cadence based on catalogue change and seasonality; interpret the result as a sample and trend, not complete impression measurement.
Common Mistakes
| Common mistake | Do this instead |
|---|---|
| Treating agentic commerce as a content or PR exercise | Fix the data and checkout layers first; visibility without transaction readiness converts into cancelled orders |
| Blocking all AI user agents to "stay safe" | Separate crawler policy from transactional access; authenticate and throttle agents at the API |
| Letting the front end own promotion logic | Compute promotions server-side so an API session sees the same price a human would |
| Building a second order flow for agent purchases | Reuse the same order pipeline; two flows means two sets of stock and tax bugs |
| Synthesising analytics sessions for agent orders | Stamp channel on the order and report agent revenue from the commerce database |
| Assuming the assistant platform handles returns | The store remains merchant of record; brief support and finance accordingly |
| Publishing return and delivery rules only as prose | Express them as structured fields an agent can evaluate before committing |
| Treating "near real time" as a specification | Define the acceptable lag as a number, assign an owner, monitor it |
FAQ
What is agentic commerce?
Agentic commerce is commerce in which an AI agent performs the buying steps on a shopper's behalf — interpreting the request, comparing options, assembling a cart and, on some surfaces, completing checkout. The distinguishing feature is that the transaction is initiated by software through a machine interface rather than by a human in a front end.
Is agentic commerce the same as being recommended by an AI shopping assistant?
No. Being recommended is a visibility outcome: the assistant names a product or seller in an answer. Agentic commerce is a transaction outcome: the assistant either hands the shopper to a checkout or completes the purchase itself. A store can be highly visible in AI answers and still be unable to accept an agent-initiated order.
Do I need ACP or UCP to sell through an AI assistant?
Not always. If an assistant recommends a product and sends the shopper to the store, accurate product data, current feeds and working links are the main requirements. ACP, UCP or a partner-specific interface becomes relevant when checkout is conducted outside the standard store front end. The correct integration depends on the assistant platform and access to its merchant programme.
How does ChatGPT choose which merchant to show?
OpenAI's documentation describes product results as selected independently rather than sold as ads, using structured metadata from first-party and third-party providers together with details such as price and reviews. Merchant selection can consider availability, price, quality and whether the seller is the maker or primary seller.
Who is the merchant of record in an agent purchase?
In the OpenAI and Google implementations described here, the merchant remains merchant of record. It validates and fulfils the order and handles the responsibilities assigned by the integration agreement and applicable law. Do not assume the same allocation for every future marketplace or intermediary; check the terms of the specific programme.
Can agent-driven sales be tracked in GA4?
It depends on the path. A handoff to the store checkout can be measured as a normal visit if the partner passes campaign and analytics identifiers. A native API checkout may not create a session on the merchant domain. Measurement Protocol can send a server-side event, but synthetic client_id or session_id values do not create valid attribution. Record the partner on the order and use the commerce database as the primary revenue record.
Should a store block AI crawlers if it does not want agent purchases?
Blocking crawlers is the wrong control. Crawler directives govern whether content can be read for search and training; they do not govern whether a transactional endpoint can be called. Refusing agent purchases is an authentication decision at the API.
What usually breaks first when a store is not ready?
Availability and price accuracy. The first visible symptoms are agent orders that have to be cancelled and totals that disagree with what the shopper was told, because a feed or cache drifted from the system that owns the number.
In Short
- Agentic commerce is about transactions, not recommendations; readiness is an operations and engineering problem.
- Two shapes matter: a handoff to the store checkout and checkout conducted in the assistant interface.
- ACP and UCP describe commerce flows in different ecosystems; AP2 supplies an authorisation and payment-security layer.
- In the current OpenAI and Google implementations, the merchant remains merchant of record and must design operations around that responsibility.
- Each field needs a declared system of record, monitored synchronisation and checkout-time validation.
- A native API checkout may not create a browser session. Record partner and checkout type on the order; use GA4 only where genuine identifiers and the appropriate consent state are available.
- Crawler policy and transactional access are different layers; conflating them removes visibility without adding control.
Sources
- OpenAI Developers — Agentic Commerce: key concepts
- OpenAI Developers — Delegated Payment Spec
- Agentic Commerce Protocol — specification repository
- Stripe Docs — Agentic Commerce Protocol
- Google for Developers — Universal Commerce Protocol
- Universal Commerce Protocol — UCP specification
- Google — Agent Payments Protocol (AP2) specification
- OpenAI Help Center — Shopping with ChatGPT Search
- Google Search Central — AI features and your website
- Google Analytics — Measurement Protocol
Continue Learning
- GEO for e-commerce: product visibility in AI Overviews, ChatGPT and Perplexity
- AI SEO: optimising for search engines, AI Overviews and LLMs
- Google AI Mode: what it means for brands and marketing
- What is a product feed and how to use it
- How to audit an e-commerce store
- Custom e-commerce development
- AI SEO service
Continue reading
E-Commerce Replatforming Without Losing Search Visibility
A migration is not a data transfer with a launch date attached. It is a project with its own workstreams — URL mapping, integration parity, cutover sequence and post-launch verification — and the visibility you lose is lost in those workstreams, not in the platform choice.
Vendor Lock-In in E-Commerce: What You Actually Own
Vendor lock-in is not one clause in a contract — it is a set of dependencies across seven layers of your e-commerce tech stack. Here is the ownership audit you can run on your own store this afternoon.
Marketing Calendar 2027: Plan the Year Around Lead Times, Not Dates
Build a practical 2027 marketing calendar with verified US and UK dates, market-specific checks and realistic lead times. Use the planning framework to align campaigns, stock, creative, tracking and fulfilment.
