Most headless Shopify teams have finished migrating off checkout.liquid and Shopify Scripts. The problem that replaces those migrations is quieter. A shopper completes a purchase, and the analytics report credits it to direct traffic rather than the campaign that brought them in.
That reads like a tracking bug, but the cause is architectural. Checkout Extensibility put checkout on Shopify's own domain and closed it to storefront code, so sessions, consent, and campaign data now cross a boundary the storefront team doesn't control.
This guide covers how the framework works, which features each Shopify plan supports, and where a headless team still shapes the buying experience.
Key takeaways:
Checkout Extensibility is Shopify's replacement for checkout.liquid and Shopify Scripts, both of which have now stopped working entirely.
Extensions run in a sandbox that can't reach the checkout page's HTML, so customizations use Shopify's own UI components under a 64 KB bundle limit.
Customizing the information, shipping, and payment steps requires Shopify Plus, while Basic and above can customize the thank-you and order-status pages.
Shopify hosts checkout on its own domain, so a headless storefront hands the shopper off by redirect and loses analytics continuity there unless both sit on a shared root domain.
A storefront controls speed, personalization, and tracking only before that redirect, which is where a headless team's remaining conversion work sits.
Copy link to headingWhat is Shopify Checkout Extensibility?
Shopify Checkout Extensibility is a framework of sandboxed extension points for adding UI blocks, backend logic, and event tracking to Shopify's hosted checkout. Extensions can declare components and run business logic, but they get no access to the checkout page's Document Object Model (DOM).
The payoff for that isolation is durability. An extension built against the framework survives Shopify's checkout upgrades because it never touches page markup that Shopify can change without notice. Themes built on checkout.liquid carried no such guarantee, and the cutoff date proved it.
Copy link to headingTrack the deprecation timeline behind checkout.liquid and Scripts
These deprecations rolled out over two years, and all of them have now passed. A team inheriting a Shopify build today will still find code written against the old surfaces. The dates matter for diagnosing what broke, not for planning a migration:
Stores still running the old surfaces past these dates moved to an uncustomized default checkout. Migration is the only path forward for anything that used to live there.
Copy link to headingRecognize why Checkout Extensibility changes the headless build
A themed Shopify store runs into few of these constraints, because its storefront and checkout sit on the same domain and share one analytics context. A headless build has neither, so Shopify's checkout rules turn into storefront engineering work.
For a team running Next.js against Shopify's Storefront API, the framework sets the terms for everything on the far side of the redirect:
Plan gating limits what you can build: Checkout UI extensions on the information, shipping, and payment steps require Shopify Plus. Custom apps containing Shopify Functions also require Plus; other plans can use eligible Functions through public App Store apps, subject to API-specific restrictions.
The checkout page is closed to your code: Extensions can't read or write the checkout's HTML, and they can't touch payment data. Anything that previously depended on checkout.liquid's markup has no replacement.
Tracking splits across two domains: Web Pixels report only on Shopify-hosted pages, and the storefront isn't one of them. A Next.js app has to emit its own page-view and add-to-cart events.
Bundle size caps what an extension can do: Checkout UI extensions using API version 2025-10 or later have a default 64 KB compressed JavaScript bundle limit. Shopify may approve exceptions for unavoidable bundle weight after optimization.
None of these are gaps in the framework. They're the terms Shopify set for keeping a checkout it controls fast and consistent across every store running on it.
Copy link to headingHow does Shopify Checkout Extensibility work?
Four components carry the framework: Checkout UI Extensions for interface blocks, Shopify Functions for backend logic, Web Pixels for event tracking, and a configuration API for branding. Which ones a store can use depends on the plan it runs.
Plus is the dividing line for anything rendering before payment, while every plan reaches the post-purchase surfaces and event tracking. What each component does inside those limits varies more than the table suggests.
Copy link to headingBuild UI blocks with Checkout UI Extensions
Checkout UI Extensions render interface blocks built from Shopify's Polaris web components, drawn inside an isolated sandbox through the remote-dom library. That sandbox is a web worker with no access to the checkout page's HTML, no access to payment data, and no window object to reach for.
Shopify caps a compiled checkout extension at 64 KB and rejects anything larger at deploy time. Each stable API version stays supported for at least twelve months, and the CLI refuses deploys targeting anything older. A live extension therefore needs a version bump roughly once a year.
Copy link to headingRun backend logic with Shopify Functions
Shopify Functions cover discounts, delivery and payment customization, cart transformation, and cart and checkout validation. They run as WebAssembly inside Shopify's own infrastructure, which is why they apply to every checkout attempt rather than only to sessions that reach the browser.
Resource limits are tight. A function has a limit of 11 million instructions per execution for carts with up to 200 line items. That limit scales proportionally for larger carts. The compiled binary must fit within 256 kB. Shopify strongly recommends Rust, because a slower language risks failing outright on a large cart. Cart and checkout validation runs last in the checkout sequence, which makes it the only function able to stop a purchase from completing.
Copy link to headingTrack events with Web Pixels
Web Pixels subscribe to customer events from inside a sandbox, and Shopify runs two of them. App pixels get a strict sandbox, while custom pixels configured in the admin get a lax one. Either sandbox exposes an analytics object for subscribing to events and a browser object that provides access to cookies and storage in the top frame. An init object holds a page snapshot with Cart and Customer data.
Apps that read protected customer data such as name, email, phone, or address have to apply for it, and Shopify reviews them against its security guidelines before granting access.
Copy link to headingBrand three surfaces with the Configuration API
The Checkout and Accounts Configuration API replaced both the Checkout Profile and Checkout Branding APIs, and it's available to Shopify Plus merchants only. Shared design tokens carry a palette of up to 20 colors, typography, and corner radii across checkout, customer accounts, and sign-in at once.
Branding doesn't have to be uniform, though. Surface-specific overrides restyle logos, colors, and sections per surface, and a store can vary branding by market.
Copy link to headingWhen to use Shopify Checkout Extensibility on a headless storefront
Component choice depends more on the store’s plan and what must survive the redirect than on what the team would prefer to build.
Copy link to headingAdd loyalty or upsell blocks below Plus
Stores on Basic and above can add extensions to the thank-you and order-status pages. A store without Plus can use those pages for loyalty point balances or post-purchase upsells, even though the information, shipping, and payment steps stay locked. Those two pages are where non-Plus interface work has to happen.
Copy link to headingMove discount and delivery logic into Functions
Discount, delivery, or payment logic still written for Shopify Scripts has no execution path left. Custom-app Functions are Plus-only, though a public App Store app shipping Functions runs on any plan. A Basic or Advanced store reaches cart validation that way without building an app in-house.
Copy link to headingRoute conversion events through a Custom Web Pixel
Ad platforms now receive checkout_completed and other customer events through a Custom Web Pixel, since the Additional Scripts field stopped firing on every plan. A store whose conversion tracking went quiet after one of those sunset dates is usually missing this pixel rather than anything on the storefront.
Copy link to headingRecognize when the framework isn't the answer
A requirement that needs the checkout page itself has no path inside the framework. Redesigning it around what the sandbox allows is the only route forward, since Shopify withdrew those capabilities deliberately rather than deferring them.
Copy link to headingHow Vercel supports the storefront side of Shopify Checkout Extensibility
The storefront still owns speed, personalization, and session state right up to the moment the redirect fires. Each of those shapes what a buyer carries into a checkout the team no longer controls.
Copy link to headingKeep analytics continuous across the checkout subdomain
Once the browser crosses from the storefront's domain to Shopify's checkout, analytics sessions lose context because they now span two properties. Continuity comes from instrumenting the storefront and the checkout as separate surfaces.
Purchase tracking belongs in a Custom Web Pixel rather than in URL-based conversion goals that assume a single domain. Urchin Tracking Module (UTM) parameters need the same treatment, since they don't carry across the boundary on their own.
Copy link to headingPropagate consent with a shared root domain
Shopify's Customer Privacy API carries a buyer's consent choice into checkout only when both properties share a root domain. A storefront on store.com with checkout on checkout.store.com honors that choice, while the same storefront pointed at a myshopify.com checkout can't, because the consent cookie can’t be read across unrelated domains.
Getting there is a domain settings change in the Shopify admin, not something the storefront code controls. Installing the Shopify Headless theme handles the other half of the loop, pointing Shopify-hosted checkout order status and email links back at the headless storefront.
Copy link to headingPersonalize and revalidate before the redirect fires
The handoff is a browser redirect. In Vercel's commerce template, one Server Action creates the cart and stores its ID in a cookie, while a separate redirectToCheckout() action fetches that cart and passes its checkoutUrl to Next.js's redirect(). Shopify returns that field on the Cart object.
Everything a team shapes happens in the moments before that call. Routing Middleware personalizes by geography or segment at the edge. Incremental Static Regeneration paired with Shopify webhook revalidation keeps catalog data current, with purges landing in every region within 300 ms. That endpoint needs a revalidation secret appended to each webhook URL, because an open one lets any caller force regeneration and drive up cache spend.
Copy link to headingProtect the handoff through peak retail traffic
Cart and redirect routes draw bot traffic in proportion to their value, and checkout-bound paths sit at the top of that list. BotID covers high-value routes like checkout and signup, and across Black Friday Cyber Monday (BFCM) 2025 the Vercel network handled 7.5 billion firewall actions.
Deploys during peak weeks carry their own risk, which Skew Protection removes by pinning Server Actions to the deployment that rendered the page. PAIGE runs Shopify with Next.js on Vercel and recorded a 76% conversion increase alongside 22% more BFCM revenue after migrating.
Copy link to headingTrack the Hydrogen rebuild without expecting the boundary to move
Vercel and Shopify are rebuilding Hydrogen as a framework-agnostic, runtime-agnostic toolkit, previewed at Vercel Ship 26 on June 30, 2026. A Next.js app gains Storefront API access through it without adopting Hydrogen's original opinionated stack.
What the rebuild changes is how a storefront talks to Shopify's APIs. The checkout boundary stays exactly where it is, and no Vercel primitive reaches past it. Checkout UI, payment logic, and the order-status page stay inside Shopify's sandbox whatever the storefront runs on.
Copy link to headingShip a faster checkout handoff on Vercel
The ownership split behind Checkout Extensibility is permanent, and the storefront side of it carries more engineering weight than it did when themes could reach into checkout. A session that arrives at checkout without its source attached is a storefront problem, not a reporting one. Consent that doesn't travel and a cart page that loads slowly belong to the same category. Analytics continuity, consent propagation, and pre-redirect speed all sit upstream of checkoutUrl, which makes them the part of the buying experience a headless team can still design.
How much of that work a team takes on depends on its plan, its traffic profile, and what the checkout funnel already costs it. Vercel covers the storefront half of the boundary:
Routing Middleware: Personalizes checkout-bound traffic by geography or segment at the edge.
Incremental Static Regeneration: Keeps catalog data current through authenticated Shopify webhook revalidation, with purges reaching every region within 300 ms.
BotID: Covers checkout and signup routes against bot traffic through peak retail weeks.
Skew Protection: Pins Server Actions to the deployment that rendered the page, so cart mutations survive a mid-deploy request.
Global Network: Serves the storefront close to the buyer worldwide, which holds pre-redirect latency down regardless of where a session starts.
Start a new project to build the storefront side of that handoff, or browse templates for a headless commerce starting point.
Copy link to headingFrequently asked questions about Shopify Checkout Extensibility
Copy link to headingDoes Shopify Checkout Extensibility work with a headless Next.js storefront on Vercel?
Yes, with one architectural note. Checkout UI Extensions, Shopify Functions, and Web Pixels deploy through Shopify and live on its hosted checkout, not inside the Next.js app. The storefront creates the cart, reads checkoutUrl, and redirects the browser there.
Copy link to headingCan I access the checkout DOM from a Checkout UI Extension?
No. Extensions run in a web worker with no window object and no DOM to reach, and Shopify documents only limited access to global web APIs from inside it. UI renders through Polaris web components instead, under a 64 KB compiled bundle limit.
Copy link to headingWhy do UTM parameters and analytics sessions break at Shopify checkout?
The storefront and Shopify's hosted checkout sit on different domains, so session context doesn't carry across both properties. Campaign parameters stay behind on the storefront URL, which is why a converted session often lands under direct traffic instead of its original source.
Copy link to headingDo Checkout UI Extensions slow down my Next.js storefront?
No. Extensions load and execute on Shopify's hosted checkout, which the browser has already been handed off to. Storefront speed is settled before the redirect, by the rendering, caching, and middleware decisions the Next.js app controls.