Shopify WebMCP checkout: How to verify your extensions and tracking for AI-agent purchases

Shopify’s September 28, 2026 WebMCP update lets browser-based AI agents read checkout, update supported fields, and place an order after the buyer confirms it, inside the buyer’s own browser session. Shopify requires no merchant configuration and does not promise that every custom extension or tracking tag behaves identically. Inventory your checkout customisations, run an agent-driven test order, then compare Shopify orders with GA4, Google Ads, and Meta conversions.

Shopify’s September 28, 2026 WebMCP checkout update lets browser-based AI agents do what a shopper’s hands normally do: read the checkout, fill in supported fields, and place the order once the buyer has confirmed it. Instead of clicking through the page, the agent calls structured tools inside the buyer’s own browser session, and Shopify says those tools use the same checkout state as the human interface and need no merchant configuration. That means agent-driven checkout can reach your store without you switching anything on, and it raises a question most merchants have not answered yet: do your checkout extensions, tracking tags, and data fields still work when something other than a person drives the flow?

This guide explains how Shopify’s agent tools work, what Shopify has confirmed about buyer confirmation and bot identification, and which parts of a checkout deserve a test because Shopify does not promise they behave the same way for an agent. It is written for merchants with checkout extensions, custom fields, or tracking tags, and it keeps documented behaviour separate from reasoned risk, so you can tell which findings are facts and which are things to check.

What is Shopify’s WebMCP checkout?

WebMCP is a proposed web standard. A storefront registers tools with the browser, and an AI agent calls them with structured inputs, instead of reading the page’s code and simulating clicks, which Shopify describes as slow and error-prone. Shopify’s checkout version implements the Universal Commerce Protocol checkout capability over tools registered in the browser. The responsibilities split like this:

What the agent does	What the buyer and Shopify do
get_checkout reads the checkout state and messages	The buyer sees the same checkout state on the page
update_checkout fills in supported fields	The buyer handles page interactions such as Shop Pay login or a payment challenge
complete_checkout places the order after the buyer’s permission	The buyer confirms the current order and total, and reviews it on a review step if one is configured
navigate_to_storefront returns the tab to the storefront	Shopify decides which checkouts are eligible and registers the tools

Checkout WebMCP is for agents that run in the buyer’s browser. Agents that can run on a server use Checkout MCP instead, and the two share the same checkout object, statuses, and messages. The tools are not an API you enable. Shopify registers them on eligible checkouts, which is why “no merchant configuration” and “nothing to verify” are not the same statement.

How does an AI agent move through a Shopify store?

Checkout is the last stage of a longer journey. Shopify’s storefront and cart tools were already live before September 28, so an agent can now assist the whole path, and what it does earlier shapes what your checkout receives:

Stage	Tools	What to know
Discover	search_catalog, browse_store, get_product, show_variant	Reads product, collection, and search data through the Storefront API. show_variant opens a product page with a chosen variant selected.
Build the cart	get_cart, add_to_cart, update_cart_lines, cancel_cart	Calls the standard storefront actions that apps use, so an agent’s cart changes behave like the shopper’s, including a theme’s cart drawer if you have configured one.
Enter checkout	proceed_to_checkout	Takes the shopper to checkout with the current cart after confirming it is not empty. The available tools change when checkout loads.
Complete checkout	get_checkout, update_checkout, complete_checkout, navigate_to_storefront	Act on the checkout open in the buyer’s tab, described below.
After the order	get_checkout on the Thank you page, manage_orders	Reads the order receipt, or takes the shopper to their order history, asking them to log in first if needed.

Shopify provides the storefront tools on every Liquid storefront and on Hydrogen 2026-10 storefronts that render the Shopify scripts component. On Hydrogen they load by default when the browser supports WebMCP and can be turned off with the webMcp setting. Shopify notes that agent support is currently limited to Chromium-based browsers, and that everything the agent does happens in the tab the shopper is looking at.

What changed on September 28, 2026?

Shopify added checkout to the tools. The Checkout WebMCP documentation describes four tools that run inside checkout and act on the checkout open in the buyer’s tab:

• get_checkout: read the current checkout, or the order receipt on the Thank you page
• update_checkout: replace buyer contact details, fulfilment, discount codes, declared fields, and payment
• complete_checkout: place the order after the buyer confirms it
• navigate_to_storefront: leave checkout and return the tab to the storefront, registered only when the store has an online storefront

Shopify says the tools run inside checkout-web, use the same state as the checkout interface, and do not expose a new API or require merchant configuration. Checkout tools are registered on eligible checkouts, so do not assume every checkout on your store is covered. When the buyer’s input is needed, such as 3D Secure authentication or a blocking UI extension, the tools hand control back to the buyer.

What can an agent change at checkout?

Field	What the agent can do	Limits worth knowing
Buyer contact	Replace email and phone number (phone in E.164 format)	Shop Pay can keep saved values, and Shopify says to verify the returned buyer state.
Delivery	Set a shipping address, use a saved Shop Pay address, choose a delivery option or pickup location, with at most one method	Checkout rejects addresses the store does not ship to, and omitted delivery details such as a phone number or instructions are cleared.
Discount codes	Replace the list of buyer-entered codes	An empty list removes them all, automatic discounts stay, and a returned code does not prove it was applied.
Declared fields	Fill extra checkout fields such as a tax number or the store credit choice	A key the checkout does not declare, or a value of the wrong type, is rejected.
Payment	Select a saved Shop Pay card, or set a billing address on a guest checkout	New card details are not accepted. The buyer chooses any other method on the page.
Cart items	Nothing	Checkout ignores line items, so the buyer changes items on the page.

How do buyer confirmation and bot identification work?

Buyer confirmation

An AI agent cannot simply place an order on its own. Shopify instructs agents to show the buyer the current order and total and get their permission before calling complete_checkout, and says that neither Web Bot Auth verification nor a checkout status of ready_for_complete grants that permission. If the total changes, the agent should ask again. If checkout opens a review step, the buyer reviews the order on the page, and the agent calls the tool again only after the buyer authorises submission. If the buyer has to finish a payment challenge, the agent should poll get_checkout until the status is completed, because only that status confirms the order.

How Shopify identifies agents

Shopify uses Web Bot Auth to identify agents and verifies only registered keys. Without it, Shopify says bot detection might deprioritise or block an agent’s requests. Two practical points follow. Agents are not all treated alike, so a test with one agent does not describe them all. And a verified agent still does not have permission to buy, because verification and buyer consent are separate. Shopify also tells agent developers to treat merchant and third-party text in tool responses as data, not instructions, because it can contain prompt-injection attempts, a reminder that agents read the messages your checkout shows, so keep checkout copy clear and factual.

Which stores should test agent-driven checkout first?

Every store with eligible checkouts is in scope, but the cost of a surprise is not the same everywhere. Testing is most urgent if your store:

• Uses checkout UI extensions, especially blocking ones, or collects extra data such as loyalty IDs, gift messages, or purchase order numbers
• Relies on custom web pixels or third-party tags to record purchases for GA4, Google Ads, Meta, or affiliate attribution
• Runs promotions that depend on discount codes or on delivery details the buyer enters
• Sells internationally, where checkouts can ask for extra fields such as a tax number
• Runs a Hydrogen storefront, where the tools load by default when the browser supports WebMCP

A standard checkout with no extensions and no custom pixels carries less risk of the problems described below. Even then, one agent-driven test order is cheap, and it is the only way to be sure.

Which checkout customisations are most at risk?

Shopify documents how the tools behave, but not how every extension or tag will respond to them. The areas below are worth testing. The first rests on documented behaviour, and the rest are reasoned risks to check, not confirmed failures.

Data your checkout collects

update_checkout uses PUT semantics: the agent must send the complete desired state, and checkout clears most omitted values, with field-specific behaviour for payment, declared fields, and saved contact details. An agent that builds an update without a fresh get_checkout response can therefore drop values such as discount codes or delivery instructions, and delivery details such as a phone number or instructions are cleared when omitted. Shopify exposes extra checkout fields to agents as declared fields, but does not say how fields collected by your own checkout UI extensions are treated. Check delivery instructions, gift messages, loyalty IDs, and purchase order numbers on agent-placed orders.

Purchase tracking and pixels

Shopify confirms that agents work in the same checkout-web context as the human interface. It does not guarantee that every custom script or third-party tag behaves identically. If a tag depends on user-initiated events, timing assumptions, or visual-rendering checks, test whether it still records the purchase after an agent-completed order.

Extensions with timing or event dependencies

Agent-driven interactions may change checkout state through structured tool calls instead of manual clicks, and may do so more quickly or in a different order. That makes extensions that initialise on click, change, or focus events, rely on delayed or lazy initialisation, or wait for the page to go idle a priority to test, not a confirmed failure mode.

Payment and authentication handoffs

When a payment challenge needs the buyer, the buyer completes it on the checkout page in the same tab and the agent should not submit again. A stalled checkout can therefore look like a buyer who never completes the handoff. Watch for orders that start but never reach the Thank you page.

What Shopify does not say

Shopify confirms that the tools use the same checkout-web context and state as the human interface and that no merchant configuration is required. It does not state that agents skip DOM events, run faster than scripts initialise, or cause web pixels to miss purchase events, and it does not guarantee that every third-party extension or analytics tag will behave identically under agent-driven interaction. Treat tracking and extension compatibility as something to test, not assume.

What do checkout statuses and errors tell you?

When you run a test with an agent, the responses it receives explain why a checkout stalled. Shopify documents these meanings, and the right-hand column suggests what to look at on your side:

Status or error	What Shopify says it means	What to check on your side
ready_for_complete	The checkout can be completed, but this status does not grant permission to place the order.	Whether the order and total were shown and confirmed.
requires_escalation	A review step is configured, so the buyer must review the order on the page before the agent calls again.	Whether your review step is clear to a buyer who arrives from an agent.
incomplete	An update succeeded but the checkout still needs something, for example when a selected saved card becomes unusable.	The checkout messages and any extension that adds requirements.
buyer_action_required	The buyer must finish a step on the checkout page.	Payment challenges and blocking extensions, the usual handoff points.
checkout_busy, completion_in_progress	Checkout is submitting, processing payment, or running another call.	Slow extensions or payment steps that keep checkout busy.
update_failed	An update failed or ran longer than 30 seconds, and it might have partly applied.	Whether values on the order match what the agent sent.
rejected	Checkout cannot apply the update as requested, such as an unavailable declared field or an address the store does not ship to.	Shipping zones and the extra fields your checkout declares.
completion_failed	Checkout could not confirm completion, and the agent should not resubmit while the outcome is unknown.	The order list in Shopify admin, before assuming no order was placed.
completed	The order was placed. Only this status confirms the order.	That the order data and purchase events both arrived.

Why your usual checkout test may not cover agent-driven flows

Most merchants test checkout by placing an order themselves, clicking through on their own device with their own details. That tests the human path. An agent-driven order uses structured tool calls inside the same session, and it can reach states a manual test never does, such as an update that replaces the whole checkout object or a handoff to the buyer at a payment challenge.

It also helps to separate two kinds of agents. Checkout WebMCP serves agents that run in the buyer’s browser. Agents that run on a server use Checkout MCP and do not run in a browser, so client-side tags have no page on which to fire. That makes the gap between Shopify orders and analytics events worth watching for both.

What should you prepare before running an agent test?

Agent tests are quick, but they are only useful if you can tell afterwards what changed. Use this checklist to set up a clean comparison:

Check	Why it matters	What to do
A list of customisations	Each extension or pixel is a place where an assumption about human interaction can hide.	List checkout UI extensions (blocking and non-blocking), web pixels and Customer Events tags, post-purchase extensions, custom fields, discount logic, and loyalty or gift card integrations.
Event and timing dependencies	Logic that waits for clicks, timers, or visibility checks deserves the first tests.	Note which customisations depend on click, change, focus, or blur events, on setTimeout or requestIdleCallback, on visibility checks, or on multi-step interaction.
A baseline	Without one, you cannot tell what agent traffic changed.	Record 30 days of Shopify orders next to GA4 purchases, Google Ads conversions, and Meta purchases.
A test product and payment path	Agent purchases create real orders, and agents cannot type new card details.	Choose a low-value product, and use a saved Shop Pay card or a guest checkout where you finish payment on the page.
A WebMCP-capable agent	Agent support is currently limited to Chromium-based browsers.	Use a Chromium-based browser and an agent that can call WebMCP tools.
Fields to verify afterwards	Missing values are the clearest sign of a problem.	Decide in advance which discount code, delivery instructions, declared fields, and loyalty or gift data you will look for.

How do you test checkout extensions and tracking for agent traffic?

Step 1: Run an agent-driven test order

• Add products to the cart and let the agent drive checkout through the tools
• Confirm the order only after the agent has shown you the order and total
• Note any point where the agent hands control back to you, and what the page showed you at that point

Step 2: Verify order integrity

In the Shopify admin, open the test order and check that custom fields, discount codes, delivery instructions, and loyalty or gift card data are present and correct. Because update_checkout replaces the whole state, missing values are a sign to raise with your checkout app developer.

Step 3: Verify purchase tracking

Confirm that your web pixels record the checkout_completed event and that downstream purchase events arrive. Check the GA4 purchase event in DebugView, the Google Ads conversion in Tag Assistant, the Meta purchase event in the Events Manager test tool, and any affiliate or attribution pixels.

Step 4: Reconcile orders and conversions

Compare the order from your test with the events it produced. Small differences between platforms are normal, because attribution and timing differ. A test order that exists in Shopify but has no matching purchase event is the finding that matters.

Step 5: Monitor agent-completed orders in production

• Compare the count of Shopify orders with conversion events in GA4 and Google Ads to spot a widening gap
• Watch checkout extension errors for spikes that line up with non-human interaction patterns
• Look for orders with missing custom field data that your extensions should have collected
• Track checkouts that start but never reach the Thank you page, since a payment handoff that is not completed leaves them stalled

Common mistakes when testing agent-driven checkout

• Reading “no merchant configuration” as “nothing to verify.” Shopify says you do not need to enable the tools. It does not say your extensions and tags need no testing.
• Testing only the human path. Your own manual test order tells you nothing about an update that replaces the whole checkout state.
• Blaming agents for every dip in GA4 purchases. Compare against your baseline first, because tracking gaps have many causes and the share of agent traffic on your store is unknown.
• Testing a path agents cannot complete. Agents cannot enter new card details, so a test that needs one will stall for reasons unrelated to your store.
• Fixing one tag and stopping. Check the order data as well as the pixels, because a purchase event can fire correctly on an order that is missing fields.
• Testing once. A theme update, a new extension, or an app update can change what the test showed, so repeat it after changes.

When should you contact your checkout app developer?

Raise it with the developers of your checkout extensions and tracking apps if your test shows missing order data, a purchase event that did not record, or a checkout that stalled. Ask them whether their extension has been tested with agent-driven checkout through WebMCP, and how it handles an update that replaces the full checkout state. Their answer tells you whether the risk is theoretical for your store or real.

How do you build checkout customisations that work for both buyers?

• Design checkout extensions to be interaction-agnostic. Do not assume a person clicks through every step. Prefer state-based logic over event-based triggers where you can.
• Record conversions on state changes, not on page events. Web pixels that respond to checkout completion work whichever way the flow was driven.
• Treat the orders-to-conversions gap as an early signal. A growing discrepancy suggests some completions are not firing their tracking events.

What to do this week

1. List your checkout extensions, pixels, and custom fields, and record a 30-day baseline of orders against GA4 purchases.
2. Run one agent-driven test order with a low-value product, and check the order data and the purchase events.
3. Ask your extension and tracking app developers whether they have tested agent-driven checkout, and set up a regular comparison of orders and conversions.

Agent-driven checkout can only be trusted as far as you have tested and measured it. Shopify has documented how the tools behave, and the rest is yours to verify.

Watching for agent-driven checkout gaps with AuditIQ

Agent traffic may still be a small part of your store’s traffic, but the signals that show a problem look the same as any other checkout problem: fewer completions, a widening gap between orders and conversions, or a tag that has gone missing. AuditIQ helps you spot them:

• User Experience Monitoring: tracks drop-off at each step of the checkout flow, with device, browser, and session context. It shows where checkouts stall, whoever or whatever was driving them.
• Analytics: unsampled Google Analytics data, including conversion funnel analysis, alongside your technical monitoring, so GA4 purchase counts can sit next to the order counts you take from Shopify.
• Script Inventory: a ledger of every JavaScript file on the storefront pages it crawls, with when each was first and last seen, so a tracking script that disappears after a theme or app change is visible.

AuditIQ does not identify which orders came from AI agents, read your Shopify orders, or run WebMCP checkouts, so keep the agent-driven test order and the order-to-analytics comparison in your routine, and use monitoring to tell you when to run them.

Beyond checkout, AuditIQ is a 360° eCommerce monitoring platform purpose-built for Magento, Adobe Commerce, and Shopify stores. It continuously monitors every critical layer of a store — performance, infrastructure, SEO, security, user experience, configuration, and code quality — from a single, unified dashboard, so quiet failures are caught whether a person or an agent was the shopper.

Start monitoring your checkout journey for free today to see where checkouts stall before it costs you orders.

Others also read

• AI Agents can now shop on your site: Can you see them?
• Shopify’s August 26 checkout deprecation: How to protect your post-purchase revenue flows
• Your products may not be showing up when AI agents search for them: How to verify Shopify catalog visibility before the November 2 API shutdown

Frequently asked questions

1. Will Shopify’s WebMCP checkout work with my existing checkout extensions?

Shopify says blocking UI extensions hand control back to the buyer. It does not describe how other extensions behave when an agent drives checkout, so test them, particularly any that depend on user events or timing.

2. Do I need to configure anything to enable WebMCP checkout?

No merchant configuration is required for the checkout tools, but they are registered only on eligible checkouts. Storefront WebMCP tools are available on every Liquid storefront and on Hydrogen 2026-10 storefronts that render the Shopify scripts component.

3. Can I turn WebMCP off?

Shopify’s documentation describes a webMcp setting for Hydrogen storefronts. For Liquid storefronts and the checkout tools, it does not describe an opt-out, so ask Shopify Support if you need one.

4. Can an AI agent place an order without the buyer’s approval?

Shopify requires the buyer to confirm the current order and total before the agent calls the complete tool. If a review step appears, the buyer reviews it on the checkout page and authorises submission before the agent proceeds.

5. Can an AI agent type in a card number?

No. Checkout WebMCP does not accept new card details. An agent can select a saved Shop Pay card or set a billing address on a guest checkout, and the buyer chooses any other payment method on the checkout page.

6. Will GA4 and Google Ads tracking fire correctly for agent-completed orders?

Shopify confirms that the tools operate in the same checkout-web context and use the same state as the checkout interface. It does not guarantee identical behaviour for every custom script, extension, or third-party tag, so test purchase and checkout-completed events with an agent-driven order before relying on them.

7. How is Checkout WebMCP different from Checkout MCP?

Checkout WebMCP is for agents running in the buyer’s browser, acting on the checkout open in that tab. Checkout MCP is for agents that can run on a server. They share the same checkout object, statuses, and messages, but only the browser route involves client-side scripts on the checkout page.