ChatGPT Shopping and Agentic Commerce: The Complete Guide to Product Discovery, Merchant Feeds, and AI Sales

Getting found is the first step. What happens when the shopper decides to buy? Your product has to reach a system that can take payment. That’s the part we’re looking at here.

AI commerce is still unsettled. What a company announces and what you can use as a merchant can be far apart. As of October 2026, there are three competing transaction layers. They disagree on basic questions, and two of the three require access to programmes you can’t simply join.

---

The three-layer map, and why it matters

Commercial activity on AI surfaces splits into three layers, and confusing them is the single most common analytical error in this market:

1. Discovery - the model decides which products to name. This is a retrieval and ranking problem.
2. Decision - the shopper compares options, reads reviews, asks about returns. This is a structured-attribute problem.
3. Transaction - the shopper commits money. This is a protocol, compliance and payments problem.

Almost all public commentary on this market sits in layer 1. Layer 3 is where the real constraints live, and where the news is mostly bad news for merchants.

Three transaction layers exist today:

	ACP (Agentic Commerce Protocol)	UCP (Universal Commerce Protocol)	Copilot Checkout
Led by	OpenAI + Stripe	Google, with Shopify, Etsy, Wayfair, Target, Walmart	Microsoft, with PayPal, Shopify, Stripe
Spec status	In beta (stated on the repository)	Spec published and Apache 2.0, but merchant onboarding is early access	Rolling out in the US
Who is merchant of record	Merchant	Merchant	Merchant
How you join	Application to OpenAI; approved partners	Interest form / waitlist; early access, US only	Shopify: automatic. Others: application
Geography as documented	US-first	US only	US only (Copilot.com)
Normative spec public?	Yes, Apache 2.0	Yes, Apache 2.0, plus SDKs and a conformance suite	No - Microsoft points at ACP

All three agree on one thing that matters enormously: the merchant remains the merchant of record. Nobody is trying to become Amazon. Google states it plainly in its UCP FAQ, OpenAI states it in its commerce documentation (“OpenAI is not the merchant of record in the Agentic Commerce Protocol”), and Microsoft’s Copilot Checkout announcement makes the same promise.

---

What actually happened: OpenAI launched checkout, then stepped back

This is the most consequential commercial story of the past year, and it’s routinely reported without its second half.

Phase one - Instant Checkout. OpenAI’s announcement “Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol” is dated 29 September 2025 on the page itself. It described buying without leaving the chat: US ChatGPT Free, Plus and Pro users could buy from US Etsy sellers, with more than a million Shopify merchants promised. Instant Checkout supported single-item purchases only, and the Agentic Commerce Protocol was open-sourced. The repository’s LICENSE file is Apache 2.0, and the spec’s first snapshot is also dated 2025-09-29.

One detail in that post is easy to misread, because it says two things that pull in opposite directions in the same paragraph. Merchants pay a fee on completed purchases and the service is free to users, and OpenAI states the fee “doesn’t influence ChatGPT’s product results” and that “Instant Checkout items are not preferred in product results.” Then, three sentences later:

“When ranking multiple merchants that sell the same product, ChatGPT considers factors like availability, price, quality, whether a merchant is the primary seller, and whether Instant Checkout is enabled, to optimize the user experience.”

Both statements are in the source. The defensible reading is that checkout enablement matters as a tie-breaker among competing sellers of the same product, while not being a paid-placement signal - but note that OpenAI published the no-preference claim first and the ranking-factor list second, and never reconciled them. Any merchant told “checkout does not affect ranking” and any merchant told “enabling checkout is a ranking input” is reading the same paragraph.

The second detail: ACP isn’t an OpenAI specification. The repository lives at agentic-commerce-protocol/agentic-commerce-protocol, jointly maintained by OpenAI and Stripe. If you have the older github.com/openai/agentic-commerce-protocol path bookmarked, it now returns 404.

Phase two - the pivot. In a post reported by CNBC on 24 March 2026, OpenAI said this:

“We’ve found that the initial version of Instant Checkout did not offer the level of flexibility that we aspire to provide, so we’re allowing merchants to use their own checkout experiences while we focus our efforts on product discovery.”

The full context is in OpenAI’s own post, “Powering Product Discovery in ChatGPT”. ACP was extended to carry product feeds and promotions so that catalogues are “fully represented” in ChatGPT. Target, Sephora, Nordstrom, Lowe’s, Best Buy, The Home Depot and Wayfair are named as already integrated for discovery. And Shopify merchants get their data in automatically through the Shopify Catalog, requiring “No additional work … from individual merchants.”

The transaction itself moved outward. Shopify’s Mani Fazeli, quoted in OpenAI’s post, described the new model directly: users “complete purchases on the merchant’s online store through an in-app browser, so everything happens seamlessly, with the merchant’s brand front and center.” Walmart got its own in-ChatGPT app supporting account linking, loyalty and Walmart payments.

So the honest summary of ChatGPT commerce in October 2026 is: ChatGPT is strong on discovery and weak on owning the transaction. Instant Checkout wasn’t switched off - but the gate is now described in the documentation at the feed layer rather than the checkout layer, and the sentence doing the gating work is worth reading carefully:

“Onboarding product feeds in ChatGPT is currently available to approved partners.”

That’s from the Get Started guide, and it’s narrower or broader than most people assume depending on which reading you take. Read narrowly, it means feed submission is gated. Read the way the same page behaves - no self-serve path is offered anywhere - and the practical position is that ChatGPT commerce remains access-controlled. Either way the centre of gravity has moved to feeds plus merchant-owned checkout.

That’s a genuinely different design from Google’s, and it’s the axis along which these platforms actually differ.

---

Google’s UCP: the most developed protocol, the narrowest door

Google announced UCP on 11 January 2026. The announcement post is the correct source for who is involved, and it’s worth quoting precisely because secondary coverage of this announcement is almost entirely unreliable:

“UCP was co-developed with industry leaders including Shopify, Etsy, Wayfair, Target and Walmart, and endorsed by more than 20 others across the ecosystem like Adyen, American Express, Best Buy, Flipkart, Macy’s Inc., Mastercard, Stripe, The Home Depot, Visa and Zalando.”

Note what is not in that list. Amazon, Meta, Microsoft and Salesforce are frequently attached to UCP in third-party coverage; Google’s own announcement doesn’t name them. A later Google post says partners “like Commerce Inc, Salesforce and Stripe will implement UCP on their platforms in the near future” - Salesforce framed there as a future implementer, not a co-developer. If you need the authoritative membership list, the January post is the source.

The status is the real story, and “early access” and “generally available” are both being used - about different things. Google’s own Merchant Center documentation is unambiguous about the merchant side:

“During this early access program phase, the Merchant Center onboarding experience is gradually available in the United States.”

“The checkout feature enabled by UCP is available for select merchants. To participate in this early access program, submit the interest form and complete the required technical implementation.”

That page scopes itself to “only products sold within the United States.” The practical summary is early access in the US, not an open protocol anyone can adopt.

UCP is, however, real and versioned. The current native checkout implementation is version 2026-04-08, with 2026-01-23 available as a prior version. Google recommends running a separate endpoint per specification version so traffic can be isolated and rolled back. Capability negotiation uses namespaced capability identifiers such as dev.ucp.shopping.checkout and dev.ucp.shopping.fulfillment.

Unlike ACP, UCP’s normative specification lives in a public repository, Universal-Commerce-Protocol/ucp, under Apache 2.0. Alongside it sit Python and JavaScript SDKs and a conformance test suite you can run your endpoints against. This is a meaningful maturity difference: you can build and self-test a UCP implementation today without Google’s permission. You can’t get a UCP merchant account without Google’s.

The repository also settles a question that the blog posts blur. UCP is transport-agnostic - the spec describes businesses offering capabilities over REST, MCP or A2A - and names AP2 mandates as a security foundation. It doesn’t mention ACP anywhere. Google’s UCP documentation claims interoperability with AP2, A2A and MCP; the specification itself goes no further than that.

Since the 19 May 2026 Google I/O post and the 15 October 2026 launch post, Universal Cart is live in the US across Search and the Gemini app. Google describes it as built on “the 60+ billion continually refreshed product listings in Google’s Shopping Graph.” Both claims are Google’s own.

One caution about documentation drift, because it will send you down the wrong path. Google’s UCP landing page still says UCP reaches “Gemini web (app coming soon)”, while the FAQ and the October launch post describe the mobile app as live. Docs lag announcements here.

Drift runs the other way too, and this is the case that actually matters for implementation. The UCP FAQ still describes multi-item carts and account linking as “upcoming” capabilities - but the Native checkout overview, last updated 16 October 2026, states flatly: “Google now supports multiple distinct line items in a single checkout session,” and documents the flow as a POST /checkout-sessions carrying a separate object per unique item in line_items. A separate Google post describes Cart and Identity Linking as new optional capabilities already available.

That same page is also where the operational commitments live, and they aren’t soft. Google publishes service level objectives you’re “expected to meet” for the Native Checkout REST API: POST /checkout-sessions at ≥95% availability with 50th-percentile latency under 1 second, PUT under 1 second, and POST .../complete under 6 seconds at the median. The status lifecycle is enumerated - incomplete, ready_for_payment, ready_for_complete, completed, canceled, error - with error available from version 2026-04-08 onward. A checkout backend that can’t hit a one-second median isn’t conforming, regardless of how well its catalogue scores.

---

The eligibility gate: what you cannot sell through an agent

To enable checkout, a UCP listing must carry native_commerce(checkout_eligibility). If it’s FALSE or missing, the product isn’t eligible - and missing defaults to FALSE. Setting the flag is necessary but not sufficient, because Google’s documentation lists categories that are ineligible for checkout regardless.

From “Prepare your Merchant Center account”, last updated 2 October 2026:

Financial products and recurring billing models

• Subscriptions: products requiring recurring billing cycles
• Installments: transactions requiring merchant-mandated payment plans or financing

Customised goods and fulfilment options

• Personalised goods (engravings, monograms)
• Non-new or final sale items - refurbished, used, or marked “Final Sale”
• Pre-order items
• Bundled services requiring additional contracts (warranties, installation, setup)
• Special shipping (freight, premium delivery)
• Gifting requiring split-invoice logistics or hidden pricing
• In-store activation

Policy and safety restrictions

• Age-restricted items requiring ID verification
• Prohibited content - weapons, adult content, healthcare/pharmaceuticals, counterfeits

Digital goods and services

• Services (lessons, online classes, travel packages) unless integrated using specific Travel rails
• Rentals (movies, equipment, leasing)
• Virtual items (in-game currency, MMORPG goods, skins)
• Software dependencies requiring installation before purchase

Check that list against your catalogue. Do you sell used or refurbished goods, pre-orders, buy-now-pay-later products, courses, or virtual items? A material share of your catalogue may be excluded from Google’s agentic checkout. These aren’t obscure exceptions.

The precise wording matters for regulated sellers: the category is titled “Financial products and recurring billing models,” and the two items enumerated beneath it are subscriptions and installments. Financial products as such aren’t separately enumerated, but they fall under the category heading. If you sell a financial product, the safe reading is that it’s in scope, and you should confirm with Google rather than rely on the absence of an explicit bullet.

ChatGPT has its own, separate prohibitions, listed in OpenAI’s Get Started guide: adult content, age-restricted products (alcohol, nicotine, gambling), harmful or dangerous materials, weapons, prescription-only medications, unlicensed financial products, legally restricted goods, illegal activities and deceptive practices. OpenAI states it “may take corrective actions such as removing a product or banning a seller from being surfaced in ChatGPT.”

The two lists overlap on age-restricted and prohibited goods but diverge sharply elsewhere. Google bars used goods and rentals from checkout; OpenAI’s prohibited list doesn’t mention either. Google bars pre-orders; OpenAI’s feed specification explicitly supports a pre_order availability value. These are policy differences, not bugs, and planning for “agentic commerce” as a single ruleset won’t work.

---

The self-serving review problem is narrower than it is usually claimed

You may have heard that banks can’t publish their own reviews and still qualify for star snippets. There’s a real rule behind that claim, but its scope is narrower. That distinction changes what you should do with your reviews.

From Google’s Review Snippet documentation, last updated 8 September 2026:

“If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.”

The exclusion is scoped to LocalBusiness and Organization structured data. The supported ratings list reinforces this: local business ratings are supported “only for sites that capture reviews about other local businesses,” and Organization ratings “only for sites that capture reviews about other organizations.”

The rule doesn’t extend to schema.org/Product. A bank marking up reviews of its own credit card or account as a Product isn’t covered by this clause. A bank marking up its own corporate reputation as an Organization is.

Two related rules apply regardless of type: “Don’t aggregate reviews or ratings from other websites,” and ratings “must be sourced directly from users.”

There’s an agentic analogue that is squarely on point, and it’s in OpenAI’s feed specification rather than Google’s. For ChatGPT discovery feeds:

review_count - “Exclude seller and store reviews.”

Seller and store reputation must go in the separate store_review_count / store_star_rating fields, which are a distinct scope requiring separate setup and must not be combined with product reviews. A regulated seller that blends its own customer-service scores into a product rating is therefore breaking a stated rule of the contract, and the specification is explicit that “the count and rating must describe the same review population.”

---

The Agent-Readable Product Data Readiness framework

The core observation underneath it: schema validity isn’t agent-readiness. In the ACP repository’s feed schema, a Product requires only id and variants, and a Variant requires only id and title. You can produce a perfectly schema-valid feed that an agent can’t price, can’t trust and can’t transact with. Google’s Merchant Center requirements go further in the opposite direction: a listing can be fully eligible for free listings and still be invisible to checkout because one boolean is absent.

So readiness has five tiers. A catalogue is agent-ready at a tier only when everything below it’s complete.

Tier 0 - Identity and stability

Can the agent hold a stable reference to this exact thing?

• A stable product ID and stable variant IDs that survive price, stock, title and image changes
• A variant model: parent listing ID, per-variant rows, user-facing option dimensions
• Machine identifiers (GTIN / MPN) where they exist, with valid check digits
• Canonical, publicly reachable URLs - variant-selected where possible
• A seller identity that’s a real name, not a placeholder

OpenAI’s guidance is blunt about the failure mode: “Never include price in an offer ID,” and item_id, group_id and offer_id should all stay stable “when price, stock, title, or images change.” Mutable identifiers break any linkage you built between the feed and a conversation.

Tier 0 failure looks like: an agent recommending a product, then being unable to deep-link to the variant the shopper chose.

Tier 1 - Price and availability truth

• Price in the exact format the surface expects - this is where feeds break (see below)
• Explicit availability on every record; never infer it
• Freshness: a snapshot cadence the surface actually ingests
• A documented way to withdraw a product that isn’t deletion by omission

On that last point, OpenAI’s retention rule is useful and unusual: a product missing from a processed snapshot is retained for up to 14 days. To remove it deliberately you set is_eligible_search=false; the record expires only if you omit it from every subsequent snapshot.

Tier 1 failure looks like: the agent quotes a price that’s days stale, or surfaces an out-of-stock item it believes is available.

Tier 2 - Trust and differentiation

• Product-level review aggregate - count and rating describing the same review population, never summed across variant rows
• Store-level reputation in its own scope, not blended into the product
• Rich media with alt text
• A factual description an agent can quote without misstating the product
• Category assignment against a recognised taxonomy

Note what is not in the ACP repository’s feed schema at all: there’s no reviews or ratings field. Review aggregates exist only in OpenAI’s merchant-facing flattened feed, as review_count and star_rating. If you’re integrating against the protocol repository’s schema rather than OpenAI’s ingestion contract, you have no place to put social proof.

Tier 2 failure looks like: an agent that can price the product but can’t tell the shopper why it’s trustworthy.

Tier 3 - Transaction attributes

The attributes that turn a recommendation into a purchasable offer:

• Shipping - an actual charge, expressed per the surface’s supported representation
• Returns - acceptance, window, and policy link as three separate facts
• Compliance notices - surfaced as structured data, not prose
• Legal links - terms and privacy as first-class fields

Google’s UCP requirements here are the strictest and the most concrete. Return policies are a mandatory Merchant of Record configuration, must include return cost, return speed (window) and a link to the full policy, and are “referenced on the checkout screen.” Customer support contact information is mandatory and generates a “Contact Merchant” link on the order confirmation. Consumer notices use a dedicated consumer_notice attribute group with notice_type of legal_disclaimer, safety_warning or prop_65, and a notice_message capped at 1,000 characters that may contain <b>, <br>, <i> and <a href>. Those warnings are “displayed prominently on the Checkout screen.”

This is what makes an attribute useful to an agent. It has a defined type, a valid value, and clear limits. A machine can put it on the checkout screen without asking someone to read your policy page.

Tier 3 failure looks like: a shopper who is told the item ships free, or can be returned, by an agent quoting a marketing page - and discovers otherwise at checkout.

Tier 4 - Eligibility and governance

• The eligibility flag set correctly for each surface, understanding that absent means ineligible
• A classification of every category against each platform’s ineligible list
• Prohibited-product screening
• Terms and privacy URLs valid and reachable
• A named owner for policy fields, because they change and nobody notices

Tier 4 failure looks like: a feed that ingests perfectly and generates no transactions, because half the catalogue was never eligible.

Scoring it

Any Tier 0 or Tier 1 gap caps the catalogue at not transactable, regardless of everything else - a perfectly-reviewed, perfectly-compliant product with a stale price is a support incident. Any Tier 4 exclusion removes that product from the surface entirely, regardless of the other tiers. Tier 2 and Tier 3 gaps degrade the experience without breaking it.

Practically: fix Tier 0 and Tier 1 for the whole catalogue first. They’re mechanical and engineering-owned. Tier 3 is the expensive tier, because it needs operations and legal sign-off rather than code. Teams that treat it as a developer ticket tend to stall on it.

---

Field-level traps: where real feeds actually fail

Read the two feed specs side by side before you map fields between them. Some definitions conflict. Treat them as interchangeable and you can corrupt data without noticing.

Price has two incompatible formats. OpenAI’s ingestion contract specifies money as a decimal amount in major units, a space, and an uppercase ISO 4217 code - "79.99 USD". It’s emphatic: “79.99 USD means 79 dollars and 99 cents, not 7,999 dollars.” The ACP repository’s JSON Schema specifies an integer in minor units with a separate currency field - "amount": 1999, "currency": "USD". Same protocol, same conceptual field, two representations. They aren’t interchangeable: submitting a minor-unit integer where an amount CURRENCY string is expected is a parsing failure, not a rounding difference, and the two error directions differ by two orders of magnitude.

The pre-order spelling changes. OpenAI’s own format uses pre_order. The Google-compatible path uses preorder - the documentation says explicitly: “Use preorder, not the OpenAI spelling pre_order; unknown is not accepted.”

The availability vocabularies aren’t the same set. OpenAI format: in_stock, out_of_stock, pre_order, backorder, unknown, where omitted, empty or unrecognised values reject the row. Google-compatible: in_stock, out_of_stock, preorder, backorder. The ACP repository schema offers a different list again: in_stock, limited_stock, backorder, preorder, out_of_stock, discontinued.

Format detection is per-upload, not per-row. This one will bite anyone with multiple feed files:

“One format applies to the entire upload, not to individual rows.”

“OpenAI checks the OpenAI format first, then this compatibility profile, using samples from each nonempty file. A match requires an accepted sample from every file that supplies records.”

Filename extensions don’t decide it. If you upload a merchant-designed .csv and an internal .txt, detection has to succeed across both or the upload isn’t accepted as intended.

The Google-compatible path silently disables per-item control. Accepted Google-compatible products “have search enabled and checkout disabled,” and is_eligible_search=false “does not opt a product out on this path.” To use per-item search controls you need a feed confirmed to follow the OpenAI format.

The zero-price exception is narrower than it sounds. A zero-price product is accepted only if google_product_category identifies a mobile device - category ID 267 (mobile phones) or 4745 (tablets) - and a valid subscription_cost is supplied. Category paths don’t qualify. “Other zero-price products are rejected.” So even inside ChatGPT’s subscription support, the exception is a phone-billing case, not a general recurring-revenue channel.

Several useful fields require setup you may not have. In OpenAI’s specification these need an integration configured to carry them: the shipping tuple, marketplace_seller, size_system, store_review_count, store_star_rating, accepts_exchanges and is_digital. Adding the column doesn’t enable the field; the documentation states this explicitly.

Policy links don’t set policy. For returns: “A policy URL does not set or override this field.” For is_eligible_checkout: an absent or invalid seller_privacy_policy “does not establish checkout readiness.” And “Setting an eligibility flag does not complete checkout onboarding.”

Minor inconsistencies exist in the specification itself. The ACP repository’s checkout RFC has a conformance checklist requiring API-Version: 2026-01-15 while its normative text specifies 2026-01-16. The feed schema’s seller link types include terms_of_service and refund_policy; the checkout RFC’s link types are terms_of_use, privacy_policy and return_policy. These are small, but they’re the kind of detail that decides whether an integration passes conformance testing on the first run. Treat the repository as beta, which it explicitly is.

---

Shipping, returns and tax: three surfaces, three different answers

This comparison is the clearest illustration of why “agentic commerce” isn’t yet one thing.

Shipping. The ACP repository’s feed schema contains no shipping cost field at all. A seller object can carry a shipping_policy link, and that’s where it stops. OpenAI’s flattened feed adds two optional representations: shipping_price as a money string, or shipping as a strict tuple of exactly country:region:service_class:price - for example US::Standard:5.00 USD - which requires feed-specific setup, can’t be combined with shipping_price for the same charge, and is “not a list of regional overrides.” The doc is careful about what this isn’t: “A shipping amount describes a charge; it does not quote a checkout total or guarantee a delivery date,” and an omitted value means unknown, not free.

Returns. OpenAI’s feed splits returns into three fields - accepts_returns (boolean), return_deadline_in_days (integer, only meaningful when accepts_returns=true) and return_policy (URL). The specification insists you keep them separate because “A return window is a duration, not a deadline date.” Google’s UCP approach is account-level and mandatory: return policies configured in Merchant Center, with return_policy_label to scope a policy to a subset of products and a returns feed attribute for product-level policy. UCP treats returns as a Merchant of Record compliance obligation; ACP treats them as merchant-supplied attributes.

Tax. Neither feed carries tax, and that’s correct - tax depends on the destination, which is unknown at feed time. Both compute it at session creation: OpenAI’s key-concepts guide has the merchant determine fulfilment options and “calculate and charge sales tax” on their own stack; UCP’s native checkout API has the merchant return “totals, taxes (initially estimated)” and recalculate whenever the address changes. UCP additionally handles tax-inclusive markets with explicit rules: the subtotal must include tax, a separate tax line item must be omitted, and display_text must be supplied. Multi-tier disclosure (Canadian GST/PST/QST) uses a nested lines array where “the sum of all sub-line amounts must equal the parent tax entry’s amount.”

The practical consequence: an agent can know your shipping charge and your return window from your feed, but it can’t know the landed cost until a session exists. Any merchandising or pricing that assumes an agent can quote a final total from catalogue data alone is building on a false premise.

---

What the platforms say about ranking

The usual question here is whether agentic participation helps or hurts organic visibility. On this specific point the two platforms give opposite, explicit answers.

Google: no effect. From the UCP FAQ, asked directly:

“Will Native integration affect my product ranking? No. Opting for our Native integration does not influence how we rank your offers in product listings. The user experience for listings remains consistent; however, offers integrated with UCP will feature the direct purchase option.”

OpenAI: checkout enablement is a ranking input. From the original Instant Checkout announcement, when ranking multiple merchants selling the same product, ChatGPT considers availability, price, quality, primary-seller status, and “whether Instant Checkout is enabled.”

These aren’t reconcilable, and merchants shouldn’t assume symmetry. A UCP integration is a presentation and transaction upgrade. An ACP integration includes a disclosed commercial signal. Neither statement is a promise about volume, and neither platform offers one - Google’s page reports on UCP BigQuery analytics and Microsoft’s Copilot Checkout announcement reports vendor-internal observational figures with explicit caveats that they “may not generalize across all groups and conditions.”

---

Copilot Checkout: the most accessible door in the market

Microsoft’s announcement describes Copilot Checkout as “beginning to roll out in the U.S. on Copilot.com,” with partner activation across PayPal, Shopify and Stripe. The onboarding asymmetry is the notable part:

“If you’re on Shopify, you’ll automatically be able to sell in Copilot Checkout. No application. No integration. Shopify merchants will be automatically enrolled following an opt-out window.”

Non-Shopify merchants apply. Launch merchants included Urban Outfitters, Anthropologie, Ashley Furniture and Etsy sellers, with expansion planned across Bing, MSN and Edge. Microsoft Merchant Center isn’t required, though its feeds “help inform organic Copilot results.”

The strategically important line: “Microsoft is adopting open standards like the Agentic Commerce Protocol (ACP) to ensure merchant onboarding is seamless and scalable.” Microsoft is standardising on ACP, not UCP. Microsoft is also working with Mastercard and Visa on Mastercard Agent Pay and Visa Intelligent Commerce.

PayPal’s release confirms it’s powering inventory surfacing, branded checkout, guest checkout and card payments from 8 January 2026, starting with Copilot.com, using PayPal’s store sync.

Microsoft’s headline figures - journeys including Copilot “led to 53% more purchases within 30 minutes of interaction”, and 194% more likely to result in a purchase when shopping intent is present - are footnoted to “Microsoft Internal Data, August 2025.” PayPal’s version adds that the insights “are observational” and “may not generalize.” Treat them as directional vendor data, not benchmarks.

---

What to do now, in order

Given everything above, the sequencing matters more than the choice of protocol.

1. Don’t start with protocol selection. For most merchants the binding constraint isn’t which protocol to speak - it’s whether the surface will accept you. UCP is US-only early access behind a waitlist. ChatGPT’s feed onboarding is approved-partners-only. Copilot Checkout auto-enrols Shopify merchants and takes applications from everyone else. Find out which door you can actually walk through before engineering anything.

2. Classify your catalogue against the ineligible lists before anything else. Used, refurbished, final-sale, pre-order, subscriptions, installments, services, rentals, virtual goods, anything requiring installation. This is a merchandising and finance conversation, not an engineering one, and it may reshape the business case.

3. Make Tier 0 and Tier 1 clean across the whole catalogue. Stable IDs, correct price format for the specific surface, explicit availability, daily snapshots. Get these basics right before moving on.

4. Only then build Tier 3. Shipping charges and return windows as structured fields, compliance notices as typed attributes. This is where your legal and operations teams get involved, and it’s where most of the value lives once transactions work.

5. Instrument before you launch. OpenAI explicitly supports feed attribution parameters on your URL for click tracking, UCP exposes BigQuery analytics, and Google’s UCP requests are identifiable at the network layer by a UCP-Agent:Profile header combined with a User-Agent beginning Google/UCP. Without that, agentic revenue is indistinguishable from unattributed direct traffic.

6. Re-read the docs at implementation time, not procurement time. Every major document in this space changed within the last six months, and Google’s own documentation contradicts itself - the FAQ still calls multi-item carts “upcoming” while the Native checkout overview says multi-item checkout is supported. Pin spec versions, re-read at build time, and treat the ACP repository as beta because it says it is. Where a conformance suite exists, as it does for UCP, run it against your endpoints before you point anything at production.

---

What still doesn’t work

Limits of the current state:

• Neither agentic transaction layer is generally available to merchants. Both major programmes are gated, each in a different layer.
• Geography is US-only across all three surfaces as documented.
• Post-purchase is uneven. ACP’s 2026-04-17 specification added rich order tracking, fulfilments and adjustments, and Google’s UCP roadmap lists post-purchase support as upcoming. Both are recent; neither is broadly deployed.

The UCP GitHub repository is at github.com/Universal-Commerce-Protocol/ucp.

---

Sources and References

OpenAI

• Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol
• Powering Product Discovery in ChatGPT
• Agentic Commerce - Get Started
• Agentic Commerce - Key concepts
• Agentic Commerce - Best practices
• Agentic Commerce - full documentation export
• Agentic Commerce documentation index

Agentic Commerce Protocol

• ACP specification repository
• Feed JSON Schema, version 2026-04-17
• Agentic Checkout RFC
• Changelog 2026-04-17
• agenticcommerce.dev

Universal Commerce Protocol

• UCP specification repository (Apache 2.0)
• UCP conformance test suite
• ucp.dev - protocol documentation

Google

• Universal Commerce Protocol guide
• Prepare your Merchant Center account (last updated 2026-10-02)
• UCP integration hub in Merchant Center (last updated 2026-10-02)
• Native checkout overview, SLOs and status lifecycle (last updated 2026-10-16)
• Native checkout REST API, version 2026-04-08
• UCP Frequently Asked Questions
• Google Pay / UCP overview (last updated 2026-09-30)
• New tech and tools for retailers in an agentic shopping era (11 Jan 2026)
• Introducing the Universal Cart (19 May 2026)
• An intelligent new shopping cart (15 Oct 2026)
• Universal Commerce Protocol updates
• Introduction to Product structured data (last updated 2025-12-10)
• Review Snippet structured data (last updated 2026-09-08)

Microsoft and PayPal

• Conversations that Convert: Copilot Checkout and Brand Agents
• PayPal Powers Microsoft’s Launch of Copilot Checkout (8 Jan 2026)

Standards and press

• schema.org/Product
• CNBC: OpenAI revamps shopping experience after struggling with Instant Checkout (24 Mar 2026)