Checkout Extensibility replaces checkout.liquid and brings you more stability, security, and better upgradeability \u2013 but with clearly defined technical constraints. The good news: What’s possible works reliably and is future-proof.<\/p>\n\n\n\n
For Swiss Shopify Plus<\/a> merchants (because only Plus provides access to these features), this specifically means: You can selectively extend your checkout, but not customize it arbitrarily. Those who know the limitations plan realistically and save themselves expensive experiments.<\/p>\n\n\n\n If you first want to know what Shopify Checkout Extensibility actually is and when it’s used, check out our earlier article<\/a>.<\/p>\n\n\n\n Checkout Extensions bring stability and update security, but they set clear boundaries. What used to be possible with checkout.liquid is often deliberately excluded today.<\/p>\n\n\n\n In short, Shopify sets a clear framework in which the checkout functions. In return, it runs stable, update-proof, and identically on every device.<\/p>\n\n\n\n For Swiss shops<\/strong>, there aren’t any special limitations that don’t also apply internationally. TWINT has been directly integrated via Shopify Payments since 2025<\/a>, and QR invoices can be integrated via apps. However, you should keep these Switzerland-specific configurations in mind:<\/p>\n\n\n\n The most important local requirements \u2013 VAT display, multilingual content, invoice payment \u2013 are achievable with standard means.<\/p>\n\n\n\n Legal requirements in Swiss e-commerce resemble those of the EU, but aren’t identical. There’s no uniform legal regulation like the EU Consumer Rights Directive.<\/p>\n\n\n\n Important differences from the EU:<\/strong><\/p>\n\n\n\n In practice, this means: Swiss merchants have somewhat more freedom in checkout design, but must carefully check which information is needed for final price, VAT, and contract conclusion.<\/p>\n\n\n\n With Checkout Extensibility, much of what was once solved directly in code shifts into the app sphere. This sounds convenient but quickly leads to dependencies and ongoing costs.<\/p>\n\n\n\n Many requirements \u2013 like additional input fields, special terms checkboxes, or B2B logic \u2013 can now only be implemented via third-party apps.<\/p>\n\n\n\n Typical cost traps:<\/strong><\/p>\n\n\n\n Add to this that multiple checkout apps can block each other or slow loading time.<\/p>\n\n\n\n Especially for shops with individual checkout flows, a careful review is worthwhile: Which functions are truly business-critical? Sometimes a Function or clever workaround via the theme is enough.<\/p>\n\n\n\n The strategic combination of native features, targeted apps, and custom developments saves money long-term.<\/p>\n\n\n\n You can’t really speak of a true “migration” anymore \u2013 checkout.liquid is history. Since 2024, Shopify no longer picks up individual checkout customizations from the old Liquid architecture.<\/p>\n\n\n\n Even if the code is still present, it won’t be executed at checkout. For merchants, this means: There’s nothing to actively migrate \u2013 old customizations simply don’t work anymore.<\/p>\n\n\n\n Our experience:<\/strong> Many merchants had poorly documented old checkout customizations. Catching up on an overview saves a lot of effort in rebuilding and prevents important features from being overlooked.<\/p>\n\n\n\n Early testing is crucial. Many merchants only notice after weeks that old validations, discounts, or shipping notices are missing \u2013 then the damage is often already done.<\/p>\n\n\n\n Anyone wanting to successfully deploy Checkout Extensibility should plan realistically from the start.<\/p>\n\n\n\n The following points have proven decisive:<\/strong><\/p>\n\n\n\n Shopify is investing massively in Checkout Extensibility<\/strong> \u2013 and it shows. Since 2023, new API extensions, UI components, and Functions types have been added almost monthly.<\/p>\n\n\n\n The trend is clear: more flexibility, but within clear boundaries.<\/p>\n\n\n\n Shopify is working on:<\/strong><\/p>\n\n\n\n Long-term, checkout will become a modular platform: Merchants add functions like building blocks instead of developing them themselves. This increases update security and reduces maintenance costs.<\/p>\n\n\n\n The future is clearly API- and component-based. Those who accept this early and restructure their processes accordingly benefit from more stability and lower operating costs.<\/p>\n\n\n\n Checkout Extensibility is a solid, future-proof solution \u2013 but not a silver bullet. Those who know and accept the technical limitations plan realistically and save themselves expensive experiments.<\/p>\n\n\n\nThe Hard Technical Limits \u2013 What Really Doesn’t Work<\/strong><\/h2>\n\n\n\n
\n
Swiss Requirements in Checkout<\/strong><\/h2>\n\n\n\n
\n
Compliance and Legal Requirements<\/strong><\/h2>\n\n\n\n
\n
App Dependency and Its Cost Traps<\/strong><\/h2>\n\n\n\n
\n
Migration from checkout.liquid \u2013 What You Need to Know<\/strong><\/h2>\n\n\n\n
Best Practices from Agency Experience<\/strong><\/h2>\n\n\n\n
\n
The Future of Checkout Extensibility<\/strong><\/h2>\n\n\n\n
\n
Conclusion: Realistic Expectations Lead to Success<\/strong><\/h2>\n\n\n\n