What Checkout Extensibility replaced, and why
Shopify deprecated checkout.liquid for all Shopify Plus merchants in August 2024. The old model let agencies modify the checkout HTML, CSS, and Liquid logic directly. It was flexible but created problems: broken upgrades when Shopify pushed platform changes, inconsistent mobile behaviour, PCI-compliance risk, and slow performance from accumulated custom code.
Checkout Extensibility is the replacement. It's a constrained, well-defined API for customising checkout through three mechanisms: Shopify Functions (server-side logic), UI Extensions (visual customisation at specific extension points), and Web Pixels (analytics). Each has its own purpose, its own scope, and its own limits. The tradeoff is explicit: you lose the old "modify anything" flexibility but gain a checkout that upgrades automatically, works on every device, and stays PCI-compliant.
For most Nordic merchants, the tradeoff is worth it. For merchants with deeply custom checkout logic, the migration required real work.
Shopify Functions, server-side logic
Functions are where the business logic lives. They're small server-side programs written in Rust, JavaScript, or another WASM-targeting language. They run at specific points in the order lifecycle and return structured data that Shopify acts on.
The main Function types relevant to checkout:
Discount Functions. Replace the old Scripts. Handle custom discount logic like tiered pricing, B2B customer-specific discounts, bundle discounts, and time-based promotions. The input is the cart and customer data. The output is a discount structure that Shopify applies.
Payment Customisation Functions. Hide, show, reorder, or rename payment methods based on cart contents, customer, or order attributes. Common uses: showing Klarna only above certain cart values, hiding B2B invoice payment for consumer accounts, showing Swish only for Swedish customers.
Delivery Customisation Functions. Same mechanism for shipping methods. Hide home delivery for specific postcodes, rename shipping options based on cart contents, reorder delivery options for specific customer groups.
Cart Transform Functions. Modify cart contents at checkout. Used for bundles that expand into component products, configurable products with computed pricing, or cart-level changes that can't be expressed as discounts.
Functions are fast (sub-100ms target), composable (you can run multiple), and version-controlled. They replace a lot of what used to live in checkout.liquid or Scripts, in a structured way.
UI Extensions, visual customisation
UI Extensions let you add or modify UI elements at predefined extension points in the checkout flow. Extension points include the checkout header, the cart summary, the delivery address block, the payment section, and the order confirmation page.
What UI Extensions can do:
- Add custom form fields (organisation number, delivery instructions, gift message)
- Add custom content blocks (trust badges, promotional banners, information blocks)
- Add confirmation or warning messages based on cart state
- Add post-purchase upsells or cross-sells
What UI Extensions cannot do:
- Move or remove core checkout elements
- Restyle the checkout beyond the available theming controls
- Interrupt the core payment flow
- Modify the HTML structure of checkout directly
The extension points are fixed. If Shopify has not defined an extension point where you want to customise, you cannot customise there. This is the tradeoff for upgrade safety.
Web Pixels, analytics and tracking
Web Pixels replace the old custom scripts injected into checkout for analytics. They run in a sandboxed environment with access to a standardised event stream (page views, cart updates, purchase completions, payment events).
Common uses: Google Analytics 4, Klaviyo, Meta Pixel, TikTok Pixel, custom server-side tracking. The sandbox prevents pixels from interfering with the checkout experience or accessing customer data outside their permission scope.
For most merchants, the Web Pixel setup is straightforward through the Customer Events section of Shopify admin. For complex multi-pixel setups with custom event mapping, a small amount of additional configuration is needed.
Nordic merchant edge cases
Nordic merchants frequently need customisation that pushes the extension model's limits. Common scenarios and how they work:
Organisation number validation for B2B. Swedish orgnr, Norwegian orgnr, Danish CVR, Finnish Y-tunnus. A UI Extension can add the field and validate format client-side. A Function can validate against external registry data post-submission. Works cleanly in the extension model.
ERP-driven customer-specific pricing. B2B customers need to see their negotiated prices at checkout. The pricing needs to come from the ERP via the integration layer. A Discount Function receives the customer context and applies the correct pricing tier. See our Shopify ERP integration guide for how the ERP side connects.
Swish integration with conditional display. Swish should appear for Swedish customers. A Payment Customisation Function hides Swish for non-SE markets. Works cleanly. See our Shopify Markets guide for multi-market payment display logic.
Klarna-specific checkout overrides. Klarna has specific flows for invoice, part-payment, and direct payment that differ by market. Shopify's Klarna integration handles the main flows. Market-specific payment display is handled by Payment Customisation Functions. Custom Klarna-specific UI is more constrained and sometimes requires the Klarna Checkout component rather than Shopify's native checkout.
Custom B2B approval workflows. B2B orders that require manager approval before payment capture. The checkout itself places the order; the approval workflow runs after via custom app logic connected through the Admin API. The checkout cannot be paused mid-flow, which is an architectural constraint to work around rather than through.
Invoice payment with credit check. Faktura for B2B with automatic credit check. Payment Customisation Function can show invoice only for customers with approved credit (customer metafield populated from ERP). The credit check itself happens outside checkout, either at customer signup or via scheduled jobs from the ERP.
Age verification for restricted products. UI Extension adds the verification field and blocks submission without confirmation. Server-side validation via a Function for audit trail.
What the old customisation model cannot be rebuilt
Some customisations from the checkout.liquid era do not have clean equivalents in Checkout Extensibility:
Deep visual overhauls. If your previous checkout was a visually distinctive experience that diverged from Shopify's default, the new model gives you theming but not layout freedom. The closest equivalent is a headless checkout, which is a different architectural decision. See our Shopify headless guide for when that fits.
Custom step flows. The old model let you add custom pre-checkout or inter-step logic that interrupted the normal flow. The new model has fixed checkout steps. Logic that needs to run between steps happens through Functions (which don't pause the flow) or through extension UI (which runs alongside the flow).
Server-side cart manipulation via Liquid. The old pattern of rewriting cart contents via Liquid logic is replaced by Cart Transform Functions. The capability is similar but the mental model is different.
Migration from checkout.liquid, practical approach
If you're still on checkout.liquid (which should not be the case for Shopify Plus merchants as of August 2024), the migration approach is:
Inventory current customisations. List every non-default behaviour in the current checkout. Categorise each as: extension-compatible, needs reworking, or no longer needed.
Map to extension types. For each extension-compatible customisation, identify whether it belongs as a Function, UI Extension, or Web Pixel. Some customisations need combinations.
Rebuild in extension model. Start with Payment Customisation Functions (usually the simplest), then Discount Functions, then UI Extensions. Use Shopify's CLI and development store for iteration.
Test across devices. The new model behaves consistently on mobile and desktop, which is an improvement. But any custom logic still needs device testing.
Phased cutover. Run the new checkout on a subset of traffic first. Monitor conversion, error rates, and support queries. Full cutover once the new setup is stable.
Timeline and cost
Building Checkout Extensibility customisations on a new Shopify Plus project typically adds 2 to 4 weeks and €8,000 to €25,000 to the project, depending on how many Functions and UI Extensions are needed. Migrating an existing checkout.liquid customisation to the extension model runs €15,000 to €50,000 depending on the complexity of the original customisation. For deep B2B flows with ERP-driven pricing, payment customisation, and B2B approval logic, budgets from €30,000 upward are realistic.
Contact us for a scoping conversation on your specific checkout customisation needs.