If a customer can discover and purchase a product in another interface, what role does the website retain? The question deserves consideration without jumping to the conclusion that the site should be abandoned.
Google launched Universal Cart in the U.S. on October 15, 2026, with purchasing options on Google or continuation at the merchant. [1]
This changes the journey. It does not mean every store and market already works this way.
Three responsibilities remain
The business needs to explain the offer, maintain accurate commercial information, and fulfill its promises. These responsibilities exist regardless of the interface where an order begins.
The website can provide detailed explanations, comparisons, configuration, support, and direct access to the brand. The catalog and operational systems can supply product and availability data. Where the purchase is completed depends on the implementation.
Keeping important information inside an image or an internal conversation helps neither customers nor distribution partners.
More interfaces need shared rules
Imagine a product removed from stock but still available in one channel. Or a delivery charge that differs from the original information. The issue needs to be traced to the data source and update rules.
We would define who owns pricing, stock, variants, and commercial terms. We would establish how changes propagate and how discrepancies are detected. Without that discipline, a new integration can multiply existing problems.
Preparation does not mean enabling every integration
UCP supports commerce actions within Google experiences, but access and validation are conditional. [2]
For a particular business, we would check the market, platform, eligibility, costs, support capacity, and potential volume. A technical project may be premature if basic data is unreliable or the feature is unavailable in the target market.
We would first favor improvements that also benefit the current journey: accurate data, clear pages, working checkout, and a sound post-purchase process.
How we would decide what is worthwhile
At NOT MORE., we would map discovery through returns and identify the systems and people responsible. We would check whether a new integration removes a real obstacle and which dependencies it adds.
A pilot would have a defined product scope, functional acceptance criteria, a rollback path, and tracked costs. We would compare completed orders, errors, cancellations, and support requests, not just use of the new feature.
Purchasing can happen in several places. Responsibility for the offer and experience stays with the business.
Want to know what is worth preparing now?
We can start with the current journey and what your systems can actually support.