For years, Plus merchants customised checkout by editing checkout.liquid — dropping in scripts, custom fields and layout tweaks wherever they liked. That era is over. Shopify has deprecated checkout.liquid in favour of checkout extensibility: a supported, sandboxed set of tools that survive upgrades instead of breaking on them. If you still have checkout.liquid customisations, they need rebuilding — and the new model is genuinely better once you understand its shape.
Why Shopify killed checkout.liquid
Free-form Liquid editing of checkout was powerful and dangerous. Custom code could slow checkout, break on Shopify updates, introduce security and PCI issues, and block platform improvements like Shop Pay optimisations. Every store's checkout was a bespoke, fragile thing. The new model trades unlimited freedom for stability: you extend checkout only at defined points, and those extensions keep working as the platform evolves.
The four pieces of checkout extensibility
1. Checkout UI extensions
Small React-based components that render at defined slots in checkout — add a gift message field, trust badges, delivery instructions, custom line-item messaging, or an upsell. They run sandboxed, so they can't slow or break the core checkout. This replaces most of what people used to inject via Liquid.
2. Shopify Functions
Server-side logic that customises checkout behaviour: custom discounts, dynamic shipping and payment method rules, cart validation, and line-item transforms. Functions run fast on Shopify's infrastructure and are how you express business rules that used to live in scripts or apps — e.g. "hide express shipping for hazardous items" or "apply a negotiated discount for a specific customer."
3. Branding & the checkout editor
Colours, fonts, logo and layout now come from the checkout editor and the branding API — visual customisation without touching code. Much of what once needed Liquid is now a settings change.
4. Web Pixels
Analytics and marketing tags load through the sandboxed Web Pixels API instead of raw script tags in checkout. Your GA4, Meta and other pixels fire from a controlled environment that can't interfere with checkout itself.
The mental shift: you no longer edit the checkout. You extend it at defined points. Less freedom, far more stability — and your customisations stop breaking every time Shopify ships.
Migrating off checkout.liquid
The practical steps for a Plus store:
- Inventory the customisations. List everything
checkout.liquidcurrently does — fields, scripts, tags, layout, logic. You can't rebuild what you haven't catalogued. - Sort each item into UI extension, Function, branding setting, or Web Pixel. A few things won't have a home — those are worth questioning rather than forcing.
- Rebuild and test on a preview. Checkout is where revenue happens; test thoroughly across devices, discounts, and payment methods before switching.
- Move analytics to Web Pixels so your tracking keeps working under the new model.
What you get in return
Beyond "it keeps working": checkout extensions are faster and safer than injected scripts, they benefit from Shopify's ongoing checkout and Shop Pay improvements automatically, and they're a maintained surface — which ties back to the wider build-vs-buy question, since a lot of checkout behaviour is now expressed as small extensions or Functions rather than heavy apps.
The honest summary
If your store still leans on checkout.liquid, treat the migration as non-optional and do it deliberately — inventory first, then rebuild each piece the supported way. The result is a checkout that's customised where it matters and stable everywhere else, instead of a fragile one-off that broke on every platform update. It's more constrained, and that constraint is the point.