Shopify Just Gave the Storefront a Second Front Door for AI Agents

Shopify shipped two things four days apart that point in opposite directions.

On September 24 the story was that direct checkout inside Google AI Mode and Gemini is on by default for eligible stores, which moves the purchase onto somebody else's surface. On September 28 the company extended WebMCP into Shopify checkout, which lets an agent operate the merchant's own storefront.

One makes the merchant transactable somewhere else. The other makes the merchant's own storefront operable by software.

What shipped

The changelog is short. Browser agents can read and update Shopify checkouts using WebMCP tools, which act on the active checkout in the buyer's browser session. Four calls: navigate_to_storefront, get_checkout, update_checkout, and complete_checkout, which submits the order after buyer confirmation. When the buyer's input is required, for 3D Secure authentication or a blocking UI extension, the tools hand control back to the buyer.

Two sentences in that changelog matter more than the tool list. The tools "run inside checkout-web and use the same state as the checkout UI." And they "don't expose a new API or require merchant configuration."

This is an extension rather than a beginning. On August 5 Shopify made WebMCP tools live "on every Liquid storefront and on the Hydrogen developer preview," with "nothing to install or configure," covering catalog search, product and variant display, cart updates, store policies and proceed_to_checkout. What September 28 adds is the end of the journey: discovery and cart become discovery, cart, checkout and order confirmation.

I should flag a gap in my own work here. When I published AI Commerce 2027 on September 21, I described WebMCP as a draft standard with an early Chrome implementation behind a flag. Shopify had already shipped it across Liquid storefronts six weeks earlier, and I missed it.

Two interfaces, one commerce state

The architecture is the story, and the August changelog describes it more vividly than the September one. Everything an agent does "happens on the shopper's live session," and the cart tools call the same storefront actions that apps use, so if a theme opens a cart drawer when the cart updates, the agent's call opens it too.

That is not a parallel storefront for machines. It is one commerce session with two ways in. The shopper sees the drawer slide open. The agent called a function. Same cart, same totals, same validation.

Checkout works the same way. The documentation says the buyer "sees the same checkout state, handles page interactions such as Shop Pay login or payment challenges, and confirms the order" before the agent completes it.

One boundary inside that design is worth noticing. At checkout the agent can replace contact details, fulfillment, discount codes and payment selection, but update_checkout ignores line items, because "the buyer changes items on the page." The agent can arrange the purchase. Changing what is being bought stays with the person. For a Shop Pay buyer, the agent can read the saved cards available and select among them. It never touches credentials.

Worth keeping the acronyms straight, briefly. Checkout WebMCP implements the UCP checkout capability over browser-registered tools instead of a server-side call. WebMCP is where the tools live, UCP is what the transaction is. The same docs tell you to use Checkout MCP instead if your agent runs on a server.

The buyer still has to say yes

Shopify is unusually direct about this, and the wording deserves quoting because it settles a question the industry keeps fudging.

"Before you call complete_checkout, show the buyer the current order and total, and get their permission to place it. WBA and ready_for_complete don't grant it. If the total changes, then ask again."

WBA is Web Bot Auth, the signature Shopify uses to identify a registered agent. Shopify is saying that proving which agent you are is not the same as proving the human agreed. A verified identity and a technically completable checkout are both insufficient. Only status: completed confirms an order.

So this is agent execution with transaction approval, not autonomous spending. The agent prepares and submits. The human authenticates when challenged and authorizes the purchase.

The website is not disappearing. It is gaining a participant.

I have written repeatedly about shopping leaving merchant websites, and this is the useful counterweight.

Both things are now true at once. A purchase can complete inside Google's surface with Shopify underneath and the merchant never rendering a page. Or an agent can arrive at the merchant's storefront and operate it through declared tools while the shopper watches. These are not competing predictions. They are two paths into the same commerce system, and a merchant may end up served by both without building either.

What constrains all of it

Agent support for WebMCP remains limited to Chromium-based browsers, which Shopify's August changelog described as an origin trial. Merchant-side availability and the existence of consumer agents that can use it are different facts.

The exclusions are substantial. Checkout registers no tools for the standard three-page checkout unless the buyer uses Shop Pay, for B2B checkout, for embedded checkout or mobile checkout SDKs, for carts containing merchandise from another shop, or for draft orders, order edits and payment collection. App-defined checkout extension interactions stay with the buyer. There is no cancel equivalent, so an agent cannot cancel a checkout it started, and the status never reads as canceled.

No WebMCP order volume, conversion rate or error rate has been published, by Shopify or anyone else I could find. This is capability evidence, not adoption evidence, and the distinction is the same one I keep applying to everything else in this category.

I also found no documented merchant configuration requirement or opt-out in the materials I reviewed. That is an absence in the documentation, not a finding that none exists.

What it asks of an operator

Three things follow, and none of them is a project.

Agent readiness arrived through the platform rather than through an integration, which means a merchant may already have an agent interface without a decision having been made.

A price, a shipping rule, a discount or an availability answer now has two readers, and the shared-state design is what keeps them honest. That is an argument for fewer bespoke front-end hacks, not more.

And measurement will eventually have to separate human-operated sessions from agent-operated ones, because the same checkout can now be completed either way. A conversion rate built on a session count stops meaning one thing when some of those sessions are software working on a shopper's behalf, and nobody has published what that mix looks like yet.

If your storefront already answers questions for software you have never met, who in your company owns what it says?