Checkout extensibility on Shopify Plus: what replaced checkout.liquid and what breaks

What changed and when

For years, the thing you were paying Plus for was access to checkout.liquid, a theme file that let a developer change anything on the checkout pages. It was powerful and it was fragile: every store’s checkout was a one-off, apps injected script tags into it, and Shopify could not change checkout without breaking someone.

Checkout extensibility is the replacement. Instead of editing the page, you add to it through fixed extension points, and Shopify owns the page. Here are the dates as Shopify’s documentation states them on October 17, 2026.

The three building blocks

UI extensions are what customers see. An app, public or custom, declares a block and the merchant places it in the checkout and accounts editor at a target: a banner above the shipping methods, a field below the address, a product offer on the thank you page. Shopify renders it inside checkout with its own components, so it inherits the store’s branding and cannot break the page. Checkout UI extensions for the information, shipping and payment steps are Plus-only; thank you, order status and customer account extensions work on every plan.

Shopify Functions are the rules. A Function is a small program, written in Rust or JavaScript and compiled to WebAssembly, that Shopify runs at a fixed point: when it calculates discounts, when it lists delivery options, when it lists payment methods, when it validates a cart, when it routes an order to a location, when it builds a bundle. It does not render anything. Any plan can use public apps built with Functions; only Plus can run a custom app containing Functions, which is what you need when no app does your rule.

Branding and configuration is the look. On every plan the checkout and accounts editor sets logo, colors, fonts and layout. On Plus, the Checkout And Accounts Configuration API, which replaced the Checkout Branding API in version 2026-04, exposes the full design system for checkout, customer accounts and sign-in, and the same branding can be varied per market.

Two more pieces round it out. Web pixels replace tracking scripts and run on every plan. Post-purchase extensions handle the offer page between payment and the thank you page, on every plan.

What maps to what

This is the table we fill in for every store in an audit. The left column is what a Plus store typically had on checkout.liquid and Scripts; the right column is what it becomes.

What breaks, honestly

Most customizations map cleanly. A few don’t, and it is better to know before the upgrade than after.

Anything that read or wrote the page DOM. A script that moved the discount field above the address, or injected a countdown timer, or rewrote the order summary. Extensions render at fixed targets and cannot reach outside their block. The usual answer is a different design that uses a target Shopify offers.

Anything that changed an order from inside checkout. Shopify’s documentation for the thank you and order status pages says there is no support for APIs that directly mutate an order from a UI extension. Order edits move to Flow, a backend app or the admin after the order exists.

Logic that needed outside data at checkout time. Functions run inside Shopify with no network access and strict resource limits, so a discount rule that looked up a customer’s balance in your ERP on every cart change has to be redesigned: cache the balance on the customer as a metafield, then let the Function read that.

Checkout styling that depended on CSS. The branding configuration is broad, with colors, typography, corner radii, spacing and per-section settings, but it is a design system and not a stylesheet. A pixel-exact copy of an old checkout is not the goal; a checkout that matches the brand and converts is.

The upside of each of these constraints is the same: Shopify can keep improving checkout, Shop Pay and one-page checkout under your customizations without breaking them, which is what used to happen several times a year.

The upgrade path

Shopify’s documentation recommends planning the in-checkout upgrade and the thank you and order status upgrade together, and if that is not possible, doing in-checkout first. Here is how we run it inside a Plus upgrade project.

1. Inventory. Pull the upgrade guide from Settings > Checkout, export every Script, and list every app that touches checkout. Each line gets a row in the mapping table above.
2. Decide build or buy. For each row, a public app from the App Store, a custom app with its own extensions and Functions, or drop it. Shopify adds checkout apps to the App Store regularly, so a rule that needed custom code two years ago may be an app today.
3. Build on a draft configuration. The checkout and accounts editor supports active and draft configurations. Everything is placed and tested on the draft while the live checkout keeps trading.
4. Test with money. Real orders through every payment method, every shipping rule, every discount, on desktop and phone, with Shop Pay and without. Validation Functions get negative tests: the cart that should be blocked, is.
5. Publish and watch. Switch the draft live, then compare checkout completion rate and average order value against the baseline for 90 days. A Function that silently hides a payment method for a segment of customers shows up here, not in testing.

The checkout work is usually the largest single item in an upgrade quote, which is why we scope it in the readiness audit. The when to upgrade guide covers whether you need Plus for it at all, and the cost page covers what the project includes.