Ecommerce used to be a three step pipeline: rank, click, convert. Agentic commerce changes the middle of that funnel. A shopper expresses intent, an agent assembles options, and the purchase can happen inside the surface where the intent was captured, like ChatGPT, Google Search AI Mode, or Gemini. That shift creates a new integration layer for merchants and a new optimization layer for marketers.
Two protocols are trying to standardize that integration layer:
- ACP (Agentic Commerce Protocol), stewarded by OpenAI and Stripe, with a first flagship experience called Instant Checkout in ChatGPT.
- UCP (Universal Commerce Protocol), published by Google as an open source standard intended to unify how many agents and surfaces talk to merchants and payment providers across the full journey.
And if you care about revenue, not just standards, there is an emerging practice that sits above both:
- ACO (Agentic Commerce Optimization), meaning: make your product data, policies, and site truth machine readable and trustworthy enough that agents can choose you, explain you, and complete checkout with fewer clarifying questions.
What follows is a technical, implementation oriented view of ACP, UCP, and ACO.
ACP vs UCP: what each protocol is really optimizing for
Core intent
ACP (OpenAI + Stripe): make checkout “agent ready” inside ChatGPT
- ACP is positioned as an open standard that lets a buyer’s agent and a merchant exchange structured checkout state, step by step, so an agent can present the UI and collect buyer inputs while the merchant keeps control of order logic and fulfillment.
- Stripe’s documentation explicitly describes an agentic checkout flow where the agent handles the interface and payment credential collection, while the seller keeps the backend data model and payment processing.
UCP (Google + ecosystem): collapse integration complexity across many surfaces
- Google describes UCP as a “common language and functional primitives” across consumer surfaces, business backends, and payment providers, compatible with Agent Payments Protocol (AP2) and interoperable through APIs, A2A, and MCP. The UCP spec formalizes “capabilities” as the core verbs, and uses a “profile” document hosted at a well known URI to declare identity, supported capabilities, and endpoints. (UCP)
Journey coverage
- ACP is centered on product feed plus checkout orchestration, fulfillment events, and delegated payment patterns to support Instant Checkout in ChatGPT. UCP explicitly targets standardization “from discovery and consideration to purchase and order management,” and Google’s launch materials emphasize end to end coverage, including post purchase support.
Merchant of record and control
Both protocols emphasize that merchants keep control, but they operationalize it differently:
- OpenAI’s ACP “get started” guide emphasizes merchants keep their customer relationship, receive payment directly, can accept or decline orders, and handle post purchase.
- Google’s UCP post similarly stresses the business remains the Merchant of Record and can maintain a customized checkout via an embedded option. (Google Developers Blog)
ACP deep dive: what you actually build
If you strip away the hype, ACP is a stateful checkout API designed for an agent driven UI.
1) You expose checkout endpoints that return rich state
Stripe’s ACP spec shows the canonical lifecycle around a Checkout Session:
- Create a checkout session with items and optional buyer and fulfillment address.
- Retrieve a checkout session by id.
- Update a checkout session (line items, shipping address, fulfillment option).
- Complete a checkout, which is where payment is processed and the order is created.
A key architectural point is that the response returns the full state the agent needs to render the next step: line items, totals, fulfillment options, messages, and links, plus a status like ready_for_payment.
2) The agent becomes the checkout UI
Stripe draws the line clearly:
- Traditional checkout: seller owns UI, data model, credential collection, payment processing.
- Agentic checkout: agent owns UI and credential collection; seller still owns data model and payment processing.
That changes what “conversion rate optimization” means. Your PDP microcopy matters less than whether your policies, options, and constraints can be expressed unambiguously in structured state.
3) Payments: tokenization and delegated flows
Stripe’s ACP docs reference secure sharing of payment credentials via a SharedPaymentToken (SPT) for processing in the seller’s existing payment stack. That is the security posture you should expect to see more of: the agent can collect and pass payment authorization without merchants ever handling raw credentials directly.
4) Product feeds are not optional
OpenAI’s ACP onboarding flow calls out that merchants should provide a product feed according to the Product Feed Spec, in addition to implementing the checkout API. This is the first major ACO signal: agents need a canonical, current product truth source.
UCP deep dive: capabilities, profiles, and payment proof
UCP is broader than checkout. It is a protocol family designed to let agents and merchants negotiate what is possible, then execute.
1) “Capabilities” are the core design primitive
The official UCP spec defines a capability as a standalone core feature a business supports, like Checkout or Identity Linking, and describes capabilities as the fundamental verbs of UCP.
This matters because it makes agent merchant communication composable. A merchant can say: I support discovery and checkout, but not subscriptions, or I support checkout plus an extension for loyalty.
2) A “profile” document declares what you support
The spec defines a profile as a JSON document hosted by businesses and platforms at a well known URI, declaring identity, supported capabilities, and endpoints.
If ACP feels like “here is the checkout API,” UCP feels like “here is how agents discover your API surface area and then call it in a consistent shape.”
3) Payment authorization is built around verifiable proof
Google’s developer post highlights a modular payment handler design and says authorizations are backed by cryptographic proof of user consent. The UCP spec formalizes this with concepts like Verifiable Digital Credentials and Verifiable Presentations.
Even if you never touch those details directly, your security, fraud, and consent narrative becomes part of your marketing. Agents will favor merchants that can prove safe, deterministic execution.
4) Transport interoperability: APIs, MCP, A2A, AP2
Google positions UCP as compatible with AP2 for payments and integrable via APIs, A2A, and MCP.
This is an important difference from typical “platform integrations.” It is designed to survive a world where the same user intent can be expressed in many assistants, not just one.
Where ACO fits: marketing when the buyer is an agent
ACO is not a replacement for SEO. It is the layer that makes SEO outcomes purchasable by agents.
Agents do not just rank pages. They:
- decide which products are eligible for a user’s constraints
- verify claims against multiple sources
- choose the path of least friction
- fail fast when the data is inconsistent
Google has already previewed this direction by talking about new Merchant Center attributes that go beyond keywords and capture answers to common product questions, compatible accessories, and substitutes for discovery in conversational commerce surfaces. )
Industry SEO coverage is starting to frame this as an agent first evolution of ecommerce optimization where schema, feeds, and authority influence inclusion in agent mediated journeys.
ACO in practice: the technical checklist
1) Make product truth easy to ingest
- clean product feeds, high update frequency, strict id consistency across channels
- canonical identifiers: SKU, GTIN, brand, variant attributes
- structured availability, lead times, backorder rules
Why: both ACP and UCP workflows assume agents can reason over structured state and up to date product facts.
2) Convert your policies into machine readable constraints
- shipping thresholds, returns windows, warranty, exclusions, hazmat rules
- what disqualifies an order (PO boxes, international restrictions, age gated items)
Why: OpenAI explicitly calls out merchants can accept or decline orders and must handle post purchase. The agent needs the decision logic early to avoid dead ends. 3) Reduce ambiguity in variant selection
- size charts, fit guidance, compatibility matrices, bundle definitions
- deterministic variant options with clear “choose one of” vs “optional add on”
Why: ambiguity forces agent clarification, which increases drop off and pushes the agent to a simpler competitor.
4) Instrument the “agent funnel”
Track events that did not matter before:
- agent initiated checkout sessions
- missing attributes that triggered questions
- cancellation reasons and decline reasons
- time to ready_for_payment, time to completion
ACP responses include a status field and messages array designed for this kind of instrumentation.
5) Build authority signals agents can verify
- citations in your own ecosystem: manufacturer docs, third party reviews, consistent specs
- consistent pricing and availability across surfaces
Agents will cross check. If your PDP says one thing and your feed says another, you lose.
Agentic commerce is not a future concept. It is already shaping how discovery and checkout work in AI-driven surfaces.
ACP and UCP are the rails. ACO is the competitive advantage.
The brands that win will not be the ones with the most creative landing pages. They will be the ones whose commerce systems are clear, deterministic, and trustworthy enough for an agent to buy on behalf of a human.
