For a decade, the way a Shopify Plus merchant changed its checkout was to open a file called checkout.liquid and edit it. That file gave developers control over the entire page: the layout, the scripts that fired on it, the tracking pixels, the upsells, the custom fields, everything. That era is over. Shopify retired checkout.liquid in stages, replaced it with a set of sandboxed building blocks called checkout extensibility, and in the process changed both what a store can do at checkout and who has to pay for it.
This guide walks through what replaced checkout.liquid, what the new tools can and cannot do, which Shopify plan unlocks which pieces, how a migration actually goes, and what a realistic budget looks like. It is written for store owners, operators, and the developers who serve them, not for people who want to be sold on the platform. Where a figure comes from Shopify itself, we say so, and pricing and platform rules change often enough that you should verify current details on Shopify’s developer documentation before committing money.
In short
- checkout.liquid is gone. Shopify deprecated the file in stages, first for the information, shipping, and payment steps, then for the Thank you and Order status pages, and finally as part of the platform-wide move to the new checkout. Stores that never migrated were upgraded automatically.
- Two tools replaced it. Checkout UI extensions handle anything visible (banners, custom fields, upsells, trust badges), and Shopify Functions handle backend logic (discounts, shipping rules, payment ordering, validation). Tracking moved to the Web Pixels API.
- The sandbox is the point. Extensions run in isolated workers with no direct access to the page’s DOM. That is why Shopify says the new checkout is faster and more reliable, and also why some old customizations simply cannot be rebuilt.
- Plus is still the gate for the checkout steps themselves. According to Shopify’s documentation, UI extensions on the information, shipping, and payment pages and the checkout branding API require Shopify Plus. All plans get extensions on the Thank you and Order status pages, and all plans can use Functions delivered through public apps.
- Costs range from near zero to well into five figures. A store that installs a couple of App Store apps spends tens of dollars a month. A store that rebuilds a bespoke checkout.liquid setup with custom extensions and Functions on Plus is looking at the Plus subscription plus agency or in-house development time.
Why checkout.liquid was retired
The official reason Shopify gave for retiring checkout.liquid was reliability and speed, and it is a credible reason. A Liquid template that any developer could rewrite meant that any developer could also break checkout, inject slow third-party scripts, or accidentally strip a required field. Shopify could not upgrade the checkout without risking every custom template on the platform, and the company had been signaling for years that it wanted a checkout it could improve centrally and ship to every store at once.
The commercial reason sits alongside it. Shopify markets its checkout as a conversion asset, citing a Shopify-commissioned study that found it converted about 15 percent better on average than competing platforms. Those are vendor claims, but the strategy behind them is clear: a single, tightly controlled checkout is easier to optimize and easier to plug into Shop Pay and the growing list of agentic and social checkout surfaces.
The deprecation ran on a published timeline. Shopify’s developer changelog set August 13, 2024 as the date checkout.liquid stopped being supported for the information, shipping, and payment pages on Plus stores, and August 28, 2025 as the deadline for the Thank you and Order status pages. Stores that had not migrated by those dates were moved onto the new checkout by Shopify, which is the origin of the “cutover” language that circulated through the merchant community last year. If you are reading this on a store that still has an old customization somewhere, it is worth understanding that the file is not coming back, and that the broader question of which e-commerce platform fits your store now has to be answered with the new checkout model in mind.
What actually broke for merchants
Most of the noise around the cutover was not about the checkout steps at all. It was about the Additional Scripts box on the Order status page, where a large share of merchants had pasted Google Ads, Meta, and affiliate tags over the years. That box was retired along with checkout.liquid, and anything in it that was not moved to the Web Pixels API stopped firing. The visible symptom was a gap between orders in the Shopify admin and conversions in the ad platforms, not a drop in orders. Our earlier analysis of why the Shopify cutover broke measurement rather than checkout covers that dynamic in detail.
Checkout UI extensions: what they can and cannot do
Checkout UI extensions are the visible half of checkout extensibility. An extension is a small app component, written in JavaScript or React against Shopify’s UI component library, that renders into a named slot on the checkout page. Shopify calls these slots extension targets, and there are dozens of them: before or after the delivery address, before or after the shipping method list, near the order summary, on the Thank you page, on the Order status page, and a few block targets that the merchant can drag anywhere the checkout editor allows.
The key design decision is that the extension never touches the checkout’s own DOM. It runs in a sandboxed web worker, talks to the checkout through a defined API, and renders only Shopify’s components, which the checkout then styles to match the store’s branding. That is a big shift from checkout.liquid, where a developer wrote raw HTML and CSS. The upside is that Shopify can change the checkout’s internals without breaking extensions. The downside is that “make the checkout look like our Figma file” is no longer a request a developer can fully honor.
What extensions can do
Within those rules, the range is wider than most merchants assume. Extensions can read the cart, the buyer’s identity if logged in, the shipping address as it is typed, the selected delivery option, and a growing set of shop and buyer attributes. They can write to cart attributes and metafields, which is how custom fields like gift messages, delivery instructions, or age confirmations get captured. They can render banners, text, images, checkboxes, choice lists, date pickers, and product offers with an add-to-cart button, which is how in-checkout upsells work now.
They can also block progress. A buyer journey intercept lets an extension halt the move to the next step with a message, which covers cases like “you must accept these terms” or “this item cannot ship to a PO box.” On the Thank you and Order status pages, extensions can show surveys, loyalty enrollment, tracking widgets, and post-purchase offers. Third-party apps use exactly the same mechanism: a duties calculator that appears at checkout, like the one covered in our piece on FedEx guaranteeing duties at Shopify checkout, is a checkout UI extension with a Function behind it.
What extensions cannot do
The list of hard limits is short but consequential. Extensions cannot inject arbitrary JavaScript or CSS into the page, cannot move or hide Shopify’s own fields, cannot read or touch the payment fields, and cannot make calls to third-party servers unless the app declares those network domains and the buyer’s data handling is consented. They also cannot change the fundamental page structure: one-page versus three-page checkout is a Shopify setting, not something an extension controls.
A related limit is visual. Layout and styling of the checkout as a whole are controlled by the checkout branding API and the checkout editor, both of which expose a fixed set of tokens: colors, typography, corner radius, header layout, and so on. An extension inherits those tokens. If a legacy checkout.liquid setup relied on a custom two-column layout with a sticky order summary and a bespoke progress bar, the honest answer is that it will not be rebuilt as-is. The theme choices that drive conversion on the storefront stop at the checkout boundary; from the cart onward, the checkout editor is the design tool.
Where tracking went
Analytics and marketing tags are the third category, and they have their own tool. The Web Pixels API lets an app or a custom pixel subscribe to standard checkout events (checkout started, payment info submitted, checkout completed, and so on) and forward them to any destination. Custom pixels run in a sandboxed iframe with a restricted API, so the days of dropping a raw script tag into the checkout are over. This is the migration that caught the most merchants out, because it is invisible until the ad platform reports start diverging.
Shopify Functions for discounts, shipping and payments
Shopify Functions are the backend half. A Function is a small program, written in Rust or JavaScript and compiled to WebAssembly, that Shopify runs at a specific point in the checkout to change how a piece of logic behaves. Functions do not render anything. They take an input (the cart, the delivery options, the payment methods) and return a set of operations that Shopify applies. Because they run inside Shopify’s infrastructure with tight execution limits, they are fast and they cannot call external services at run time.
The main Function APIs
The list has grown steadily since 2022, and as of Shopify’s current documentation it covers most of the logic that merchants used to script in checkout.liquid or via Shopify Scripts on Plus. The discount API replaced the old Script Editor for product, order, and shipping discounts, and Shopify has since consolidated the three discount classes into a single API. The delivery customization API can hide, rename, reorder, or annotate shipping options based on cart contents or address. The payment customization API can hide, reorder, or rename payment methods, which is how “no cash on delivery over $500” or “show BNPL first for carts over $200” gets implemented.
Beyond those, the cart transform API builds bundles, the cart and checkout validation API rejects carts that break a rule (minimum quantity, one-per-customer limits, restricted regions), and the fulfillment constraints, order routing, and pickup point APIs control where an order is assigned and which pickup options appear. Each of these was a separate app or a Scripts hack a few years ago.
Limits worth knowing before you plan
Functions are deliberately constrained. Shopify documents a maximum compiled size and an instruction-count budget per run, both of which are generous for rule-based logic and hostile to anything that wants to loop over a huge product catalog or call an API. There is no run-time network access at all: a Function that needs external data has to have that data written to metafields ahead of time by the app that owns it. Input is provided through a GraphQL query that the developer declares, and the input size is capped too. None of this stops normal use cases, but it does rule out “call our ERP at checkout to check stock” as a Function. That job belongs to an app pulling data in advance.
One more limit is distribution. Shopify’s documentation draws a line between public apps installed from the App Store and custom apps built for a single store. Functions delivered by public apps run on every plan. Functions inside a custom app, which is how most bespoke agency work is delivered, require the store to be on Shopify Plus. That single rule explains a large share of the “you need Plus for that” conversations merchants end up having.
Plan requirements and where Plus is unavoidable
The plan gating is the part that most directly determines cost, and it is worth stating precisely because it is easy to get wrong. The table below summarizes the position as described in Shopify’s documentation at the time of writing. Shopify changes plan entitlements periodically, so treat it as a map rather than a contract and confirm current entitlements before signing anything.
| Capability | Basic, Shopify, Advanced | Shopify Plus | Notes |
|---|---|---|---|
| UI extensions on Thank you and Order status pages | Yes | Yes | The post-purchase surface is open to all plans |
| UI extensions on information, shipping, payment steps | No | Yes | The core checkout steps remain a Plus feature |
| Checkout branding API (colors, fonts, layout tokens) | Limited, via checkout editor | Full | Non-Plus stores can set basics; the API is Plus |
| Functions via public App Store apps | Yes | Yes | Discounts, shipping rules, payment rules through apps |
| Functions via custom (single-store) apps | No | Yes | The rule that pushes bespoke work onto Plus |
| Web Pixels API (app and custom pixels) | Yes | Yes | Replaces Additional Scripts on every plan |
| Post-purchase extensions (one-click upsell after payment) | Yes, with eligibility rules | Yes | Requires Shopify Payments or supported gateway |
| Checkout Blocks style drag-and-drop apps | Thank you and Order status only | All steps | App capability tracks the plan gating above |
Read across the rows and a pattern appears. Anything after the buyer has paid is available to everyone. Anything that changes the checkout while the buyer is still deciding is either a public-app feature or a Plus feature, the same logic that governed the Plus-only checkout.liquid, translated into the new model. Our breakdown of Shopify pricing across every plan tier puts the subscription numbers next to these entitlements.
When Plus is genuinely unavoidable
There are three situations where a store cannot get what it needs without Plus, and it is useful to name them so that the decision is made on facts rather than on an agency’s preference. The first is any custom UI in the information, shipping, or payment steps: a bespoke gift-wrap selector, a B2B purchase-order field, a custom trust module. The second is any custom Function that a public app does not already provide, for instance a discount rule tied to internal customer segments or a shipping rule that reads proprietary metafields. The third is full checkout branding control through the API, which matters mostly to brands with strict design systems.
If none of those three applies, a store on the Advanced plan can get surprisingly far with public apps on the Thank you and Order status pages plus Functions-based discount and shipping apps from the App Store. The Shopify versus Shopify Plus comparison we published earlier goes through the other reasons a store might upgrade, including B2B, multi-store, and support tier, and checkout extensibility is only one of them.
Migrating an old customised checkout
For stores that still have legacy customizations in their history, or that are moving from another platform where the checkout was fully custom, the migration is less a technical project than an inventory exercise. The failure mode is not that the new tools do not work; it is that nobody wrote down what the old checkout did, so features disappear silently and are noticed by customer service weeks later.
Step one: inventory everything the old checkout did
Start with the code and the Additional Scripts box, but do not stop there. Interview the people who own conversion, customer service, finance, and marketing, and ask each of them what they expect the checkout to do. Common items that surface: a terms checkbox, a delivery date picker, a gift message, a company-and-VAT field, an age gate for restricted products, a free-shipping progress bar, a trust badge row, a specific payment-method order, a shipping rule that hides express for oversized items, and a dozen tracking tags nobody remembers adding. Write every one down with its owner and its business reason.
Step two: map each item to the new tool
Every inventory item goes into one of four buckets: rebuild as a UI extension, rebuild as a Function, rebuild as a web pixel, or retire. Retire is a real option and should be used aggressively. A tag that fed a marketing tool the company stopped paying for in 2023 does not need to be migrated. A custom layout that nobody can prove ever improved conversion does not need to be recreated at agency rates. The exercise usually cuts the list by a third.
For what remains, check the App Store before writing anything. Terms checkboxes, delivery date pickers, gift messages, trust badges, and free-shipping bars all exist as public apps that work on every plan on the Thank you and Order status pages, and on all steps for Plus stores. Custom development is for the items that are genuinely specific to the business.
Step three: rebuild, then cut over in one move
The rebuild happens in a development store or a draft checkout profile, and the cutover is a single publish action in the checkout editor. Because the live profile keeps running while the draft is assembled, the store avoids the half-migrated state where some features exist and others do not.
| Legacy customization | New home | Public app available? | Plan needed if custom-built |
|---|---|---|---|
| Terms and conditions checkbox | UI extension with buyer journey intercept | Yes | Plus (for the payment step) |
| Gift message or delivery instructions | UI extension writing a cart attribute | Yes | Plus |
| Free-shipping progress bar | UI extension reading cart total | Yes | Plus |
| Hide express shipping for oversized items | Delivery customization Function | Yes | Plus (custom app) or any plan (public app) |
| Show BNPL first over a cart threshold | Payment customization Function | Yes | Plus (custom app) or any plan (public app) |
| Tiered volume discount | Discount Function | Yes | Plus (custom app) or any plan (public app) |
| Google Ads and Meta conversion tags | Web pixel (app or custom) | Yes | Any plan |
| Post-purchase one-click upsell | Post-purchase extension | Yes | Any plan, gateway rules apply |
| Custom two-column layout and sticky summary | Not reproducible; use branding tokens | No | Plus for full branding API |
Testing and previewing checkout changes safely
The new model makes testing both easier and more formal. Easier, because a sandboxed extension cannot take down the whole checkout the way a broken Liquid template could. More formal, because there are now specific tools for each stage and skipping them is how avoidable incidents happen.
Developer preview and local testing
Developers build and run extensions locally through the Shopify CLI, which serves the extension into a development store’s checkout with live reload. Development stores can be created with checkout extensibility features enabled, which means a developer does not need a Plus subscription to build for the Plus checkout steps; they only need one to deploy to a live non-development store. Test orders go through Shopify’s test payment gateway, which accepts specific card numbers to simulate success and failure without moving money.
The checkout editor’s draft and preview modes
On the merchant side, the checkout editor lets an operator place extensions, set branding, and preview the result in desktop and mobile views before publishing. Because extensions render Shopify’s own components, what the preview shows is very close to what the buyer will see. The residual risks are the ones the preview cannot show: how the extension behaves with a real address, a real discount stacked on a real shipping rule, and a real payment method. For those, the practical approach is a short list of scripted test purchases run against the draft profile, covering each business rule that the migration inventory produced.
Pixels deserve their own test pass
Tracking is where the least visible failures hide, so it gets its own step. Each custom pixel should be validated by completing a test order and confirming the event arrives at the destination with the right value, currency, and order identifier. Ad platforms’ own debugging tools (Meta’s event testing, Google’s tag debugging) are the right place to check, because they show what the platform received rather than what the browser sent. A pixel that fires but sends a zero value is the classic silent failure.
Performance and conversion impact worth measuring
Shopify’s pitch for the new checkout rests on performance, and there is a reasonable basis for it. A checkout that cannot load arbitrary scripts loads faster and more consistently, and the extensions run off the main thread. Shopify has published its own before-and-after figures for stores that migrated, but those come from the vendor and should be treated as a hypothesis to test on your own store rather than a guarantee.
What to measure and how
The metric that matters is checkout completion rate, measured from checkout started to order placed, split by device and by payment method. It should be measured for a clean period before the migration and a clean period after, with the same promotional calendar and ideally the same traffic mix, which in practice means avoiding a cutover in the weeks around Black Friday. A secondary metric is the time from checkout start to order placed, which captures the friction removed or added by extensions. A third is the share of orders using Shop Pay, since accelerated checkout adoption is where Shopify’s own conversion claims come from.
Measurement itself has to be trustworthy first. If the migration also moved tracking to web pixels, ad-platform reports will show a discontinuity that has nothing to do with buyers. Compare against the Shopify admin’s order count, the source of truth, before concluding that conversion moved.
Where extensions can hurt
It is possible to make the new checkout worse. Six apps competing for the same block target show the buyer a wall of banners, upsells placed before the buyer has committed add doubt rather than revenue, and validation Functions with unclear messages generate support tickets. Every extension should be justified against completion rate, not average order value alone.
What checkout extensibility actually costs
The title promised a cost answer, and the honest version is a set of scenarios rather than a number. The subscription is the largest fixed component for stores that need Plus. Shopify’s published Plus pricing at the time of writing starts at roughly $2,300 per month on a three-year term, with a higher month-to-month rate and variable pricing above a revenue threshold; verify the current figure on Shopify’s pricing page because it has changed more than once. Everything else is apps and development.
The following scenarios use ranges that reflect typical public app pricing and the development effort each scope implies. They are illustrative estimates, not quotes, and agency rates vary widely by market.
| Scenario | Plan | Apps | Development | Rough total, first year |
|---|---|---|---|---|
| Non-Plus store adding post-purchase surveys, tracking, and a pixel migration | Advanced or lower | $0–$100 per month | Minimal, mostly configuration | Low four figures at most |
| Non-Plus store adding App Store discount and shipping Functions | Advanced or lower | $50–$300 per month | Configuration and testing | Low to mid four figures |
| Plus store rebuilding a moderate checkout.liquid setup with public apps | Plus | $100–$500 per month | Inventory, testing, a few days of developer time | Plus subscription plus mid four figures |
| Plus store with custom UI extensions and one or two custom Functions | Plus | $100–$300 per month | Several weeks of developer or agency time | Plus subscription plus low to mid five figures |
| Plus store with a fully bespoke checkout, B2B fields, custom validation, and branding API | Plus | Varies | Multi-month agency engagement plus ongoing maintenance | Plus subscription plus mid to high five figures |
Two costs are easy to miss. The first is maintenance: Shopify releases new API versions quarterly with a defined support window, so custom extensions and Functions need a small amount of developer time each year. The second is the opportunity cost of features that cannot be rebuilt; if an old customization genuinely lifted conversion and has no equivalent, that lost lift is part of the migration’s cost and should be measured rather than assumed away.
For most stores below the Plus threshold, the right frame is that checkout extensibility made the checkout cheaper to customize, not more expensive, because public apps now deliver most of what used to require Plus and a developer. For stores above it, the frame is that the subscription was always the cost of a custom checkout and the new model simply made the customization safer. Either way, it is one input into the broader platform decision, and rarely the deciding one on its own.
FAQ on Shopify checkout extensibility
Is checkout.liquid completely gone, or can a Plus store still request access?
It is gone. Shopify’s deprecation timeline ended with the Thank you and Order status pages in 2025, and stores that had not migrated were upgraded to the new checkout automatically. There is no path back to a Liquid-based checkout, and Shopify has not indicated one is planned. Any agency still quoting checkout.liquid work is quoting for a product that no longer exists.
Do I need Shopify Plus to customize my checkout at all?
No. Every plan can install apps that add extensions to the Thank you and Order status pages, use Functions-based discount, shipping, and payment apps from the App Store, and run web pixels for tracking. What requires Plus, according to Shopify’s documentation, is custom UI in the information, shipping, and payment steps, custom-built Functions in a single-store app, and full control through the checkout branding API.
What is the difference between a checkout UI extension and a Shopify Function?
A UI extension is something the buyer sees: a field, a banner, an offer, a checkbox. It runs in a sandbox in the browser and renders Shopify’s components. A Function is logic the buyer never sees directly: a rule that changes which shipping options appear, how a discount is calculated, or whether a cart is valid. It runs on Shopify’s servers as compiled WebAssembly. Many real features use both, with a UI extension collecting an input and a Function acting on it.
Where did the Additional Scripts box go, and what replaced it?
The Additional Scripts box on the Order status page was retired alongside checkout.liquid. Its replacement is the Web Pixels API, where tracking runs either as an app pixel installed from a vendor or as a custom pixel the merchant writes in the admin. Custom pixels run in a sandbox with access to standard checkout events rather than the raw page. Anything left in Additional Scripts at the cutover stopped firing.
Can an extension call my own server or a third-party API during checkout?
A UI extension can make network calls to domains the app declares, subject to Shopify’s data-handling rules and buyer consent. A Function cannot make network calls at all; it has to receive any external data through metafields written ahead of time. That design keeps checkout fast and predictable, and it means integrations that need live external data belong in an app that syncs data in advance rather than in the checkout itself.
Can I rebuild my custom checkout layout exactly as it was?
Usually not. The checkout’s layout, step structure, and core fields are controlled by Shopify, and customization happens through branding tokens and named extension slots rather than free-form HTML and CSS. Colors, fonts, corner radii, logo placement, and header style are all adjustable. A fully custom multi-column layout or a bespoke progress indicator is not. Most stores find the branding tokens sufficient once they stop trying to replicate the old page pixel for pixel.
How do I test extensions without risking live orders?
Build and run them in a development store through the Shopify CLI, where development stores can have checkout extensibility features enabled without a Plus subscription. Use Shopify’s test payment gateway to place orders that do not move money. On the live store, assemble changes in a draft checkout profile in the checkout editor, preview on desktop and mobile, run scripted test purchases against each business rule, and only then publish.
Will migrating to checkout extensibility improve my conversion rate?
Shopify says the new checkout is faster and reports conversion gains for migrated stores, but those are vendor figures. Measure your own checkout completion rate, split by device and payment method, over comparable periods before and after. Make sure tracking is validated first, because a pixel migration can make ad-platform reports look like a conversion drop when the Shopify order count has not moved.
What ongoing cost should I plan for after the migration?
App subscriptions, which for most stores land between tens and a few hundred dollars a month, and a small amount of developer time per year if you have custom extensions or Functions, since Shopify releases new API versions quarterly and older versions eventually stop being supported. Plus stores also carry the subscription itself, which should be verified on Shopify’s current pricing page rather than assumed from older figures.