eCommerce AI Agents: Discovery to Checkout in 2026

An AI shopping agent can help someone compare products without being able to buy them. It can build a cart without having permission to charge a card. For merchants, the useful question is where each experience hands the shopper back to the store, and whether product, price and delivery information survive that handoff.

The landscape has moved since this article was first published. Google announced Universal Cart on May 19, 2026; its current help page describes US availability across Search and Shopping, AI Mode and Gemini Apps. OpenAI has also clarified that its shopping investment emphasizes product discovery and merchants' own checkout experiences. A feed connection, an assistant recommendation and an enabled checkout are distinct milestones.

This playbook retains the discovery-to-checkout view: the conversion evidence, five shopping surfaces, commerce protocols, merchant readiness, retailer examples and an implementation plan. Product details were checked on October 4, 2026. The practical recommendations are a diagnostic framework, not measured Digital Applied client results or a promise of placement in an assistant's answers.

Adobe's April 16, 2026 report, U.S. retailers see surge in AI traffic, but many websites are not entirely readable by machines, reports AI referral growth of 393% year over year for January through March 2026. It describes online transaction insights covering more than a trillion visits to US retail sites. That is the stated coverage of its evidence base, not a claim that every visit occurred within that quarter.

In March 2026, AI-referred visits converted 42% better than non-AI visits; the March 2025 comparison was 38% worse. These are relative differences against each period's non-AI traffic. Subtracting the reported differentials gives an 80-percentage-point change in the comparison, not an 80-point increase in the underlying purchase rate. Adobe also reports March AI visitors spending 48% longer on site and viewing 13% more pages per visit.

That makes the channel worth measuring. It does not show that adding markup causes those results. Visitors who arrive after a detailed product conversation may differ in intent, category, device or familiarity with the retailer. Channel mix can change between periods, too. A merchant should compare like-for-like product groups before attributing a change to a feed project.

For a clearly fictional arithmetic example, suppose non-AI traffic converts at 2%. A rate that is 42% higher would be 2.84%, an increase of 0.84 percentage points. This is not Adobe's underlying rate and not a target for a store. It illustrates why a relative uplift cannot be pasted into a forecast as an absolute increase.

Google's May 19 Universal Cart announcement introduced a cart spanning merchants and Google services, with price monitoring and product compatibility assistance. The announcement planned Search and Gemini availability first, with YouTube and Gmail to follow. A launch roadmap should not be read as evidence that every announced surface is available today.

The current Universal Cart help page is more useful for operational scope. It states US-only availability and lists Search and Shopping, AI Mode and Gemini Apps. Items are organized by merchant. Participating merchants can accept Google Pay within Google; other purchases transfer to the merchant's site. The same page notes limits on what Gemini and AI Mode can display or do directly in a conversation, and says order tracking depends on merchants sharing order information.

For a merchant, this makes cart transfer an important acceptance test. The destination must preserve the selected variant, quantity and offer. If a shopper chooses a particular size in the assistant but lands on a default product page, the discovery succeeded while the purchase handoff failed. Record those as different defects so the catalog team and checkout team can fix the right system.

Google's UCP Cart API guide describes a cart-creation and transfer integration across Google surfaces. Its current documentation limits this to a one-way creation of the cart on the merchant system; it does not promise ongoing synchronization, updating or deletion between systems. A Merchant Center product listing alone should not be treated as proof that this integration is enabled. Our UCP overview provides background; use current provider documentation and the merchant's actual configuration for implementation decisions.

The following map groups five consumer-facing shopping destinations discussed in this guide. It is an editorial comparison, not a census of every assistant. In each case, separate how product information reaches the service from where payment happens. A common catalog can supply several integrations, but a Google-specific feed is not a universal submission channel.

Source anchors for the map are OpenAI's product-discovery update, Perplexity's current Instant Buy help, Amazon's Alexa for Shopping announcement and Microsoft's checkout announcement. These establish documented capabilities and launch scope, not comparable adoption or conversion performance.

A retailer can be visible in a shopping answer without having a direct commercial integration. Equally, an integration can be enabled while a particular product remains ineligible or inaccurate. Keep catalog ingestion, recommendation visibility and transaction availability as separate fields in the channel register. This prevents a partner announcement from becoming a false operational completion claim.

OpenAI and Stripe introduced the Agentic Commerce Protocol with Instant Checkout on September 29, 2025. The original announcement describes communication between the agent and the merchant, with the merchant accepting or declining orders and retaining responsibility for payment processing, fulfillment and support. Its historical availability statements should not override the later discovery-focused update.

ACP is not simply a payment token. OpenAI's March announcement extends it to product discovery, while the original specification covers purchase coordination. Likewise, UCP should not be reduced to a static product-feed format. Keep the catalog, cart, order and payment responsibilities visible in architecture diagrams instead of treating either acronym as a complete implementation.

Stripe's current Shared payment tokens documentation describes scoped access to a customer's payment method, granted to a seller profile with usage and expiration limits. Those limits include currency and maximum amount. The seller then uses the token when creating a payment request. This is not a basis for saying that one approval can be reused indefinitely for later purchases. The exact authorization and permitted use must come from the integration's contract.

In a proposed checkout design, price changes after the shopper's approval should trigger a clear policy decision. A merchant can reject a stale quote or require renewed approval; it should not quietly substitute a more expensive item because the assistant inferred a broader intent. The same reasoning applies to shipping upgrades, alternative variants and subscriptions. Each changes what the customer is buying, even if the assistant regards it as a helpful improvement.

Payment success also differs from order acceptance. Plan for an inventory race, a payment retry and a delayed confirmation without creating duplicate orders. Use a stable order reference, reconcile provider events, and make the customer-visible status match the merchant system. These are design recommendations for a dependable transaction path, not a claim that every protocol or storefront already implements them identically.

Our ACP guide is useful background for the protocol vocabulary. Before implementation, have engineering and payments owners review current provider requirements together. A low-code payment integration claim does not eliminate catalog mapping, shipping logic, tax handling or customer service work.

Define the failure responses before connecting an assistant. If the merchant rejects an unavailable item, the agent should receive a clear reason and a safe next step. If a payment is pending, the order should remain pending rather than being submitted again as a new purchase. If the shopper abandons the handoff, preserve only the data the store is entitled to retain and make any later reminder follow the store's existing consent rules.

Also identify the system of record for each decision. The catalog owns the product identity; the checkout calculates the payable total; the inventory system determines whether the item can be fulfilled; and the order system records acceptance. An assistant can coordinate those systems, but a fluent explanation cannot replace their authoritative responses. This separation makes it possible to investigate a failed transaction without reconstructing the entire conversation.

The reusable investment is trustworthy product information. Maintain an authoritative catalog that supplies the website and each destination's supported feed or API. Then validate the receiving format independently. Avoid a requirements matrix that labels markup “required” for every assistant without a matching platform specification.

Google's Product structured-data guide explains the relationship between page markup and Merchant Center data. These can support richer product presentation, but correct implementation does not guarantee a particular search appearance, as Google’s general structured-data guidelines explain. Nor does it establish a general AI-citation multiplier. The useful check is whether the visible product page, structured data and submitted offer agree.

Google's GTIN guidance distinguishes products with assigned identifiers from those without them. Use the manufacturer's correct identifier where applicable; do not invent one to improve a completeness score. A handmade product without an assigned GTIN and a branded product with a missing known GTIN are different data conditions.

For each defect, record the source value, the received value, the affected product and the owner. This turns “AI readiness” into repairable work. A feed issue can require a content correction; an unavailable cart route can require onboarding; an incorrect total can require checkout engineering. Treating all of these as SEO problems delays the right fix.

The product-feed strategy guide and merchant readiness assessment provide adjacent planning context. For a store-specific implementation, our eCommerce services cover catalog and purchase-path work. The acceptance criteria should be observable product and order behavior, rather than a promised ranking uplift.

Retailer assistants and merchant tools belong in the same operating discussion but perform different jobs. Amazon's announcement describes a consumer shopping experience that uses shopping history and personalized context. Its Shop Direct and eligible Buy for Me paths also mean external websites can be part of the experience. A merchant should identify which route a customer actually used before attributing an order to an Amazon marketplace interaction.

Walmart introduced Sparky as a shopping assistant in June 2025. Its launch description focused on finding and comparing products and helping with shopping questions, while presenting further agentic capabilities as work to come. That distinction matters: a roadmap for replenishment or booking is not proof that all those functions shipped at launch. The current OpenAI update separately describes Walmart's in-ChatGPT app experience, including account linking and Walmart payments. A retailer app inside another assistant is a distinct distribution and checkout arrangement.

Shopify's March 24, 2026 Millions of merchants can sell in AI chats announcement describes Agentic Storefronts and Shopify Catalog distribution. For ChatGPT, it describes purchases through an in-app browser, with desktop linking to the store. That is a merchant-store checkout even when the shopper's journey begins inside an assistant. Store customizations and order attribution therefore remain relevant acceptance checks.

Sidekick is a different product category. Shopify's current help documentation describes an assistant in the merchant admin that provides guidance, creates content and helps complete tasks, with changes presented for review. Improving a product record with a merchant assistant does not itself prove that a consumer assistant ingested the change. Assign responsibility for the entire path from the edited record to its destination.

These examples support an organizational choice: give consumer discovery, merchant operations and transaction handling clear owners, even if the same commerce platform supplies tools for all of them. A merchandising team can improve descriptions while the payments team confirms checkout eligibility and the analytics team verifies order attribution. Combining those responsibilities in one vague “AI rollout” makes failures difficult to locate.

Adobe's April report also describes a companion survey of more than 5,000 US respondents: 39% said they had used AI for online shopping, and 85% of those users said it improved the experience. Those are survey responses, distinct from observed referral visits and transactions. The article does not supply the full sampling and weighting detail needed to treat that survey as a precise estimate for every merchant's customer base.

The operational measurement plan should distinguish discovery, referral and purchase. A recommendation can influence a later direct visit without leaving an identifiable referral. An assistant can send a visit that does not become an order. A retailer-owned checkout can record an order from a different source than the initial conversation. No single referral report resolves all of those paths.

Start with observable events: a product page arrival, a cart transfer, checkout initiation, an accepted order, cancellation and refund. Preserve the original source information where the systems expose it, while respecting the store's consent and data rules. Reconcile analytics orders with the commerce backend before treating a dashboard increase as commercial growth.

Segment results by destination, market, device and product group when the volume supports it. Compare revenue per visit alongside purchase rate, order margin and returns. A channel that sends highly researched shoppers may look strong on conversion while contributing little volume. A channel with greater sales can still be unprofitable if delivery costs or cancellations rise.

When evaluating a catalog repair, record the change date and the products affected. Check whether competing promotions, inventory availability or seasonal demand also changed. A before-and-after chart is a useful observation, but it cannot isolate causality by itself. Keep a comparable unchanged product group where feasible, and state the limits if the pilot is too small for a reliable conclusion.

A useful channel register includes the surface name, supported market, catalog delivery method, checkout route, activation evidence and date of the last successful check. Keep an observed outcome beside each stage: product found, correct variant shown, cart received, total confirmed and order accepted. This is a proposed evidence record, not a new performance score. Its value is showing exactly where a journey stops.

For example, a fictional apparel merchant may see its coat recommended correctly but discover that the destination cart opens with the wrong size. The relevant repair is variant mapping and cart transfer. Increasing the description length would not solve that defect. After the mapping is corrected, repeat the same journey with the selected size and confirm it in the merchant order record. That produces a narrow, reviewable result without claiming a conversion improvement that has not been measured.

Start with an audit of the products and markets that matter commercially. Choose a bounded set that includes common variants, a product with an assigned identifier, an item without one where legitimate, and a product with meaningful shipping constraints. This is a proposed test design, not a claim about work already completed. The purpose is to expose failures that a single easy product would miss.

Next, document the intended journey for each selected channel. Identify where a shopper sees the product, who supplies the offer, where the cart lives, who accepts payment and who sends order updates. Get confirmation of the actual merchant activation status. If the channel is still unavailable to that merchant or market, retain it as a dependency rather than announcing readiness.

Repair the shared catalog before building custom integrations around bad inputs. Resolve conflicting product IDs, missing variant attributes, incorrect offer data and unclear delivery terms. Then rerun the receiving-channel checks. A canonical catalog is valuable because its facts can be reused; channel-specific mapping remains necessary because fields and capabilities differ.

For the purchase path, use controlled tests that cover changes between discovery and checkout. Examples include an item becoming unavailable, an expired quote, an unsupported address and a payment that requires further customer action. Verify that errors are understandable and that retries cannot create duplicate orders. Do not let an agent conceal a failed purchase behind a conversational success message.

Before expanding, decide what evidence will justify the next investment. That might be accurate product retrieval, reliable cart transfer and reconciled orders for the pilot population. Commercial expansion should additionally consider margin, support demand and returns. Use the store's observed results to set the pace rather than a platform launch calendar or an unsupported claim that every merchant has a narrow deadline.

Keep a change log for provider documentation and integration settings. Recheck when the platform changes its supported markets, product eligibility or checkout model. The most durable preparation is a merchant system that can explain what it sells, quote it accurately and honor the resulting order, regardless of which assistant began the conversation.