October 8, 2026 · Ahmed · More by Ahmed
Shopify Checkout WebMCP: What Agents Can Actually Do
Shopify's new Checkout WebMCP tools let browser agents read, update, and submit checkout — but only after the buyer explicitly confirms the order.
Shopify extended its WebMCP tooling to checkout on September 28, 2026, letting a browser-based AI agent read a buyer's checkout, change it, and submit the order — but only inside the buyer's own browser tab, and only after the buyer has said yes.
What the four checkout tools actually do
Checkout WebMCP registers exactly four tools on the checkout page: get_checkout reads the current checkout state, and after the order is placed, the receipt on the Thank you page; update_checkout changes buyer contact details, fulfillment, discount codes, declared fields, and payment; complete_checkout submits the order; and navigate_to_storefront returns the tab to the storefront without touching the cart or order. All four run inside checkout-web, use the same state as the checkout UI, and require no merchant configuration. Shopify is explicit that this is a browser-only surface: an agent that runs on a server is directed to the separate Checkout MCP instead, which shares the same checkout object, statuses, and messages but is not documented here.
The buyer-confirmation rule complete_checkout can't skip
The most consequential guardrail sits on complete_checkout. Shopify's documentation states plainly that neither a verified Web Bot Auth signature nor a checkout status of ready_for_complete counts as the buyer's permission to place the order. The agent itself has to show the buyer the current order and total and get their go-ahead before calling the tool, and if the total changes after that, it has to ask again. Only a completed status confirms the order actually went through; a complete_in_progress or completion_in_progress response means the agent should poll get_checkout rather than call complete_checkout a second time.
update_checkout is a PUT, not a PATCH
update_checkout is easy to misuse because it behaves like a full replace, not a partial edit. It expects the complete desired checkout state on every call, because checkout clears most fields that are omitted rather than leaving them untouched — the documented pattern is to build each call from a fresh get_checkout response rather than from whatever the agent sent last. Line items and attribution are ignored entirely, since the buyer changes cart contents on the page itself, and an update that runs past 30 seconds comes back as update_failed even though it may still have applied.
Still a proposed standard, not a finished API
None of this ships as a finished spec. Shopify's own changelog calls WebMCP "a proposed web standard" it's helping shape alongside Google and Microsoft, and agent support is currently limited to Chromium-based browsers through an origin trial. Shopify's docs also flag prompt-injection risk directly: any merchant or third-party text that comes back inside a tool response should be treated as checkout data, never as an instruction, and an agent should never fall back to operating the page's own controls when a tool call doesn't do what it expects.