Shopify checkout: the pros and cons

This guide is for merchants deciding whether Shopify's hosted checkout is enough, and for developers who have to extend it. We stick to what Shopify's own docs say about what checkout does, what you can change and where the edges are.

What you get out of the box

The biggest advantage of Shopify's checkout is that you don't run it. Shopify's checkout docs describe it as where merchants accept orders and receive payments wherever they sell online. There is no checkout code for the merchant to patch, host or keep compatible with a theme. That frees up a surprising amount of developer time, and it means one less place for a launch-week bug to hide.

The docs also say that all customisation options are easy to install and upgrade-safe. In practice that means merchants can benefit from new Shopify releases, with Shop Pay and One-page checkout named as examples, without a rebuild. Compare that with a heavily modified checkout of your own, where every platform change is a job someone has to schedule.

Treat that as the main trade-off, because staying inside supported extension points is what keeps upgrades free. If you extend checkout with the documented extension types, you keep the benefit. If you push against the edges, you lose some of it. So our tip is to start from what the extension types can do, such as Functions for discount and delivery logic, and shape the requirement to fit rather than the other way round.

You'll often hear that a hosted checkout is faster and more trusted by shoppers. The docs we read don't make those claims, so take them as reasoning rather than measured fact. It is plausible that a familiar, consistent checkout reassures buyers and that a platform-run page gets steady performance work. Test it on your own store before you promise it to a client.

What you can change with extensions

Shopify lists four types of extension for customising checkout: UI extensions, Functions, Web pixel extensions and Payments extensions. Between them they cover what the buyer sees, the rules behind the scenes, how events are tracked and how payment is handled. Shopify's checkout docs say these options are upgrade-safe, so your changes should keep working as new releases such as Shop Pay and One-page checkout arrive.

The docs give some useful examples. Functions can hide a payment option, rename a delivery option, or block progress when cart line quantities exceed a limit. Extensions more broadly can offer a customer free shipping or other discounts depending on what is in their cart. None of that needs you to touch the checkout templates, which is the point: you add behaviour without owning the whole page.

Merchants place UI blocks themselves in the checkout editor in the Shopify admin, so a developer can build the extension and the team can decide where it sits. One catch from the checkout UI extensions reference: static targets sit at fixed spots and can't be moved. Check which kind of target you are using before you promise a layout.

Here is our tip. Reach for a Function when the change is logic, and a UI extension when it is something the buyer needs to see. A quantity limit or a hidden payment option is a rule, so it belongs in a Function. A delivery message or a custom field is something the buyer reads or fills in, so it belongs in a UI extension. Keeping the two apart tends to help because rules then apply consistently, and the interface stays small and easy to test.

Where Shopify Plus comes in

Plan level matters most when you start extending checkout. Checkout UI extensions for the information, shipping and payment steps are available only to stores on a Shopify Plus plan, according to the checkout UI extensions docs. Those are the steps where most of the interesting changes tend to live, so this is where Plus becomes the dividing line.

The same docs say extensions add custom UI and logic into any step of the Shopify checkout experience. Read that alongside the plan note: the capability exists across the flow, but step-level access is what Plus unlocks. Merchants can still place blocks using the checkout and accounts editor, including on the Thank you page. The build you can do without Plus is therefore narrower, and it tends to be about what happens after the order rather than during the core steps.

Here is the tip we'd give any team. Before you scope a build, list every requirement and write down which checkout step it touches: information, shipping, payment or Thank you. Then check that list against the store's plan. This tends to save you from designing a feature the store can't ship, and it gives a merchant a clear, factual answer when they ask whether Plus is worth it for their particular needs.

What can't change

Some parts of checkout are fixed, and it helps to know where before you plan a build. Static targets render automatically at set locations when the page loads, and Shopify's checkout UI extensions reference says they can't be moved or repositioned. Block targets are more flexible, because merchants can place them in the checkout and accounts editor. Even then, a merchant can add up to three extensions to the same block target location. If you're stacking an upsell, a gift note and a delivery message, decide early which ones earn the space.

Extensions also have limits on how much they can do. The same reference says rate limits may apply to extensions that make too many changes during a checkout, and once an extension is rate limited it can't make further changes during that buyer's session. So keep the logic light. This tends to help because a checkout step that does one clear job is easier to test and less likely to hit a limit. Where the work is really a rule, such as hiding a payment option, renaming a delivery option or blocking progress when quantities go over a limit, Shopify Functions are the tool the checkout build docs point to.

A few details are easy to get wrong early. Once you create a draft version of an extension or deploy it, you can't change its handle, so name it carefully. The extension name must be between 5 and 30 characters. Each target must point to its own module file, though you can define several targets in one configuration file. Finally, checkout apps and extensions must meet Shopify's design requirements, whether they're custom or public apps, and the components follow Shopify's design system. You won't get a radically different look, but the checkout stays consistent and familiar to buyers.

Moving off checkout.liquid

Start with what has already changed. Shopify's checkout docs say checkout.liquid is now unsupported for the Information, Shipping and Payment steps. Anything you built there the old way is no longer something to maintain. It needs a replacement.

The Thank you and Order status pages have a deadline. Script tags on those pages were sunset on August 28, 2025 for Plus stores, and are sunset for non-Plus stores on August 26, 2026. Stores still using checkout.liquid on those pages must upgrade to Shopify Extensions in Checkout. If tracking snippets or post-purchase widgets live there, check them first, because a snippet that stops running tends to go unnoticed until someone looks at the reports.

Our tip is to audit before you build. List every old customisation and every tracking snippet, and note what each one does for the buyer or the business. Then rebuild each as the right kind of extension. Shopify's checkout docs list four types: UI extensions, Functions, Web pixel extensions and Payments extensions. As a rule of thumb, visible changes suit UI extensions, rules such as hiding a payment option, renaming a delivery option or blocking progress on a quantity limit suit Functions, and tracking suits web pixels.

Next, map each item to an extension type and to your plan. Checkout UI extensions for the information, shipping and payment steps are available only to stores on a Shopify Plus plan, so a non-Plus store may need a different route for some of them. Put the result in a simple table with one row per customisation, and you have your migration plan and a clear view of what you can drop.