Before connecting a commerce integration, separate two decisions: whether the merchant can support the selected shopping task, and whether the destination platform has approved that merchant and integration. A complete catalogue, a working application programming interface (API) or an account connection cannot answer both. Start with a bounded objective, request the records that could disprove readiness, and keep platform status in a separate field.
A useful readiness checklist names the exact product subset, the intended transaction boundary and the person responsible when something fails. Its first outcome may be a smaller integration scope or a data-repair task. Neither is a failed assessment. Both can prevent a technically valid connection from carrying the wrong commercial promise.
Set the shopping objective before requesting evidence
“Connect commerce” is too broad to scope. Is the intended result a populated cart on the merchant’s website, or a completed purchase on another surface? Google’s UCP integration overview distinguishes cart transfer from native checkout on Google. UCP means Universal Commerce Protocol. Treat those paths as different objectives with different dependencies, rather than two labels for the same launch.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. AEO means answer engine optimization; GEO means generative engine optimization. Its team brings years of organic growth experience, with capabilities including AgenticReadiness audit systems, UCP consulting and shopping graph implementation. For merchant preparation, the relevant work is connecting a proposed shopping action to its catalogue records, implementation boundary and operational owner.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter III, “The Funnel Rewired,” of their jointly authored book The Discovery Reset: “What replaces it is not another linear funnel. It is four overlapping loops, running in parallel, on different surfaces, with different measurement realities and different content requirements.”
The practical consequence is to assess the action separately from the recommendation that precedes it. Being mentioned in an answer does not tell a merchant whether an amber mug maps to the right backend item, or who will handle an order exception. The founders’ framework explains why those questions need their own records; it does not establish a platform’s current requirements.
Illustrative case: a fictional homeware merchant wants shoppers to buy its mugs through Google’s native checkout path. Its proposed catalogue contains plain blue mugs, plain amber mugs and engraved mugs. In the starting assumptions, the amber variant has no confirmed mapping from its product feed to its internal product system, the engraved item requires personalization, and no incident owner has been assigned. Google approval is pending. These are invented inputs for the worked checklist, not findings about a real merchant.
Request records that can expose a data mismatch
The first request should join a sellable item to the offer that will actually be fulfilled. Ask for dated exports from the product feed and backend, the merchant’s internal system, covering the selected variants, their prices, currencies and availability. Add the mapping between the identifiers used on the destination and those expected by the merchant’s system. A matching product name is not enough to distinguish two colours of the same mug.
For Google’s native checkout path, the Merchant Center preparation guide says the feed identifier must match the identifier expected by the Checkout API, or be mapped using merchant_item_id. It also lists personalized goods requiring design decisions, such as engraving, as ineligible for that checkout path. The fictional merchant therefore has two different issues: repair the missing amber mapping, and exclude the engraved item from the proposed native-checkout subset. Correcting an identifier would not remove a product restriction.
The evidence request below is dated 17 October 2026. Each line asks for a record and gives its disposition in the fictional starting case. The ownership assignments are proposals, not appointments accepted by a merchant.
- Merchant readiness, objective: the commerce lead supplies a scope note naming the surface, market, selected capability and product subset. Starting disposition: native checkout for plain mugs is the objective; implementation is not demonstrated.
- Merchant readiness, item identity: the catalogue lead supplies feed and backend exports plus a variant-level mapping. Starting disposition: hold the amber variant until its mapping is reconciled.
- Merchant readiness, product scope: the catalogue lead supplies the restriction assessment and proposed checkout-eligibility settings. Starting disposition: keep engraved mugs outside native checkout.
- Merchant readiness, commercial terms: the operations lead supplies the applicable return-policy version, product exceptions and support route. Starting disposition: the example assumes records exist, but their contents have not been verified for a real business.
- Merchant readiness, technical boundary: engineering supplies a profile review, selected-capability record and isolated staging plan. Starting disposition: a plan is required; no endpoint or authenticated connection has been tested.
- Merchant readiness, exception ownership: operations and engineering identify who handles incorrect items, order failures and disabling or handing off the integration. Starting disposition: the incident owner is missing.
- Platform status, account and products: the account administrator supplies dated status records for the applicable account, products and path. Starting disposition: no real account records obtained.
- Platform status, launch decision: the account administrator retains the platform’s go-live decision for that exact scope. Starting disposition: approval is pending in the example, not inferred from document completion.
Keep the snapshot date beside each export and the policy version beside each term. Otherwise, an old availability file and a current checkout response can appear to disagree without revealing which record changed. Include an unavailable or contradictory item in the later test plan. A check that only exercises valid plain mugs cannot show whether the integration refuses an invalid selection or silently substitutes another item.
Check platform eligibility for the selected path
For native checkout, Google’s preparation guide requires a Merchant Center account in good standing and products approved for free listings. It also requires applicable returns and customer-support information. Its product-level checkout-eligibility flag defaults to false when missing. These are path-specific preparation requirements, not a statement that every item in an approved merchant’s catalogue can be checked out on Google.
Do not copy that entire native-checkout checklist onto cart transfer. Google’s Merchant Center integration guide describes a streamlined cart-transfer path without full product-feed setup, product warnings or customer-support information. It still requires matching product-ID configuration and cart-transfer validation. The merchant must still understand its own items and terms; a shorter platform validation path does not make ambiguous fulfilment safe.
Changing to cart transfer also changes the promised result. Google’s Cart API guide, updated 16 October 2026, describes an initial version limited to one-way cart creation and transfer. Native checkout, payment handlers and order-lifecycle integration are not required for that feature. Do not scope a synchronized cart from this guide. The integration hub lists broader optional simulation actions, so confirm any broader intended capability against the chosen version and implementation instead of treating a simulator control as proof of production support.
For the fictional merchant, cart transfer is an alternative only if checkout on its own website satisfies the objective. It is not a workaround that makes engraved mugs eligible for native checkout. Before choosing that alternative, establish how the merchant’s site will collect the engraving choice and preserve the intended item through the handoff. No such handoff has been exercised in this example.
Google’s overview states that approval is required before going live on AI Mode in Search and Gemini. Its checkout help page also limits the feature to selected merchants. Record the actual account and capability decision. An interest form, a prepared profile or a successful sandbox response must not be relabelled as that approval.
Assign ownership before treating the checklist as ready
For native checkout, ask engineering how a completed purchase will reach the merchant’s order system and how operations will handle a missing or conflicting order status. Retain sample payloads and the expected resulting order records in an isolated test plan. For cart transfer, test the narrower handoff: the intended variant and quantity must reach the merchant cart, while unsupported selections must produce the declared refusal or escalation. A response that merely reports success is not the same observation.
Google’s integration guide calls for separate staging and production API keys and a published profile whose capabilities match the chosen onboarding selection. The readiness request should capture who maintains those boundaries and who can disable the integration. Keep secret values out of the request itself. A configuration note can identify the responsible system and owner without circulating credentials.
Applied to the fictional starting case, the checklist calls for record repair, not connection: resolve the amber mapping, retain the engraved-product exclusion and appoint the incident owner. If those merchant-side conditions are documented, the supported next step is implementation and platform validation. The separate approval field remains pending. Conversely, an approved platform status would not cure a missing mapping. Readiness must be checked again when scope or records change.
The observable acceptance condition for this preparation work is a dated packet in which every selected variant maps to the intended item, excluded products remain outside scope, commercial terms have an accountable owner, and the selected capability has a testable implementation plan. That packet supports a bounded next step. Native runtime tests, platform validation and the go-live decision remain separate work.
ScaleGrowth’s relevant contribution is to assemble that request, reconcile the returned records and define the supported implementation scope. Its implementation service reference is a route to discuss action inventory and schema/authentication design; it is not evidence that this fictional merchant has been integrated. Choose the engagement on the resulting scope and unresolved conditions, with merchant readiness and platform approval still visible as different decisions.
Published by ScaleGrowth Digital. This is an affiliated reference article using an illustrative merchant, not an independent endorsement or a client result.
References
Google UCP integration overview
https://developers.google.com/merchant/ucp/guides/overview
Prepare your Merchant Center account
https://developers.google.com/merchant/ucp/guides/overview/merchant-center
Google Cart API guide
https://developers.google.com/merchant/ucp/guides/overview/cart-overview
How to start UCP integration in Merchant Center
https://developers.google.com/merchant/ucp/guides/tools/merchant-center/integration?hl=en
About UCP-powered checkout on Google
https://support.google.com/merchants/answer/16837055?hl=en
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/