Checkout Extensibility

Why it matters

The old model let a developer rewrite checkout as a Liquid file, and the cost of that freedom was that Shopify could not improve checkout without breaking those stores. Every merchant with a customised checkout.liquid was frozen at the version they had modified, missing accelerated wallets, one-page checkout, and each conversion improvement shipped since.

The new model inverts the deal. Customisation happens at defined extension points, and Shopify upgrades everything around them. A store on Extensibility gets checkout improvements automatically instead of paying a developer to reapply its changes.

For merchants who lost customisations in the transition, the real question is usually whether the customisation was earning anything. A surprising share of legacy checkout code existed to add trust badges.

How it works on Shopify

Three mechanisms cover most requirements.

Checkout UI extensions add interface elements at published extension points — a delivery instructions field, a gift message, a custom banner, an upsell block. They run in a sandboxed frame with a component library that inherits the store's branding.

Shopify Functions handle logic: which delivery and payment methods appear, how discounts apply, whether a cart is valid to proceed.

The branding API covers appearance — colours, typography, corner styles, logo — configured centrally rather than through overridden CSS.

Around those sit checkout profiles, letting a store keep different checkout configurations and test one against another.

The important boundary: extension points are a published set. If the requirement does not map to one, the answer is that it cannot be built rather than that it needs a workaround, and design should account for that early.

Common mistakes

• Scoping a design against the old model. A checkout mockup that assumes arbitrary layout control produces a build that cannot be delivered. Design within the extension points.
• Recreating what Shopify already does. Trust badges, express wallets, and address autocomplete are largely handled. Much legacy customisation is now redundant.
• Overloading checkout with extensions. Every extension adds work to the page that converts best. The bar for adding one should be higher than for any other page.
• Ignoring the profile system. Changes pushed straight to the live profile skip the safest testing mechanism available here.
• Leaving it until the deadline. Stores that delayed the move off checkout.liquid discovered its end of life the hard way. The same pattern repeats with each deprecation.

When you need help

The useful outside work starts with an audit: listing every existing checkout customisation, what it was for, and whether it maps to an extension point, converts to a Function, or should simply be dropped. That list usually shortens considerably.

The build itself is worth handing over when it touches money or method availability, for the same reason as any Function work — the logic runs on every order, and a mistake is a revenue incident rather than a visual bug. Interface-only extensions are more forgiving.