See all services → Shopify Plus Partner
Platform Developer

Prepare checkout for browser agents using WebMCP tools

Shopify checkout now registers WebMCP tools in the buyer's browser, letting an AI agent read checkout state, update fields, and submit the order after the buyer confirms. There is nothing to enable, so the behaviour is already live on your store.

Executive summary

What changed

Checkout now publishes four tools that an agent in the buyer's browser can discover and call. The agent can navigate to the storefront, read checkout state along with any messages and post-completion order details, update the checkout fields Shopify permits, and complete the checkout after the buyer has confirmed. The tools run inside checkout-web and operate on the same state as the checkout UI, so an agent is not driving a parallel session or a separate API surface.

Two details are worth holding onto. First, there is no new API and no merchant configuration, which means this is already active rather than something you schedule. Second, the tools deliberately hand control back to the buyer whenever human input is required, including 3D Secure authentication and blocking UI extensions. An agent cannot authenticate a card challenge on the buyer's behalf, and it cannot dismiss an extension that demands interaction.

Why it matters

The practical consequence of a zero-configuration rollout is that you inherit the behaviour whether or not agentic commerce is on your roadmap this quarter. Checkout customisations that were built on the assumption of a human reading the page are now being traversed by software that reads the page differently. Any extension that interrupts progress becomes a stall point in an agent run rather than a small friction cost, and the order simply does not complete.

This is also the first change that makes agent traffic measurable in a useful way, because completed orders now carry a path you can reason about. Teams that have already invested in checkout extensibility are in the better position here: extension-based logic is inspectable and adjustable, where older interruptive patterns are not.

Role-specific impact

Use-case example

Real-world scenario

A Plus merchant selling replenishable consumables was already seeing roughly 6 percent of storefront sessions originating from assistant referrers, with those sessions converting at less than half the site average. The drop was concentrated at a single step: a post-address checkout extension asking buyers to pick a delivery window, which required a click before the buyer could continue. Rebuilding that block to default to the next available window and treat the picker as optional removed the interruption. The agent-assisted cohort closed most of the conversion gap within three weeks, and the change cost about a day of extension work.

Implementation checklist

  1. Inventory every checkout UI extension and mark which ones block progress until the buyer acts.
  2. Convert blocking prompts to sensible defaults wherever the business rule allows it, and keep the interaction optional.
  3. Test a full checkout with an agent in the browser, covering the 3D Secure and Shop Pay hand-back paths.
  4. Confirm your analytics can segment assistant-referred sessions, even if only by referrer, so the cohort is visible.
  5. Review fraud and order-review rules for false positives on agent-assisted orders.
  6. Document the expected behaviour so support staff can recognise these orders when a buyer calls.

FAQ

Q: Do we need to enable anything or target an API version?

A: No. The tools run inside checkout-web with no merchant configuration and no version to pin, so the behaviour is live on every store already.

Q: Can an agent place an order without the buyer knowing?

A: No. The buyer confirms before the completion call, and any step needing authentication, such as a card challenge, returns control to the buyer.

Resources

Checkout WebMCP documentation

Need guidance? Talk to Makro.