Shopify Plus checkout extensibility
checkout.liquid is gone, and with it every hand-edited checkout template on the platform. What replaced it is narrower on purpose: a set of defined extension points that Shopify can upgrade underneath you without breaking anything. The work is no longer writing the checkout: it is expressing what you need within those points, and knowing which needs genuinely cannot be met there before you build around them.
Nothing to re-do next release
Extensions run against a versioned API. When Shopify ships a checkout change, supported extension points come with it instead of silently breaking the way a forked template did.
Checkout, Thank You and Order Status
The three post-cart surfaces share an extension model, so a rule written once behaves the same in all of them rather than being reimplemented per page.
A clear line around what is possible
Some requirements the extension points cannot express. Finding that out during scoping is cheap; finding out four weeks in is not.
What actually gets built
Checkout UI Extensions are the main instrument: small components rendered by Shopify at defined targets in the checkout, written in React or plain JavaScript and executed in a sandbox that has no access to the surrounding page. Delivery notes, gift messaging, B2B purchase order fields, age or licence confirmation, subscription summaries and upsell blocks all fit this shape.
The Branding API handles the parts that used to be CSS: colour roles, typography, corner radii, button treatments and form field styling, set as structured values rather than selectors. It is a smaller surface than a stylesheet, and the trade for that is that it keeps working when the underlying markup changes.
Validation is its own extension type. A cart-level rule, minimum order value for a customer group, a restricted-postcode block, a per-item quantity cap, runs server-side as part of the checkout, which is the only place a rule can run and actually be enforced. A client-side check is a hint; this is the enforcement.
The part most scopes get wrong
The extension points are a defined list. A requirement either maps onto one or it does not, and no amount of engineering effort changes which. The reflex when something does not fit is to reach for an app embed or a workaround somewhere adjacent, and that is usually where checkouts start to feel held together.
So the first piece of work on any checkout engagement is a mapping exercise: every requirement against the extension point that would serve it, and an explicit list of the ones with no answer. For those, the options are to change the requirement, move it out of checkout entirely, or accept it will not happen. Presenting that list is more useful than quietly building the third-best version of it.
Where this leaves your theme developer
Checkout extensions are app-hosted, not theme-hosted. They live in a Shopify app, are versioned and deployed with the Shopify CLI, and can be rolled back independently of the storefront. That is a genuine operational improvement, checkout changes stop being coupled to theme releases, but it does mean checkout work is app development, and needs the deployment discipline that implies.
The handover reflects that: source in your repository or mine, the app in your Partner organisation, deploys documented, and a walkthrough recorded so whoever holds it next is not reverse-engineering it.
Is this the right engagement?
A good fit
- Shopify Plus stores that had checkout.liquid customisations and need them back
- B2B and wholesale flows needing purchase orders, approvals or customer-group rules at checkout
- Regulated categories needing enforced verification before an order completes
- Teams who want checkout deployable independently of the theme
Not a fit
- Non-Plus stores: checkout UI extensibility is a Plus capability
- Rebuilding checkout as a fully custom page outside Shopify
- Cart and product page work, which is theme development, not checkout
Common questions
Can I still edit checkout.liquid?
No. Shopify has fully sunset checkout.liquid. Checkout Extensibility, UI extensions, the Branding API, Functions and validation, is the supported path, and it is the only one that survives platform upgrades.
Do checkout extensions slow the checkout down?
They run in a sandboxed worker rather than on the main thread, so they do not block checkout rendering the way an injected script could. They are not free, though: each one is work the browser does. Scoping which extensions genuinely earn their place is part of the engagement.
What if my requirement does not map to an extension point?
You get told during scoping, in writing, before anyone commits to a timeline. Then we decide together whether to change the requirement, move it elsewhere in the journey, or drop it. That is a better outcome than a workaround that becomes someone else's problem in six months.
Start with the diagnosis
Send me your store and I will record a 20-minute walkthrough of what I would change and why. No call required, and nothing to unsubscribe from afterwards.