Published October 12, 2026

Checkout Extensibility Explained: The Blocks That Replaced checkout.liquid

What actually replaced the old checkout file

For years, Plus stores customized checkout by editing checkout.liquid, a theme file with unusual power and a matching talent for breaking at upgrade time. Checkout extensibility is the replacement architecture: a checkout editor where merchants place apps and blocks into defined slots, UI extensions that render inside those slots, Shopify Functions running the logic underneath, and branding controls that handle the legitimate 90 percent of what most liquid edits were doing: logos, colors, fonts, and a banner someone in marketing cared about.

The honest trade is freedom for stability. You cannot put anything anywhere anymore. You also cannot take checkout down with a stray tag the night before a drop, and checkout now inherits platform upgrades instead of fossilizing around your 2023 edits. Operators who lived through a liquid checkout rotting in place will take that trade and not look back.

What the slots let you do, in operator terms

The useful inventory: add a block for a trust message or a delivery note, a field for gift instructions or a delivery date within the rules of the surface, post purchase offers after payment, address and validation logic that catches a bad postal code before it becomes a failed delivery, and payment or shipping methods hidden or reordered by Function based on what is in the cart. Upsell blocks exist too, and the discipline with those is load order and restraint: checkout is the one page where the customer has already decided, and every added widget is a small withdrawal from that decision.

Standard plans get the branding layer and a limited set of app blocks. Plus unlocks the deeper editor and more surfaces. That gating is the commercial reality, and it means a standard plan store should spend its checkout effort on the things still fully in its control: what its apps inject, what its policies say, and how fast the page loads before checkout even starts.

The migration audit, in the order we run it

First, inventory what the old checkout actually did, not what the file contains. Half of most checkout.liquid files is archaeology: a pixel for an agency relationship that ended years ago, a banner for a promotion two summers gone, a script whose vendor was acquired and shut down. Delete on evidence, not on vibes: check whether each element fired, earned, or was even visible in the last ninety days.

Second, sort the survivors into the three replacement buckets: branding settings, an app or block in a slot, a Function for logic. Third, rebuild in the draft checkout editor and run test orders against every payment and shipping combination you actually offer, including the embarrassing ones, gift cards, a local pickup order, a discount stack. Checkout bugs hide in combinations, not in the happy path.

What good looks like now

A good extensible checkout is boring to describe: brand matched, one clear delivery story, no surprise fields, validation that catches real errors without scolding, and tracking that still attributes orders after the migration. That last item is where migrations quietly bleed. Pixels and conversion events move to the new surfaces, customer events and app pixels in the current model, and the store that forgets to verify them discovers the gap in its ad data a month later, priced in wasted spend.

So the last step of any checkout change is a data check within the first days, not the first month: orders attributed, events firing, discount combinations behaving. The platform gave operators a checkout that is harder to break. It did not give them one that checks its own homework, and the homework is now the whole job.

Frequently asked questions

Is checkout.liquid still usable?

Shopify has retired checkout.liquid as the customization path in favor of checkout extensibility, with the information, shipping, and payment pages moved to the new editor based system. Stores should treat any remaining liquid dependency as a migration task with a platform deadline, and rebuild the needed behavior with branding settings, blocks, and Functions.

What can standard Shopify plans customize at checkout?

Branding: logo, colors, fonts, and related presentation, plus a limited set of app provided blocks where apps support them. The full checkout editor with deeper placement and more extension surfaces is a Plus capability. Standard stores get the most from auditing their apps and policies rather than chasing layout control they do not have.

Can I add a custom field at checkout with extensibility?

Within the supported surfaces, yes: UI extensions can add fields such as delivery instructions or gift messages in defined slots, and the data is stored with the order in supported ways. What you cannot do is insert arbitrary fields anywhere in the flow or change the core checkout steps, which is the deliberate constraint of the system.

Will migrating to checkout extensibility break my tracking?

It can if you let it. Tracking moves to customer events and app pixels under the current model, and legacy scripts pasted into checkout or the old additional scripts area need to be accounted for. Rebuild the events, then verify attribution and firing on real orders in the first days after the switch, while the gap is still cheap.