Google AI Mode and Gemini Store Checkout Requirements

Google now lets some merchants show a checkout ("Buy") button on eligible product listings in AI Mode in Google Search and in Gemini. The shopper buys without leaving Google, pays with Google Pay, and you remain the merchant of record. The feature runs on the Universal Commerce Protocol (UCP), which Google calls "a new open standard for agentic commerce" covering discovery, buying, and post-purchase support. It's compatible with A2A, AP2, and MCP.

The requirements are spread across four teams, and projects stall when nobody knows whose turn it is. This guide turns Google's documentation into a readiness checklist with an owner on every line.

Everything below comes from four Google pages: the Merchant Center Help article About UCP and UCP-powered checkout, the developer guides for preparing your Merchant Center account and the checkout integration, and the native_commerce attribute reference.

Check that you can apply at all

The first gate is geography. Google's Help article applies to products with eligibility in the United States, Canada, and Australia, for participating merchants and partners.

The second is access. Google says the checkout feature is "available for select merchants at this time." You express interest through a form, and the early access program rolls out in phases. The Google pages above give no timeline or approval criteria for it, so don't give your leadership a launch date. Treat the form as a request.

The readiness checklist

#	Item	What Google requires	Owner
1	Merchant Center standing	Account in good standing, with products approved for free listings	Ecommerce
2	Return policy	Return cost, return window, and a link to the full policy	Ecommerce, Legal
3	Customer support	At least one of: website URL, email, phone	Ecommerce
4	Eligibility flag	`native_commerce(checkout_eligibility)` set per product; defaults to FALSE	Ecommerce
5	Product ID mapping	Feed `id` matches your checkout API's ID, or `merchant_item_id` maps it	Dev, Ecommerce
6	Regulatory notices	`consumer_notice` on items with warnings such as California Prop 65	Legal
7	Category screen	Ineligible product types left out	Ecommerce, Legal
8	Google Pay & Wallet Console	Account created	Payments
9	Payment processing	PSP integrated with the Google Pay API, or direct integration with encryption and PCI documentation	Payments, Dev
10	Native checkout API	REST integration built, tested in sandbox, validated in production	Dev

Ecommerce: items 1, 2, 3, 4 and 7

The account has to be in good standing and your products have to be approved for free listings.

The return policy has three required parts: what a return costs the shopper, how long they have, and a link to the full policy. You can set it at account level or through the returns or return_policy_label feed attributes. Advanced accounts configure it per sub-account. Have legal confirm the wording before anyone types it in.

Customer support info needs at least one contact method: a website URL, an email address, or a phone number. Google uses it for the "Contact Merchant" link on the order confirmation, so pick the channel your team actually answers.

Then the flag. native_commerce(checkout_eligibility) is a boolean that defaults to FALSE, which means no product joins by accident. You mark each eligible product yourself. The plain native_commerce attribute is still supported as an alias. Google recommends delivering these attributes through a supplemental feed rather than editing your main product feed.

Legal: items 2, 6 and 7

The consumer_notice group is mandatory for items that carry regulatory warnings, with California Prop 65 as Google's example. It has a notice_type (one of legal_disclaimer, safety_warning, or prop_65) and a notice_message of up to 1,000 characters. Ecommerce uploads it. Legal writes it.

Legal should also sign off on the category screen. Google excludes these product types from this checkout:

Subscriptions and installment purchases
Personalized goods
Refurbished, used, or final-sale items
Pre-orders
Products bundled with services, such as warranties or installation
Items that need special shipping, like freight
Gifting, and items that need in-store activation
Age-restricted goods such as alcohol and tobacco
Prohibited content: weapons, adult, healthcare and pharma, counterfeits
Services like lessons, classes, or travel packages (unless sold on travel rails), plus rentals, virtual items, and software-dependent goods

Leave the flag FALSE on anything in those groups.

Payments: items 8 and 9

You don't need a Google Pay button on your own site. You do need a Google Pay & Wallet Console account. Shoppers pay with Google Pay, using payment methods and shipping details saved in Google Wallet. For now that means standard funding PANs (FPANs) stored in Wallet.

If your payment service provider (PSP) isn't already integrated with the Google Pay API, the PSP has to onboard. If you integrate directly without a PSP, you set up encryption yourself and upload PCI compliance documentation. That path belongs to whoever owns PCI scope in your company.

Dev: items 5, 9 and 10

The integration is Google's Native checkout: a REST API that lets Google manage the checkout flow with your servers. Google renders the buyer UI for now, "with future plans to support more agentic experiences."

Authentication to your checkout endpoint is optional. Google supports an API key sent in an X-API-Key header, or OAuth 2.0, which it recommends. You test in a sandbox first, then validate capabilities in production in Merchant Center.

For item 5, the id in your feed must match the ID your checkout API expects. If the two systems use different IDs, map them with merchant_item_id, which takes precedence over id.

Questions to settle before you fill in the form

Is our PSP integrated with the Google Pay API? If not, what does its onboarding involve?
Do our feed IDs match our order system's IDs, or do we need merchant_item_id?
Who signs off on consumer_notice text?
Will the checkout endpoint use OAuth 2.0 or an API key?

Three checkouts that sound alike

The existing checkout button sends the shopper to your site, and the transaction happens there. UCP checkout keeps the transaction on Google's surfaces, AI Mode and Gemini, while you stay merchant of record. Google's separate agentic checkout feature buys on the customer's behalf on your own website, at the customer's direction. UCP is the layer that standardizes how an agent and your backend exchange that information, whether by API, MCP, or A2A.

When you scope the project, write down which of the three it is.

What the checklist doesn't buy you

Every item above makes a product purchasable from an AI answer. None of it makes Google, or any other assistant, recommend that product. Getting picked is a separate problem.

That's the job we'd give Promptwatch. It tracks your prompts in Google AI Overviews and AI Mode alongside ChatGPT, Gemini, Perplexity, and other engines, so you can see whether your brand shows up in answers to the shopping questions you care about. Citation analytics show which pages those answers rely on. Agent Analytics crawler logs show whether AI crawlers, GoogleOther included, are fetching your product and policy pages. Visitor analytics with conversion tracking measure shoppers who click through to your site, which is the existing checkout path. On the ChatGPT side, its ChatGPT Shopping tracking covers product recommendations.

Know the scope before you buy. Promptwatch doesn't report on AI Mode product cards, Gemini shopping listings, or UCP checkouts. UCP orders run through your own checkout API, and because they complete on Google, they won't appear as site visits either.

Essential costs $95/mo for 50 prompts. Crawler logs start on Professional at $245/mo, the plan we'd pick if you want the crawl check next to answer tracking. ChatGPT Shopping tracking is on Business at $579/mo. For background on the ChatGPT side, see how ChatGPT shopping product answers get assembled. Plans and trial are at promptwatch.com.