From Shopping Intent to a Merchant-Owned Cart: What UCP Changes for Commerce

Summary. UCP can carry shopping intent from an AI conversation into a merchant-owned cart. Here is how SuggestAPI Commerce Gateway is designed to support Google and Shopify handoffs.

A shopper asks an assistant for waterproof hiking boots for Iceland in October, under $250. That is not a tidy keyword query. It is a shopping job with weather, use, budget, timing, and fit built into it. The real test comes after the assistant finds a good option: can that intent make it all the way to a cart without forcing the shopper to begin again?

That is the promise behind the Universal Commerce Protocol, or UCP. It gives commerce systems and agents a common way to exchange the information needed to move from discovery toward purchase. Google is using UCP to support shopping actions on AI Mode and Gemini, while Shopify has implemented UCP cart and checkout capabilities for agents. [1] [4]

For merchants, the important point is simpler than the protocol name suggests. A new agent surface should not require a new storefront, a second catalog, or a replacement checkout. The goal is to let the shopper arrive on the merchant’s site with the right products already selected, then let the merchant keep control of the cart, checkout, payment, customer relationship, and post-purchase experience.

That is the role SuggestAPI is building toward with Commerce Gateway: hold the shopping job through discovery, resolve the exact product and variant, and hand the shopper into the commerce stack they already use. What is live today is narrower. SuggestAPI is the Knowledge / Agent Gateway for discovery and a merchant-owned handoff. It does not create carts or run checkout. The current UCP scope is spelled out here.

UCP cart transfer is not checkout, and that is a good thing

Google’s UCP Cart API is designed for a focused job. When a shopper elects to transfer a cart from a Google surface, Google sends the merchant’s implementation a CreateCart request with line items. The merchant validates the request, creates a cart in its own system, and returns a continue_url that takes the shopper back to a pre-populated cart or checkout on the merchant’s site. The Cart API does not process payment or attempt to own the whole purchase lifecycle. [2]

That boundary matters. It keeps the merchant as merchant of record and leaves the final buying experience where it belongs, on the merchant’s storefront. It also gives merchants room for the things that make a real checkout work: availability checks, tax and shipping calculations, loyalty rules, promotions, financing, and the occasional product substitution.

To support Google’s cart-transfer flow, a merchant publishes a UCP profile at /.well-known/ucp, advertises the dev.ucp.shopping.cart capability, and provides the endpoint that will receive the cart request. Google is rolling out its Merchant Center onboarding and sandbox access in phases, so technical readiness should be paired with the program’s current participation process. [3]

The tricky work begins after an agent finds the product

Finding a product title is one thing. Turning it into the correct purchasable item is another.

An agent may know that a shopper wants a specific jacket. The merchant’s commerce platform, however, needs the exact variant: size medium, a particular color, the current sellable SKU, quantity, and valid market context. An item may be out of stock. Pricing may change by country. The product Google identifies may not match the merchant platform’s internal variant ID.

SuggestAPI already exists to carry shopping intent through search, comparison, recommendation, and handoff without replacing the search engine or catalog a merchant has chosen. [6] Commerce Gateway is the design for extending that same idea into the cart handoff. It would sit between an agent-facing discovery experience and the merchant’s existing commerce provider.

The Gateway’s job is to translate, not take over. It would resolve product identity, check the selected variant, send a normalized cart request to the right provider, and return the merchant-owned destination for the shopper. The merchant platform remains the source of truth for the actual cart.

One commerce model, separate protocol adapters

It would be tempting to wire a Google cart request directly into Shopify. That would work for one narrow route, but it would turn two different protocol implementations into one fragile dependency.

Google’s current Cart API uses a REST-style CreateCart flow and supports a one-way handoff into the merchant’s cart. [2] Shopify’s UCP implementation uses JSON-RPC through Cart MCP and supports a longer shopping session, including cart creation, retrieval, replacement, and cancellation. [5] Same shopper outcome. Different operating models.

Commerce Gateway is designed around a common internal cart intent. Protocol adapters would meet at the edges. Provider adapters would speak the native language of the commerce stack underneath.

This separation is less glamorous than a one-off integration, but it is the useful part. The same product and variant resolution could support Google UCP, Shopify’s UCP interfaces, a merchant’s own agent, or another agent protocol later. No one needs to rebuild the commerce logic for every new assistant.

Three handoff paths merchants should understand

Google to a non-Shopify merchant

For a merchant on BigCommerce, WooCommerce, Magento, or a custom platform, the design has SuggestAPI operate the UCP cart capability as part of the merchant’s integration. Google would call the merchant’s advertised UCP endpoint. Commerce Gateway would verify and map the requested products, create the cart through the provider adapter, and return the merchant-domain continue_url.

The shopper would land on the store with the cart ready for review. Checkout, payment, and all customer-facing terms stay with the merchant. That path is not live. SuggestAPI does not advertise dev.ucp.shopping.cart or expose CreateCart today.

Direct agent to Shopify

Shopify merchants have a native UCP option. Shopify’s Cart MCP is intended for the exploratory part of shopping: building a cart, changing quantities, checking estimated totals, and sharing a cart link before a buyer commits. Its create_cart response includes a continue_url for the merchant storefront. [4] [5]

For this route, SuggestAPI’s place is upstream of the cart. It holds the shopping job and helps the agent identify the right Shopify variant. A later Commerce Gateway step would use Shopify’s native Cart MCP to create the cart. SuggestAPI should not pretend to be Shopify’s checkout system when Shopify already supplies the storefront handoff, and it does not call Cart MCP today.

This is particularly useful for shopping conversations that take a few turns. A buyer can compare options, switch a color, revise a quantity, and then pick up the cart on the merchant’s site when they are ready.

Shopify cart to Shopify checkout

When the buyer has made a decision and needs final fulfillment or payment details, Shopify separates that state from the longer-lived cart. An agent can convert a cart into a checkout by passing its cart ID to create_checkout, then use the checkout response’s continue_url to direct the buyer to the merchant’s storefront. Shopify documents this conversion as idempotent and carries the cart’s line items, context, buyer information, and associated attribution metadata into the checkout. [4]

That gives merchants a clean line between browsing and buying. The agent can be helpful before the purchase without assuming it should handle the final transaction.

Merchant control needs to be visible in the product design

A handoff is only useful if it remains trustworthy. Commerce Gateway should be explicit about what it can and cannot decide.

The merchant owns price, availability, promotions, shipping options, checkout eligibility, payment, and order confirmation. SuggestAPI can preserve intent and carry structured information forward, but it should not manufacture certainty where the store has not confirmed it. A requested variant that is unavailable needs a clear business outcome, not a silent substitution. A cart that expires needs a useful recovery route. A retry needs an idempotency strategy so a shopper does not get duplicate carts.

The design should also keep protocol errors distinct from ordinary commerce outcomes. Shopify, for example, separates transport or authentication failures from business results such as an unavailable product or an adjusted quantity. [5] That distinction makes a better agent experience because the assistant can explain the difference and offer the next sensible action.

From handoff events to useful measurement

The moment a cart is created is not the same as a completed sale. That gap is why the event model matters.

A Commerce Gateway event chain would record first-party steps: product resolved, cart requested, cart created, cart handoff, checkout created, checkout handoff, and, where the merchant has an approved integration, order completed. For merchants using Convertmax, those events could connect an agent-originated shopping session to a completed order without asking UCP itself to become an analytics product. SuggestAPI does not record that chain today. A discovery event is not a cart-created event, and a cart-created event is not revenue.

The practical question is not simply, “Did an assistant recommend this product?” It is whether the shopper reached a merchant cart, completed checkout, or abandoned the journey after a handoff. That is information a merchant can act on, once the cart step actually exists.

The better path to agentic commerce is to preserve what already works

Merchants have invested years in catalog quality, search relevance, checkout policies, and customer trust. The arrival of AI shopping surfaces does not erase that work. It raises a new integration question: how can an agent keep the shopper’s intent intact and then hand control back at the right moment?

SuggestAPI is built around that handoff. Commerce Gateway is the cart and checkout bridge on the roadmap. It would not ask merchants to replace the stack beneath it. Whether the first request comes from Google, a Shopify-native agent flow, or a merchant’s own assistant, the desired outcome is the same: the shopper gets to the right merchant-owned cart with less repetition and more context preserved.

If your team is preparing for UCP, start with the unglamorous details. Clean product and variant identifiers. Reliable availability data. A clear cart destination. Solid error handling. Then add the protocol adapter that fits the channel. That is how an interesting agent demo turns into a buying path customers can actually use.

References

1. Google for Developers, “Getting started with Universal Commerce Protocol on Google”
2. Google for Developers, “Cart API implementation, Universal Commerce Protocol 2026-04-08”
3. Google Merchant Center Help, “How to onboard to the Universal Commerce Protocol in Merchant Center”
4. Shopify, “Carts and checkout for agents”
5. Shopify, “Cart MCP server”
6. SuggestAPI: Turn shopping intent into products, wherever people start