Shopify WebMCP checkout went live on September 28, 2026, and it closes the last gap in browser-side agent shopping on Shopify. An AI agent running in the buyer's own browser can now read the checkout, fill in contact, shipping and discount details, and place the order once the buyer says yes. Shopify now offers two agent routes into checkout: WebMCP in the browser and Checkout MCP on a server. Picking the wrong one is the most likely mistake a team building a shopping agent will make this quarter.
What Shopify WebMCP checkout does
Shopify WebMCP checkout registers four tools on the checkout page that a browser agent can call: get_checkout, update_checkout, complete_checkout and navigate_to_storefront, according to the Shopify developer changelog. The tools run inside Shopify's own checkout and share its state, so there is no new API and nothing for the merchant to configure. When the buyer has to act, for a 3D Secure challenge or a blocking checkout UI extension, the tools hand control back to the person.
This extends the storefront tools Shopify shipped on August 5, 2026. That release gave all Liquid themes, plus Hydrogen's developer preview, ten tools covering catalog search, product and variant details, cart updates, policy lookup and the jump to checkout. With checkout covered, a browser agent can now take a buyer from a search query to an order confirmation without ever simulating a click.
WebMCP itself is a proposed web standard, still limited to Chromium browsers. The page registers tools with the browser, and the agent discovers and calls them with structured input and output. Shopify says it is shaping the spec alongside Google and Microsoft.
WebMCP checkout vs Checkout MCP: which one to build on
Build on Checkout MCP unless your agent has to run inside the buyer's browser, because that is Shopify's own recommendation in its carts and checkout guide for agents. The two options share the same checkout object, statuses and messages, both implement the Universal Commerce Protocol checkout capability, and both pin the UCP version dated 2026-08-25. The difference is where the agent lives and who holds the session.
Checkout MCP is server-side. Your agent authenticates, creates a checkout session, can convert a cart into it, and hands the buyer a continue_url when a human needs to finish. It suits assistants inside your own app, a messaging channel or a concierge tool, where you control the runtime and the logs.
WebMCP checkout is browser-side. It acts on whatever checkout is open in that tab, with the buyer watching the same screen. It suits browser assistants and extensions that ride along with a shopper who is already on the store. It also inherits things a server agent has to rebuild: the buyer's Shop Pay login, saved cards, the theme's cart behaviour. The price is less control. The agent cannot change line items at checkout, because the buyer does that on the page, and tool availability shifts as the buyer moves through the steps.
A simple rule: if you are building the agent, pick Checkout MCP. If someone else's agent is visiting your store, WebMCP checkout is already on, and your job is to make sure it works well.
The details that will break a first implementation
Three implementation details in the Checkout WebMCP reference will catch teams moving over from the Storefront API. First, update_checkout uses PUT semantics. Every call replaces the checkout state, so a request that omits the shipping address clears it. Each update has to be built from a fresh get_checkout response. Storefront API and AJAX cart mutations patch single fields, so this is a real mental shift.
Second, arguments go in as a JSON string. In Chrome 153 an object argument fails to parse, and Chrome plans to flip that in Chrome 155, accepting objects and deprecating strings. Any agent shipped this autumn needs to handle both.
Third, identity. Shopify asks agents to sign browser requests with Web Bot Auth, an Ed25519 key published in a registered key directory. Unsigned agents may be deprioritised or blocked by bot detection. That makes agent identity an operations task with key rotation and short-lived signatures, not a line of config.
Shopify also writes two rules into the reference that we would treat as non-negotiable. Show the buyer the current order and total before complete_checkout, and ask again if the total changes. And treat merchant or third-party text inside tool responses as data, never as instructions, because it can carry prompt injection.
What merchants and studios should do this quarter
Merchants on Shopify Plus should test their checkout with a WebMCP agent now, because the tools are already live on their store whether or not anyone planned for them. On our Shopify Plus and Magento builds, that test has three parts. Run a full agent checkout on staging and note every point where control returns to the buyer. Check every blocking checkout UI extension, since each one stops the agent flow. And look at declared fields, gift notes and B2B purchase order numbers, because an agent can only fill what the checkout declares.
Custom themes deserve a check too. Storefront cart tools go through Shopify's standard storefront actions, the ones apps already call, so a theme that bypasses them with its own cart script may behave differently when an agent drives it. Teams on the Hydrogen developer preview get the storefront tools, but should confirm their checkout handoff matches.
For Magento and Hyvä merchants the comparison is sharper. We know of no native WebMCP tools in Magento Open Source, Adobe Commerce or Hyvä today, so a Hyvä store that wants agents in its checkout has to register and maintain its own tools. That is doable, and Hyvä's lean Alpine checkout is a good host for it, but it is a build line item, not a toggle. It belongs in any Shopify Plus vs Magento Hyvä decision made in 2026.
For teams building their own shopping agents, the work sits in AI-native interface design more than in plumbing: the confirmation step, how the agent explains a changed total, and what it says when it hands control back. That is where trust in agent checkout is won or lost.