Shopify Checkout Extensibility: What It Broke for Tracking

TL;DR

Shopify moved checkout customization from a free-form Liquid template to a sandboxed extension model. The Web Pixels API is now the only supported way to fire tracking events from the checkout. Custom JS you pasted into checkout.liquid does not carry over. If your tracking app was built around that pattern, you have a gap. If it was built on the Web Pixels API, you do not.

What Shopify Actually Replaced

The old checkout was a Liquid template file called checkout.liquid. Shopify Plus merchants could edit it directly, which meant you could drop a raw <script> tag anywhere in the checkout, fire a pixel, push data to a dataLayer, or load a third-party library.

That flexibility was also the problem. Shopify could not update the checkout experience, add accelerated payment methods, or enforce performance standards without risking conflicts with whatever arbitrary code merchants had injected. So they drew a line.

Checkout Extensibility replaces the editable template with two building blocks:

1. Checkout UI Extensions for visual customization (adding fields, banners, custom sections) [2]
2. Web Pixels API for all event-based tracking [1]

The Web Pixels API runs tracking code in an isolated sandbox, separate from the checkout page itself. It subscribes to standardized events like checkout_completed, payment_info_submitted, and page_viewed, and fires your pixel or tag when those events happen [1]. You do not get direct DOM access. You do not get window.dataLayer. You get a structured event payload and a sandboxed execution context.

That is a meaningful constraint, but it is also why this approach is more reliable. The sandbox cannot be broken by a theme update, a conflicting script, or a checkout UI change Shopify ships overnight.

The Deprecation Timeline (What Shopify Has Confirmed)

Shopify has not quietly deprecated checkout.liquid. They published the sunset on shopify.dev [3].

For Shopify Plus stores, checkout.liquid was deprecated for the information, shipping, and payment steps. Shopify's documentation states that the upgrade to Checkout Extensibility is required for Plus stores to maintain access to the latest checkout features and that legacy checkout.liquid customizations will eventually stop being supported [3].

The thank_you page and order_status page follow a separate timeline and are also being migrated to the new extension model [2].

If you are on Shopify Plus and have not migrated yet, your current checkout keeps working, but you cannot add new Checkout UI Extensions to it, and you are accumulating migration debt. If you are on a standard Shopify plan, this does not apply to you since checkout.liquid was always Plus-only.

How the Web Pixels API Works for Tracking

The Web Pixels API is Shopify's standardized interface for running analytics and advertising pixels during and after the checkout [1].

When a customer completes checkout, Shopify fires a checkout_completed event. The Web Pixels sandbox receives that event with a structured payload: order ID, line items, revenue, customer data, and more. Your pixel code or tracking app subscribes to that event and sends it to GA4, Meta, Google Ads, or wherever you need it.

This matters for two reasons:

First, the event fires from within Shopify's own checkout flow, so it is not dependent on a third-party script loading before the page closes. Traditional tag-manager-based setups occasionally miss checkout_completed because the page redirects before the tag fires. The Web Pixels sandbox handles timing differently.

Second, the structured event schema means the data is consistent. You are not parsing dataLayer.push events that different apps format differently. The payload shape is defined by Shopify and documented publicly [1].

Customer Events in Shopify Admin (Settings → Customer events) is the merchant-facing interface for managing Web Pixel apps. When you install a tracking app that uses the Web Pixels API, it appears there.

Verify on Your Own Store: Check Your Checkout Tracking Setup

If you are not sure whether your current tracking setup survives a Checkout Extensibility migration, run through this in the next 15 minutes.

Step 1: Check whether you are on a legacy or extended checkout Go to Shopify Admin → Settings → Checkout. Scroll to "Checkout customization." If you see a button labeled "Customize" that opens the visual editor with sections and blocks, you are on Checkout Extensibility. If you see a code editor for checkout.liquid, you are on the legacy template.

Step 2: Check what tracking pixels are registered Go to Shopify Admin → Settings → Customer events. Every app using the Web Pixels API appears here with a status indicator. If a pixel is listed and shows as active, it is using the supported API path.

Step 3: Check for orphaned scripts If you or a developer added raw <script> tags to your checkout.liquid in the past (Google Ads conversion tag, Meta pixel, custom GA4 snippet), those scripts are not automatically registered as Web Pixels. After migration, they will not fire. Look for any <!-- tracking --> style comments or gtag / fbq function calls in your checkout.liquid file.

Step 4: Confirm in GA4 Go to GA4 → Reports → Monetization → Ecommerce purchases. Look at the purchase event count over the last 30 days and compare it to your Shopify order count in Admin → Orders. A material gap on a store with consistent order volume usually signals a checkout tracking issue, not just browser privacy noise.

If you are seeing unexplained attribution gaps after the migration window, the Shop Pay checkout article covers one specific mechanism that causes undercounting even on well-configured stores.

What Breaks When You Migrate (And What Does Not)

Not every tracking setup breaks. The outcome depends entirely on how the tracking was instrumented.

Breaks after migration:

• Raw <script> tags pasted into checkout.liquid (they do not exist in Checkout Extensibility)
• Google Tag Manager containers loaded via checkout.liquid (same reason)
• Custom Liquid variables passed to third-party scripts via {{ checkout.order_id }} or similar template syntax
• Any server-side setup that relied on firing from a custom checkout.liquid template tag

Not affected:

• Tracking apps installed through the Shopify App Store that use the Web Pixels API
• Shopify's own Customer Events integrations (like the native Google and Meta channels)
• Server-side event forwarding that reads from Shopify's Order webhooks or the Admin API, since those are independent of the checkout template entirely

This also affects email and SMS platforms that trigger post-purchase flows from checkout events. If you use Klaviyo and the integration relies on JavaScript events fired from checkout.liquid, the Klaviyo + Shopify tracking article covers where that specific gap shows up and how to address it.

What Checkout Extensibility Means for Attribution

The migration introduces a specific attribution challenge that is easy to miss.

Under the old model, a merchant could fire a purchase event with full order data immediately on the order_status page by embedding JS directly. Under Checkout Extensibility, that page is now a post-purchase extension, and the event model is still the Web Pixels API.

The practical implication: if your attribution setup depended on the order_status page firing a pixel with full transaction data and you have not verified the Web Pixels replacement is active, you may be recording conversions with missing revenue or missing order IDs. Those conversions still count in Google Ads and Meta, but they distort your ROAS numbers. Stores using accelerated checkout buttons should also review the Shop Pay tracking patterns since Shop Pay bypasses parts of the standard checkout flow entirely.

Run the diagnostic above and specifically check whether checkout_completed and purchase events are arriving in your ad platforms with value and order_id populated. In Meta Events Manager, go to Events Manager → Data Sources → [your pixel] → Test Events and place a test order. Confirm the Purchase event includes a value parameter. In Google Ads, go to Conversions → [your purchase conversion action] → Diagnostics and check for missing transaction data warnings.

Key Takeaways

• Any <script> tag injected into checkout.liquid stops firing when you migrate to Checkout Extensibility. Audit your checkout template before you upgrade.
• Shopify Admin → Settings → Customer events shows every Web Pixels API app registered on your store. If your tracking app is not listed there, it is not using the supported path.
• The Web Pixels API runs in a sandboxed iframe, which means no window.dataLayer access and no direct DOM manipulation. Tools built around GTM containers loaded in checkout.liquid need to be replaced, not just moved.
• Compare GA4 purchase event count to Shopify order count monthly. A material gap on stores with consistent order volume warrants investigation.
• The order_status page is also migrating to the extension model, so any pixel firing from that page specifically needs the same audit as the main checkout.
• Shopify's published deprecation documentation at shopify.dev is the authoritative source for timeline details [3]. Do not rely on secondhand summaries for planning your migration date.
• Tracking tools built on the Web Pixels API work on both legacy and Checkout Extensibility stores without code changes, so migrating does not require a re-implementation.

FAQ

Does checkout.liquid still work in 2025?

For Shopify Plus stores, checkout.liquid still renders on stores that have not migrated, but Shopify has deprecated it and migration to Checkout Extensibility is required to access new checkout features [3]. Standard plan stores never had access to checkout.liquid, so this only applies to Plus merchants.

How do I fire a GA4 purchase event from Checkout Extensibility?

The supported method is a Web Pixels API integration. Either use a tracking app that registers a Web Pixel through Settings → Customer events, or use Shopify's native Google sales channel which does this automatically. You cannot load a GTM container or gtag.js snippet directly in the checkout via script injection under the new model [1].

Will my existing tracking app break when I migrate to Checkout Extensibility?

It depends on how the app was built. Apps that use the Web Pixels API (visible in Settings → Customer events) are unaffected. Apps that worked by injecting scripts into checkout.liquid or requiring merchants to paste code manually into that template will stop tracking the checkout after migration. Check the app's documentation or contact the developer before upgrading.

What is the difference between Customer Events and Web Pixels API?

They are the same system from two different perspectives. The Web Pixels API [1] is the developer-facing interface that app developers use to register and subscribe to events. Customer Events is the merchant-facing UI in Shopify Admin where you can see which pixels are active and manage their consent settings. When an app uses the Web Pixels API, it appears automatically in Settings → Customer events.

Does Checkout Extensibility affect tracking on the thank you page?

Yes. The order_status page (the thank you page) is also part of the migration to Checkout Extensibility and post-purchase extensions [2]. Any pixel or script that was firing exclusively on that page via checkout.liquid injection needs to be replaced with a Web Pixels API implementation.

WeltPixel Conversion Tracking and Checkout Extensibility

WeltPixel Conversion Tracking (WCT) uses Shopify's Web Pixels API for all checkout-stage events, including checkout_completed and purchase. That means it works on both legacy checkout.liquid stores and Checkout Extensibility stores without any code changes required on your end.

When you migrate to Checkout Extensibility, WCT does not require a re-installation, a developer session, or a new pixel configuration. The Web Pixel registration carries over because it is tied to the app, not the checkout template.

WCT also handles server-side event forwarding for GA4, Meta, Google Ads, and TikTok, which means the conversion data arrives even when browser-side signals are degraded by ad blockers or iOS privacy changes. For the full picture of why server-side matters once Checkout Extensibility is in place, see Shopify server-side GA4 tracking.

Install WeltPixel Conversion Tracking

Sources

1. Shopify Web Pixels API documentation: https://shopify.dev/docs/api/web-pixels-api
2. Shopify Checkout Extensibility for app developers: https://shopify.dev/docs/apps/build/checkout
3. Shopify checkout configuration and customization settings: https://help.shopify.com/en/manual/checkout-settings/customize-checkout-configurations