Google AI Mode and Gemini Store Checkout Requirements
How we prepare an ecommerce client for Google's UCP checkout in AI Mode and Gemini: the Merchant Center audit, feed flags, the PSP call, legal notices, and what we measure afterwards.
When an ecommerce client asks about checkout in AI Mode and Gemini, the first conversation is about expectations, not code. Google's UCP-powered checkout lets participating merchants show a checkout ("Buy") button on eligible listings in AI Mode in Google Search and in Gemini. The shopper pays with Google Pay and never visits the store. The client stays the merchant of record.
That's useful. It also doesn't make Google recommend anyone's products, and we say so in the first meeting, before anyone budgets for it.
Below is how we prepare a client, in the order we do the work. Every requirement comes from Google's documentation: the Merchant Center Help article on UCP and UCP-powered checkout, the developer guide to preparing your Merchant Center account, the checkout integration guide, and the native_commerce attribute reference.
We start with two gate questions
Does the client sell products with eligibility in the United States, Canada, or Australia? Google's Help article applies to those three markets, for participating merchants and partners. A client selling only elsewhere has nothing to apply for yet.
Is the client comfortable with early access? Google describes the checkout as "available for select merchants at this time." Merchants register interest through a form, and the program rolls out in phases. The Google pages we work from give no dates and no approval criteria, so we don't give any either. We usually suggest submitting the form while prep runs, since the prep is worth doing regardless.
The Merchant Center audit
The account has to be in good standing, with products approved for free listings. Disapprovals a client has been ignoring become blockers here.
The return policy needs three things: what a return costs, how long the shopper has, and a link to the full policy. It can live at account level or come through the returns or return_policy_label feed attributes. Clients on advanced accounts configure it per sub-account. The gap we look for first is a return policy that exists on the website but was never entered in Merchant Center with all three parts.
Customer support info needs at least one of a website URL, an email address, or a phone number. Google shows it as the "Contact Merchant" link on the order confirmation, so we enter the channel the support team actually monitors.
The feed work
Checkout eligibility is opt-in per product. The attribute is native_commerce(checkout_eligibility), a boolean that defaults to FALSE. The older plain native_commerce form still works as an alias.
We put the checkout attributes in a supplemental feed, as Google recommends, so the main feed keeps running untouched and the checkout layer is a separate file the client can read. Clients pushing data by API use the Merchant API, where custom attributes go in accounts.productInputs.insert. The Content API is deprecated, so if the client's integration still depends on it, we flag that early.
The feed id has to match the ID the client's checkout API expects. If the store platform and the order system disagree, merchant_item_id maps the two and takes precedence over id. The developer and the ecommerce manager confirm that mapping together.
Going through the catalog
Google excludes a long list of product types from this checkout. We walk the catalog against it with the client:
- subscriptions and installment purchases
- personalized goods
- refurbished, used, or final-sale items
- pre-orders
- products bundled with services such as warranties or installation
- items needing special shipping like freight
- gifting and in-store activation
- age-restricted goods such as alcohol and tobacco
- prohibited content: weapons, adult, healthcare and pharma, counterfeits
- services such as lessons, classes, or travel packages (unless on travel rails)
- rentals, virtual items, and software-dependent goods
The flag stays FALSE on anything excluded. The client makes the borderline calls, not us.
Legal notices go to counsel
Products that carry regulatory warnings, with California Prop 65 as Google's example, must have a consumer_notice. It has a notice_type (legal_disclaimer, safety_warning, or prop_65) and a notice_message of up to 1,000 characters. We format and upload it. We don't write warning text for a client, and we don't decide which products need one.
The payments call
This is the dependency we control least, so we book it early. The client doesn't need a Google Pay button on their own site, but they do need a Google Pay & Wallet Console account. Shoppers pay with payment methods and shipping details saved in Google Wallet, currently standard funding PANs (FPANs).
If the client's payment service provider isn't integrated with the Google Pay API, the PSP has to onboard. A client integrating directly, without a PSP, sets up encryption and uploads PCI compliance documentation. We get the client's payments owner and PSP contact into one conversation early.
Handing over to developers
The build is Google's Native checkout integration, a REST API that lets Google manage the checkout flow with the client's servers. Google renders the buyer UI for now, "with future plans to support more agentic experiences." Authentication to the endpoint is optional; Google supports an API key in the X-API-Key header or OAuth 2.0, and recommends OAuth. The developers test in the sandbox, then validate capabilities in production in Merchant Center.
The checklist we hand the client
| Item | Where it lives | Client owner |
|---|---|---|
| Good standing, free listings approved | Merchant Center | Ecommerce |
| Return cost, window, policy link | Merchant Center or feed | Ecommerce, legal |
| Support URL, email, or phone | Merchant Center | Customer service |
native_commerce(checkout_eligibility) | Supplemental feed | Ecommerce |
merchant_item_id where IDs differ | Supplemental feed | Developer |
consumer_notice text | Supplemental feed | Legal |
| Excluded categories left FALSE | Supplemental feed | Ecommerce |
| Google Pay & Wallet Console account | Payments | |
| PSP onboarding or PCI documents | PSP or Google | Payments |
| Native checkout API, sandbox, production | Client's servers | Developer |
Explaining the three checkouts
The existing checkout button sends a shopper to the client's site to buy. UCP checkout keeps the purchase on Google's surfaces, with the client as merchant of record. Google's separate agentic checkout feature buys on the shopper's behalf on the client's own website, at the shopper's direction. UCP is the open standard underneath, covering the exchange between an agent and the merchant's backend via API, MCP, or A2A.
What we measure around it
A Buy button only matters if the product is in the answer. So alongside the UCP prep, we track the client's buying questions in Promptwatch, the platform we run client programs on. It tracks prompts in Google AI Overviews and AI Mode alongside ChatGPT, Gemini, Perplexity, and other engines. Citation analytics tell us which pages those answers lean on, which is usually where the content work starts. Agent Analytics crawler logs show whether AI crawlers, GoogleOther included, reach the product and policy pages. Visitor analytics with conversion tracking cover shoppers who click through to the store. For clients who sell through ChatGPT too, ChatGPT Shopping tracking covers that side.
We're careful about what that does not show. Promptwatch doesn't track AI Mode product cards, Gemini shopping listings, or UCP checkouts. A UCP order completes on Google and runs through the client's own checkout API, so it never appears as a site visit. We report those orders from the client's order system and keep them off the visibility slide. Our wider ecommerce setup is in the stack we run for ecommerce brands.
What we won't promise
We won't promise acceptance into the early access program, a launch date, or that eligibility lifts AI Mode visibility. We will get the account, the feed, and the paperwork ready so that when Google opens the door, the client isn't the bottleneck. If you want that prep on your retainer, write to hello@1001seomedia.com and bring your Merchant Center account ID and the name of your PSP.