TLDR;
Google expanded UCP to support carts, catalogue lookup and customer identity linking. That could make agent-assisted shopping more complete. Retailers should test current product data, basket changes and account permissions across the providers they actually plan to use.
What happened
Google expanded UCP with capabilities for carts, catalogue access and identity linking. These additions address practical shopping flows such as assembling purchases, checking current product information and recognising customer relationships across participating systems, extending the January protocol’s initial scope.
Why it matters
A useful shopping flow needs more than a single product and price. It must preserve basket choices, obtain current product information and recognise customer relationships appropriately. Extending a protocol can enable those functions, but enterprise systems still need to manage state, identity boundaries and failure behaviour reliably.
Cart and identity capabilities increase the number of states that a shopping flow must handle. A customer can add or remove items, return after an interruption or change the account used for the purchase. The assistant and merchant need a shared understanding of the current basket without allowing an old instruction to act on a new state. Identity linking introduces another boundary: recognising a customer should follow the permissions and account rules the business has approved. These are operational design questions even when the protocol provides a supported way to exchange information. The UCP extension is therefore significant because it can support more complete journeys, while also making exception handling more important. Enterprises should evaluate the participating implementations and versions rather than assume that a common protocol makes every combination interchangeable.
How your brand can benefit / be affected
Map the new capabilities to concrete use cases in your current commerce stack. Test catalogue freshness, unavailable variants, cart changes and the permissions required for identity linking.
Check protocol versions and participating implementations before relying on interoperability. Exercise interrupted flows, repeated requests and logout or revocation scenarios. Roll out where the added capability improves a customer task, with operational metrics that reveal errors as well as successful transactions.
Write down the basket state that must be preserved and the conditions that require it to be checked again. Include quantities, variants, promotions and any product that becomes unavailable. Test repeated requests and interrupted sessions to see whether the result remains consistent with the customer's latest choice. Keep the final merchant order as the reference for fulfilment and support. This is an acceptance framework for the intended integration, not a statement that all UCP participants implement identical behaviour. Make failures understandable to the user so a stale cart or missing catalogue response does not appear to be a confirmed purchase.
Review identity linking with the account and privacy owners. Specify which relationship is being established, which customer permission supports it and what should happen after logout, revocation or an account change. Use test accounts to verify those transitions before extending the pilot. Measure completed purchases alongside basket mismatches, account confusion and support effort. If the additional capabilities do not improve a defined task, avoid implementing them simply to complete a protocol checklist. A staged rollout lets the enterprise gain useful functionality while keeping the state and identity risks visible. The strongest result is a more dependable customer journey, not merely a longer list of enabled endpoints.
News date: 19 March 2026. Editorial review: 16 September 2026. Analysis includes subsequent developments where stated.