By Andy Gaber, Founder · Published August 23, 2026 · Last updated August 23, 2026
Shopify Checkout Extensibility replaces checkout.liquid and Additional Scripts with a sandboxed extension model built around four surfaces: Checkout UI Extensions for UI customization, the Web Pixels API for third-party tracking, Shopify Functions for logic customization, and app blocks for merchant-installed apps. For Basic, Grow, and Advanced plans, Additional Scripts is removed on 2026-08-26; every third-party tracking script still running through the old path on that date silently stops working. This guide walks the full tracking architecture, focused on how to instrument checkout events cleanly under the new model.
Pre-Extensibility, Shopify's checkout was a Liquid template (checkout.liquid) that merchants and apps could inject JavaScript into via the Additional Scripts field in Settings → Checkout. A Meta Pixel or GTM container installed there ran in the same DOM context as the checkout, could read any DOM element, could manipulate any DOM element, and could execute arbitrary code with no sandboxing. That model was flexible; it was also responsible for a long tail of production incidents in which a third-party script broke the checkout for real customers.
Checkout Extensibility replaces that architecture with sandboxed extension surfaces. UI changes go through Checkout UI Extensions, which run in a sandboxed iframe with a defined React-based API surface. Third-party tracking goes through the Web Pixels API, which exposes a normalized event stream in a sandboxed iframe rather than raw DOM access. Logic changes (custom discount rules, shipping calculations, payment method visibility) go through Shopify Functions. Each extension type has its own defined capability boundary; the collective effect is that a broken third-party script can no longer take down the checkout.
Shopify has scheduled the removal of Additional Scripts and checkout.liquid for all Basic, Grow, and Advanced plan stores on 2026-08-26. On that date, any tracking script or checkout customization still running through the legacy path on those plans silently stops working. There is no fallback and no gradual degradation: the script simply does not load on any checkout page render after the deadline.
Shopify Plus merchants retain a longer migration window with additional legacy support. Plus stores that have not migrated should still plan the transition, but the immediate operational deadline applies only to non-Plus plans. A store on the Basic plan that has not migrated by 2026-08-26 will begin losing checkout tracking events from the moment the removal takes effect, with no in-console warning to the merchant beyond the migration notices Shopify has already published in the Partner Dashboard.
Checkout UI Extensions. React components that render inside defined extension targets on the checkout (a specific position in the checkout flow, such as the shipping method section or the payment method section). UI extensions receive a defined API surface for reading order state and updating specific elements; they cannot manipulate arbitrary DOM.
Web Pixels API. The tracking surface. Custom Pixels installed via Settings → Customer Events run in a sandboxed iframe and receive a normalized event stream. This is the primary interest of this guide.
Shopify Functions. Server-side logic extensions that let a merchant customize discount rules, shipping method visibility, payment method availability, and similar business logic. Functions run on Shopify's infrastructure, not in the browser, and have no direct interaction with third-party tracking.
App blocks. Merchant-installable app components that appear at defined positions in the checkout. From a tracking perspective, an app block operates through the same UI Extensions API as a native UI extension; it does not open a new tracking surface.
The Web Pixels API is Shopify's event-driven runtime for observing customer behavior on the storefront and checkout. It comes in two flavors: App Pixels (published by third- party apps and installed via the Shopify App Store) and Custom Pixels (written by the merchant or an agency and installed directly through Shopify Admin). Both flavors execute inside the same sandbox with the same event schema and the same DOM-access restrictions.
The sandbox is a cross-origin iframe with a restrictive Content Security Policy. Custom Pixels can call fetch() to make outbound network requests (subject to the CSP's connect-src allowlist), can set first-party or third-party cookies within the iframe's document scope, and can call arbitrary JavaScript included in the pixel body. They cannot read the parent page's document, cannot manipulate the checkout DOM, and cannot execute scripts against the checkout's cookie jar directly.
The Web Pixels API exposes a defined event schema. The most commonly instrumented events: page_viewed (every page navigation), product_viewed (a customer views a product detail page), product_added_to_cart, cart_viewed, checkout_started (customer enters the checkout flow), checkout_contact_info_submitted, checkout_address_info_submitted, checkout_shipping_info_submitted, payment_info_submitted, and checkout_completed (successful order). Each event payload includes context (customer, cart, checkout state) and event-specific data (for product_viewed, the productVariant and price; for checkout_completed, the order id, total, currency, and line items).
Field names use camelCase (productVariant, variantId, priceV2), which is a common source of schema-mapping bugs when forwarding to destinations that expect snake_case (GA4 expects item_id, price; Meta CAPI expects content_ids). A production forwarding implementation should have an explicit mapping layer that transforms field names and structures, not a pass-through JSON forward, or events arrive in each destination with missing dimensions.
A minimal Custom Pixel that forwards checkout_completed to a server endpoint installs through Shopify Admin under Settings → Customer Events → Add custom pixel. The pixel body is JavaScript that subscribes to the event stream using analytics.subscribe('checkout_completed', callback), extracts the order data from the event object, and POSTs to the destination endpoint using fetch(). The pixel is customer-scoped: if the customer has declined analytics or marketing cookies, Shopify does not fire the pixel for that customer, enforcing consent at the sandbox layer regardless of what the destination endpoint would do with the data.
The pixel body must complete each event handler quickly; long-running handlers risk being terminated by the sandbox and losing events. A well-written pixel does the minimum work necessary in the browser (extract the required fields, POST once to a durable endpoint) and offloads any heavy processing to the receiving server, which can enrich, validate, and forward to multiple destinations without any browser-side latency.
A production tracking stack on Checkout Extensibility typically pairs a Custom Pixel on the client with a server endpoint that fans out events to destinations. The server can be a GTM Server container hosted on Google Cloud Run or App Engine, a Segment source, a Rudderstack source, a purpose-built serverless function on AWS Lambda or Cloudflare Workers, or any endpoint that can accept POST requests and forward to third-party APIs. The critical property is durability: events arrive at the server, get logged, and get forwarded reliably even when a downstream destination has a temporary outage.
For Meta Conversions API specifically, server-side forwarding is not optional for iOS Safari traffic in 2026: Safari ITP restrictions on third-party cookies and short first-party cookie expiry make browser-only Pixel tracking increasingly unreliable, and Meta's attribution model relies on CAPI as the primary event source for Safari users. The client Pixel and the server CAPI call should share an event_id for deduplication, following the standard Meta CAPI integration guidance.
Shopify's Customer Privacy API captures the current visitor's consent state (analytics, marketing, preferences) through a cookie consent banner (Shopify's native banner or a third-party CMP), and the Web Pixels API automatically enforces consent at the pixel level: pixels tagged as requiring analytics consent do not fire for customers who have declined. This sandbox-layer enforcement is one of the substantive advantages of the new model versus checkout.liquid; under the old model, consent had to be enforced by each individual tracking script's own logic, and misconfigurations that fired trackers without consent were common.
Custom Pixels declare their consent requirements as part of the pixel configuration in Shopify Admin. A pixel that forwards purchase data to a marketing destination should declare marketing_consent as required; a pixel that forwards to an analytics destination for aggregate reporting should declare analytics_consent as required. The pixel body itself does not need to check consent state at runtime; Shopify enforces it before the pixel executes.
The post-purchase page (the "Thank You" page shown immediately after order completion) is its own extension surface. Post-purchase UI Extensions render on that page with a defined API for reading order state and, on Plus plans, offering post-purchase upsells. From a tracking perspective, checkout_completed already fires on the checkout side before the post-purchase page renders, so most conversion tracking should trigger off checkout_completed rather than off a post-purchase page-view event. Storefront-side page-view tracking on the thank-you page runs through the storefront tracking model, not through Web Pixels API, and is often useful for on-page cross-sell attribution.
The failure modes that catch merchants off-guard on Checkout Extensibility, in rough order of frequency: (1) a Custom Pixel is disabled or its underlying event subscription throws an error inside the sandbox, silently stopping event forwarding without alerting the merchant; (2) a schema drift on a destination endpoint (Meta CAPI, GA4, TikTok Events API) causes events to be rejected server-side after forwarding, so the pixel appears to work in Shopify but no events land in the destination; (3) a legacy tracking script left behind in Additional Scripts on a non-Plus store stops working on 2026-08-26 and nobody notices until the following quarterly attribution review.
All three failure modes are recoverable, but only if a monitor catches them within hours rather than weeks. Merchants that rely on manual quarterly attribution reviews to detect tracking failures routinely discover that between one and three weeks of marketing spend was optimized against a broken conversion signal. The fix cost is always small next to the wasted spend, but the missing signal cannot be recovered after the fact.
PixelProof monitors Meta Pixel, GTM, and GA4 events continuously against Shopify's Web Pixels API event stream and each destination's ingestion log, alerting the moment an event stops flowing or a schema drifts. It is a monitor, not tracking infrastructure; it does not install pixels, build server containers, or send events. It watches tracking that already exists and tells you the day it breaks.
Free scan: audit your Checkout Extensibility tracking in under 90 seconds.
Run the free Checkout Extensibility scan →Checkout Extensibility is Shopify's replacement architecture for checkout.liquid and Additional Scripts. It exposes four extension surfaces (Checkout UI Extensions, Web Pixels API, Shopify Functions, and app blocks) that let merchants and apps customize the checkout without touching a Liquid template. Extensions run in sandboxed environments with defined APIs rather than in the main checkout DOM.
Yes for non-Plus merchants. Shopify has scheduled the removal of Additional Scripts and checkout.liquid for Basic, Grow, and Advanced plans on 2026-08-26. Any tracking or customization still running through Additional Scripts on that date silently stops working on those plans. Shopify Plus merchants retain a longer migration window with additional legacy support.
For third-party tracking on the checkout page, yes: the Web Pixels API is the only supported way for third-party pixels to observe checkout events on non-Plus stores after the migration. On storefront pages (product, collection, cart), traditional client-side pixels installed via theme.liquid still work. The two contexts have different tracking mechanisms and must be instrumented separately.
Yes. A Custom Pixel installed through Settings → Customer Events can call fbq() with a custom event name and payload, subject to the sandbox's CSP restrictions and outbound network policy. The pixel executes inside an iframe, so any state or cookies it sets are scoped to that iframe context, not to the parent checkout page.
Shopify Admin exposes a preview mode for Custom Pixels under Settings → Customer Events → the pixel detail view → the event log. Events fire in preview against a test order flow before the pixel is set live. For production monitoring, use each destination's test-events view (Meta Events Manager Test Events tab, GA4 DebugView) to confirm events arrive in the destination with the expected payload.
PixelProof is a compliance monitoring service, not a certification or legal advice service. Monitoring cannot guarantee 100% detection of every pixel breakage or Meta API deprecation. Merchants remain responsible for their own tracking compliance.
PixelProof is not affiliated with Meta, Google, or Shopify.