What does it mean for an agent to take over the buying process?
Agentic commerce is when users no longer search for a product and add it to their cart themselves; instead, an AI agent carries out the goal they've given it from start to finish. The user says, "find and buy a waterproof sports watch suitable for a twelve-year-old for under 2,000 TL." The agent breaks this sentence into sub-criteria, gathers candidate products, compares price and stock status, picks one and completes the payment step using authorization the user granted in advance.
The real shift is in where the decision gets made. In classic e-commerce, the seller works to catch a human's eye: image quality, the title, social proof, a promotion badge. In the agentic flow, a software layer steps in between, and that layer doesn't see the page the way a person does. It reads the product as data split into fields, scores it against the criteria and drops anything that doesn't match from the candidate list. How good the image looks isn't an input at this stage.
The real difference from the classic e-commerce funnel
The classic funnel consists of impression, click, browsing, cart and checkout, and each step is optimized for human attention. A user browsing a category page can change their mind, be swayed by a banner or drift toward a similar product recommendation. The agent skips the steps in the middle. It doesn't browse category pages, isn't influenced by campaign design and doesn't see the cross-sell block.
This has two consequences. First, the competitive surface shifts from presentation to data integrity. Second, the result set narrows. Instead of a user choosing among ten links on a search results page, an agent compares two or three candidates and recommends one. A page's search engine optimization performance still matters, because agents largely build their candidate pool from search infrastructure and the data the seller provides. But the difference between ranking third and dropping off the candidate list is much sharper than a difference in click-through rate.
How does an agent find a product?
For an agent to evaluate a product, that product needs to be described consistently in three separate places: in the product feed the seller submits, on the product page itself and in the seller's machine-callable endpoints.
The product feed is the real catalog the agent sees
On the Agentic Commerce Protocol side, the product feed is a required component. In the feed specification published by OpenAI, the fields required for each row include the product ID, title, description, product page URL, brand, image URL, price and availability. On top of these, two eligibility flags are required, indicating whether the product can be used in search and checkout flows. For products open to checkout, the seller's privacy policy and terms of use also become required fields. Because the seller submits the feed, the agent doesn't have to guess its way through the site; it works from the data the seller has declared.
On Google's side, the equivalent is Merchant Center. In the first reference implementation of the Universal Commerce Protocol, a business needs an active Merchant Center account and checkout-eligible products to appear on conversational surfaces. Both ecosystems follow the same logic: the agent deals not with the catalog itself but with the structured copy of the catalog the seller delivers.
On-page structured data
The feed alone isn't enough, because some agents also read the product page directly and use consistency between the feed and the page as a kind of trust signal. That's why it matters that the price, currency, stock status and product ID in the JSON-LD markup on the product page match the values in the feed. Markup that can't be parsed or that contradicts the feed lowers the product's credibility rather than keeping it in the candidate pool. Using a structured data audit tool to confirm that the markup on your pages is actually valid, and fixing it where it isn't, is a prerequisite for feed work.
Capability declaration and checkout endpoints
Above the discovery layer sits another question: "which operations does this seller support?" The Universal Commerce Protocol solves this with a standard declaration file. The business publishes a JSON manifest at /.well-known/ucp, and the agent reads it to learn which capabilities are enabled, which endpoints can be called and which payment configurations are supported. Checkout sessions are opened and updated through separate endpoints, and identity linking runs over OAuth 2.0, meaning the user doesn't hand their password to the agent. The Agentic Commerce Protocol offers similar flexibility and can be implemented either as a classic REST interface or as a Model Context Protocol server.
Why do payment and authorization need a separate protocol?
Today's card infrastructure is built on a single assumption: the person approving the transaction is the human who is present at that moment. When an agent steps in, that assumption collapses. Three questions go unanswered: what exactly did the user authorize, which amount and which product was that authorization limited to, and who is liable in a dispute? These aren't questions product data can solve, which is why a separate layer emerged.
The Agent Payments Protocol fills this gap with cryptographically signed, verifiable digital credentials. The cart and conditions the user approved are carried in one credential, and the payment amount and the payment instrument to be used in a separate one. This separates the information shared with the seller from the information the payment network sees, and leaves behind an auditable trail. Google launched the protocol and positioned it as an extension of the Agent2Agent protocol, and its standardization has since moved to FIDO Alliance working groups.
The Agentic Commerce Protocol tackles the same problem from a different angle. There, payment details are never exposed to the agent; instead, an authorized payment token is passed, and the seller remains the merchant of record. Both approaches point to the same need: a payment made by an agent has to be as provable as one made by a human.
Three protocols working at three different layers
Because these three names keep coming up side by side, it's easy to get the wrong impression. They aren't alternatives doing the same job.
| Protocol | Who develops it | What problem it solves | Current status |
|---|---|---|---|
| ACP | OpenAI and Stripe | Product feed, cart, checkout session and authorized payment | Open-source specification, marked as beta, with live integrations on the ChatGPT side |
| AP2 | Launched by Google, being standardized in FIDO Alliance working groups | Proving the agent's payment authority and making liability traceable | Open specification, payment network and provider integrations ongoing |
| UCP | Google and Shopify | The entire commerce flow, from discovery to post-purchase | Open standard, live on Google surfaces in the US, expanding to new markets |
The layers aren't fully separate. ACP and UCP genuinely overlap on the checkout side, and a seller may need to support both. AP2 sits underneath both of them, because proving payment authority is the same problem in either flow.
Where does the Universal Commerce Protocol fit in this picture?
UCP is the broadest in scope of the three. It brings product discovery, capability negotiation, checkout and post-purchase processes together under a single standard. It's developed by Google and Shopify, published as open source under the Apache 2.0 license, and backed by more than twenty retailers, payment networks and platforms. It doesn't impose a single transport layer for communicating with agents; it can work over Agent2Agent, Model Context Protocol or plain REST interfaces. On the payment side, it's described as compatible with AP2, meaning it hands payment authorization off to that layer rather than embedding it.
Its practical effect shows up on Google's own surfaces. In AI Mode in Google Search and in the Gemini apps, users in the US can shop from participating retailers, and a universal cart feature that combines different sellers into a single cart is being built on the same infrastructure. UCP-based checkout launched first in the US, then expanded to Canada and Australia, with the UK among the planned markets. UCP is positioned not as a replacement for ACP but as a protocol that coexists with it.
What did the pullback of in-chat checkout reveal?
The most instructive part of this picture is the experiment that didn't work. A model in which purchases were completed inside ChatGPT without ever leaving the conversation was tried and pulled back. In the setup that replaced it, discovery stays in ChatGPT, while payment is completed on the seller's own site or in the seller's own app built inside ChatGPT. The protocol itself didn't disappear; on the contrary, it expanded toward the discovery side.
The reasons behind the pullback show sellers exactly where to focus. Sellers didn't want to hand checkout over to a third party, because loyalty programs, payment data and the post-purchase relationship are tied to that step. The second reason was more technical: when the agent had to derive product and stock information instead of getting it from the seller, real-time price and stock accuracy didn't hold up.
The conclusion is clear. Investment in the discovery layer pays off in either scenario, while the payment layer is still shifting. The same distinction applies to visibility in generative search engines. A brand being represented on AI surfaces is a gain that's independent of, and comes much earlier than, being able to take payment on that surface.
Product data an agent can't read can't be bought
In classic SEO, good copy partly compensates for missing structured data. In the agent channel, there's no such compensation mechanism. Agents generally don't guess a missing field; they treat a product with an empty field as having failed an elimination criterion. That's why missing data here isn't a loss of points but a direct reason for dropping out of the candidate pool.
In practical terms, here's what sellers need to do:
- Use a permanent ID for each product and keep that ID identical between the feed and the page.
- Don't let the price, stock and shipping values in the feed diverge from those on the site.
- Provide variants as separate rows and link them all to a shared group ID.
- Fill in matching fields such as brand, GTIN and MPN, because agents use these fields to match the same product across different sellers.
- Don't leave fields used for filtering, such as size, color, material, compatibility and intended use, empty.
- Publish return and shipping terms in a machine-readable form.
The cost of inconsistency isn't just invisibility. When an agent trusts the price or stock information and places an order the seller then can't fulfill, cancellation and return rates go up and the seller's credibility goes down. That's why product data hygiene isn't a one-off project but a maintenance task that should be treated as part of ongoing SEO work.
A realistic timeline for Türkiye
The discovery layer is already working in Türkiye. Users research products, compare brands and ask about prices in Gemini, ChatGPT and AI answers in search. That's where machine-readable product data pays off today, and there's no need to wait.
It wouldn't be honest to say the same about the payment layer. UCP-based checkout started in the US, and the announced expansion order is Canada, Australia and the UK. Türkiye isn't on that list. On the ChatGPT side, the in-chat payment model was pulled back even in the US. On top of that comes a local layer: adapting card authorization flows, payment provider integrations and return processes to these protocols is separate work, and that work hasn't visibly started in Türkiye yet.
In practice, this means one thing. Building a checkout API for an agent that can't reach you yet is a premature investment. Fixing your product data isn't premature, because the same data is also used on classic shopping surfaces, comparison sites and marketplaces. When payment protocols arrive in Türkiye, the seller who's ready won't be the one who starts writing a feed that day but the one whose catalog is already clean.
Frequently Asked Questions
Is agentic commerce replacing SEO?
No, but it changes what SEO produces. Agents don't build their candidate pool out of nothing; they build it from search infrastructure and the data sellers provide. So indexing, page accessibility and topical authority work remain valid. What's changing is that product data quality is being added alongside this work as a required component.
Can agents find my product without a product feed?
Partly, because structured data on product pages is also read. But in protocols that handle checkout, the feed is explicitly a required component. A catalog without a feed can still appear on the discovery side, but it's largely out of the picture on the transaction side.
Which protocol should a small e-commerce site prioritize?
Starting with protocol selection is the wrong order. The common prerequisite for all three protocols is clean, complete product data. Once the catalog side is fixed, the priority is set by which surface the business's customers are on. If your e-commerce platform offers these integrations at the platform level, following that route is less costly than building endpoints yourself.
Who owns the customer relationship in an order placed through an agent?
Both major protocols are built on the seller remaining the merchant of record and retaining ownership of the customer relationship. In practice, the critical point is whether return, exchange and support processes are also open to the agent. If order status and return terms aren't machine-readable, every post-purchase step falls back to a human.
