What the Agentic Commerce Protocol is, how it compares with Google's UCP, what each asks of a merchant, and why clean product data comes first.
The short answer
The Agentic Commerce Protocol is an open spec from OpenAI and Stripe that lets an AI agent complete a purchase with a merchant directly. The merchant publishes a product feed, hosts a checkout endpoint the agent calls, accepts a delegated payment credential, and stays merchant of record. Google runs a parallel standard, the Universal Commerce Protocol.
Key takeaways
Two standards now describe how an AI agent buys something from you. The Agentic Commerce Protocol comes from OpenAI and Stripe. The Universal Commerce Protocol comes from Google. Both are public, both are moving, and both are being read by merchants as a choice they have to make this quarter.
It mostly is not. The technical spec lives at agenticcommerce.dev and engineers can read it there. This page covers the commercial version: what each protocol asks of you, where the card networks and model providers fit, and why the sequencing question matters more than the protocol question.
The Agentic Commerce Protocol, usually shortened to ACP, is an open specification for how an AI agent and a merchant complete a transaction without a human touching a website. OpenAI and Stripe published it at agenticcommerce.dev, and it is open for any agent, merchant or platform to implement.
It exists because the old interface broke. Web checkout assumes a human: a rendered page, a form, a card field, a confirm button. An agent buying on someone's behalf has none of that, and screen-scraping a checkout is fragile, unauditable and unwelcome to the merchant.
ACP replaces that with three pieces of contract.
The design principle worth internalizing is that authority stays with you. The agent cannot set a price, invent a discount, or promise delivery you did not quote. Every commercial fact in the transaction is returned by your server at request time.
That is also why a nightly feed is not enough on its own. The feed gets you found, the endpoint gets you paid, and the two have to agree. If they disagree, the agent finds out at the worst possible moment and learns not to trust you.
ACP is an OpenAI and Stripe project, and the two roles are different in a way that matters when you plan the build.
OpenAI owns the demand side. It decides which merchants are surfaced in ChatGPT answers, when Instant Checkout appears, and which categories are eligible. That is a distribution relationship, and like every distribution relationship it comes with eligibility rules you do not control.
Stripe owns the payment mechanics. The delegated credential, the tokenization, the way liability and authentication travel with the transaction: that is payments infrastructure, and it is the part the rest of the industry can adopt without adopting OpenAI's surface.
Commercially, the split means you are not making one decision. You are deciding whether to be listed on an assistant's shelf, and separately whether your payment stack can accept an agent-presented credential. The second is reusable. The first is specific to one channel.
Openness is real here but worth reading precisely. Anyone can implement the spec, so a competing agent can transact with your ACP endpoint without OpenAI's permission. What nobody else can do is put you in ChatGPT's answers. Open protocol, gated distribution.
For most merchants the implementation does not land on their own roadmap at all, because commerce platforms are implementing it on their behalf. That pushes the merchant's real work back to the catalog, which is where it belongs. The merchant guide to selling on ChatGPT covers that route in detail.
On money, separate the protocol from the channel. ACP is published as an open specification and carries no fee of its own. What carries a fee is distribution: OpenAI states that merchants pay a fee on completed Instant Checkout purchases, and it has not published the rate. Get that number from OpenAI or from your commerce platform before you model the economics.
There are two serious standards in play, not one. Google's Universal Commerce Protocol, or UCP, does the same job for Google's surfaces that ACP does for OpenAI's, and Google has documented the design in its under the hood post on UCP.
UCP expanded at Google Marketing Live on 20 May 2026. Announced partners included Nike, Sephora, Target, Walmart and Wayfair, plus Shopify merchants such as Fenty and Steve Madden, with buy now pay later through Affirm and Klarna. That is a broad retail coalition rather than a pilot.
The differences that actually affect a merchant are about starting position, not philosophy.
One more practical difference. Some large retailers actively block agent traffic altogether, and that stance tends to apply across both protocols rather than to one of them, because it is a policy position about who gets to buy on your site, not a technical objection to a spec.
Neither is obviously winning, and a merchant reading either spec as a bet on a winner is reading it wrong. The realistic end state looks like card networks: multiple rails, common merchant-side requirements, and platforms abstracting the difference.
On what UCP asks for, Google is explicit. Merchant Center stays the hub for your product data, but a feed on its own does not switch on agent checkout: only listings carrying the native commerce checkout eligibility attribute get the buy experience.
The rest is onboarding rather than data. You submit an interest form, complete the technical integration and open a Google Pay and Wallet Console account. Your payment provider does not have to offer Google Pay on your own site, but it does have to be able to process Google's tokens.
Strip out the vocabulary and both protocols ask for the same four things. The overlap is the useful finding.
Whether one checkout implementation can serve both is not something either side promises. Google describes UCP as compatible with the open standards it names, and ACP is a separate specification with its own endpoints and its own payment presentation. Plan for two integrations until your commerce platform tells you otherwise, and let the platform absorb the difference where it can.
Read those two lists next to each other and the sequencing answer falls out. Four shared requirements, all of them data and systems work that takes months. Three differences, all of them integration work that takes weeks and that your platform may do for you.
Protocols describe the conversation. Somebody still has to make an agent-initiated payment safe, and that layer is being built in parallel by parties who are not taking sides.
Mastercard is building the payments side of this in public, under names like Agent Pay and Agent Suite. The card networks' interest is straightforward: an agent-initiated transaction needs an identity for the agent, a verifiable mandate from the cardholder, and a liability model, or issuers decline it. Network-level plumbing solves that once for every protocol above it. Which of those products you can actually use, in your market and through your acquirer, varies, so ask your payment provider rather than reading it off a press release.
Anthropic publishes Claude-based shopping and merchant agent blueprints, and those blueprints do not commit to a single commerce protocol. Shopify's reference implementation built on them connects through Shopify Catalog, UCP and Shop sign-in. That matters less as a competing standard and more as a signal about volume: the agents doing the buying will not all come from two companies, and a merchant integration that only works with one assistant is a dead end.
Instinct, an invite-only personal agent, pays through Stripe's Link wallet, which shows the other pattern. Some agents will not integrate with merchants at all. They will carry a wallet and transact through whatever rail already exists.
Meta launched Muse, a personal AI agent, on 8 September 2026, running in a private cloud VM with a visible browser and its own Sentinel permissions system. An agent that drives a real browser buys from you through your normal checkout, which is a third pattern again and needs no integration at all.
The merchant lesson from all three is the same. Agent identity, payment credentials and mandates are being commoditized by people whose job that is. Your product data is not being commoditized by anyone, which is why it is where your effort belongs.
The protocol decision is reversible and cheap. The data decision underneath it is neither. That asymmetry should drive your plan.
Implementing a checkout endpoint against a published spec is a scoped engineering job, and on a major commerce platform it is somebody else's scoped engineering job. Adding a second protocol later reuses most of the first one's work, because the hard parts, real-time pricing, tax, shipping, order status, are yours either way.
Restructuring a catalog is not like that. Moving variant meaning out of titles and into fields touches your PIM, your feed logic, your theme templates and usually your merchandising team's habits. It takes a quarter, not a sprint, and it cannot be undone and redone cheaply.
So the sequence is: fix the data, then connect whatever rails your customers are actually arriving on. Clean product data pays off under either standard, and under paid shopping, and under classic search. Choosing a protocol before your variant structure is correct is choosing a distribution channel for bad data.
There is a measurable reason not to treat this as one channel with two names. Productrise, studying 2M+ listings across 100k+ SERPs in the US and UK during August 2026, found only 1.28% product overlap between classic Google search and AI Mode, and that the main seller differed on 49.6% of matched products. Different surfaces are already showing different shelves.
One practical exception. If a specific protocol is the only route to a customer segment you already sell to, and your data is close to ready, connect it and fix the rest in parallel. Sequencing advice is not a reason to sit out a channel you can already serve. Our overview of AI shopping agents covers who is actually buying through which surface.
You can find out in a day whether a protocol decision is even your next problem. Run this against your live catalog, not a spreadsheet export.
The work that decides your position under any protocol is slower than the integration and far less discussed.
Rebuilding the variant model comes first. Human shoppers read titles and look at pictures, so catalogs encode meaning there. Agents read fields, so the meaning has to be migrated, and that usually means changing how your team enters products rather than just running a script once.
Precise taxonomy is second. A product filed in a vague category competes with everything else in it. Agent requests are narrow, so precision is what puts you on a three-item shortlist instead of a forty-item one.
Real-time inventory is third, and it is an ongoing commitment. Cancellations after an agent has confirmed an order are the most damaging signal you can send to a system that ranks on reliability.
Fourth is demand. When the product page stops doing the persuading, the persuading has to happen earlier, in creative that makes someone ask for your category at all. That is a volume and iteration problem before it is a taste problem.
We work on two of those four directly. On catalog, we do Shopify product data fixes for agent readability: variant grouping, taxonomy, literal product fields and live price and stock sync. On demand, we run performance creative as a service at 100+ creatives a month with a 5-7 day turnaround, and our creative intelligence is trained on 32M+ ads.
We are not a protocol vendor and we do not implement your checkout endpoint. What we cover is the full creative chain, intelligence, strategy, production and campaign management, plus the product data that agents read. Analytics-only tools stop at the report, and premium production shops stop at the asset.
If you want to see what that looks like in practice, start with creative as a service or the agentic commerce pillar.
It is a published set of rules that lets an AI assistant buy something from a merchant without using a web checkout. OpenAI and Stripe released it openly. The merchant provides structured product data and hosts an endpoint that prices and completes a cart, and the agent presents a scoped payment credential instead of a card number. The merchant remains the seller.
No. They are separate standards solving the same problem for different surfaces. ACP comes from OpenAI and Stripe and reaches ChatGPT users. Google's Universal Commerce Protocol reaches Google surfaces and expanded at Google Marketing Live on 20 May 2026 with partners including Nike, Sephora, Target, Walmart and Wayfair. Both require structured catalog data, live pricing and programmatic cart confirmation from the merchant.
No, and choosing early is usually the wrong instinct. The shared requirement, a machine-readable catalog with correct variants and real-time price and stock, takes a quarter to get right and serves both. The protocol-specific integration takes weeks and is often handled by your commerce platform. Fix the data first, then connect whichever rails your customers are arriving on.
Under both standards the merchant remains merchant of record, so the charge, the fulfillment obligation, the refund and the chargeback stay with you. That is exactly why the payment layer is being standardized separately, with the card networks building agent payment products, such as Mastercard's Agent Pay and its wider Agent Suite, to give agent-initiated transactions verifiable identity and mandates. Availability varies by market and by acquirer, so confirm the specific liability terms with your processor before you enable anything.
If you are on a major commerce platform, probably not, because the platform implements the endpoints on your behalf and you enable the feature. If you run a custom stack, yes: a checkout session API, delegated payment handling with your processor, and feed maintenance. Either way, the catalog data work is a merchandising and operations job rather than a purely technical one.