The checkout you cannot change, and the one you can

Start with the deadline, because it is the one thing in this article that has a date attached and some stores have not acted on it.

Shopify's documentation is unambiguous: "checkout.liquid and additional scripts were sunset for the Thank you and Order status pages on August 28, 2025. Script tags were sunset on those pages on August 28, 2025 for Plus stores, and are sunset for non-Plus stores on August 26, 2026." The same page notes that checkout.liquid "is now unsupported for the Information, Shipping, and Payment checkout steps".

If you are not on Plus and something still injects a script into your Thank you or Order status page, it stops working in under two months. In practice that is usually a conversion tag, a post-purchase survey, a referral widget or a reviews prompt — installed years ago by someone who has left, and invisible until the revenue attributed to it goes to zero. The replacement is a checkout UI extension or a web pixel, and both are development work with a lead time. Audit what is on those two pages this month, not in August.

Branding attaches to a checkout profile and is applied either through the checkout and accounts editor or through the Admin GraphQL API. The input has two layers: a designSystem covering colour schemes, typography, font sizing and corner radius, and customizations reaching into specific areas — the header and logo, the main column, the order summary, form controls, the primary button, the footer, the buyer journey, the favicon.

You are configuring values, not writing rules. There is no selector, no cascade, and nowhere to put a media query. That is the constraint teams find hardest, and it is the right one: it is what lets Shopify keep shipping checkout improvements without breaking every store that styled it.

Two documented limits catch people at handover. You cannot style one step differently from another — Shopify states you "can't currently customize styling for individual pages" — and what you set carries across checkout, UI extensions and customer account pages together. And SVG is not a supported image type for styling checkout, so the logo needs a raster export.

An extension renders at a defined target — a named place in checkout — using Shopify's own components. It can add a delivery-date picker, a required consent checkbox, a gift message field, a loyalty balance, a note about a restricted item.

What makes extensions predictable is the sandbox, and it is worth understanding before you promise anything. Extensions run isolated from the checkout page and from each other, with no access to checkout HTML or assets and no access to sensitive payment data, restricted to the exposed APIs and a subset of standard web APIs. Outbound network calls are opt-in: an extension has to declare the network_access capability in its configuration, and Shopify's own documentation flags this even for the modest case of sending errors to a third-party service.

The practical consequence is that an extension cannot fight the page it sits in. It cannot move the email field, collapse the order summary, restyle the shipping step or read the card form. Every one of those has been asked for in a kickoff we have sat in, and the answer is the same each time.

The plan line runs through here too. Shopify documents that "checkout UI extensions for the information, shipping, and payment steps are available only to stores on a Shopify Plus plan." Thank you and Order status page targets are not behind that restriction, which is the practical route for a non-Plus store replacing a sunset script tag.

This comes up in every scoping call and gets answered wrongly in both directions, so here is the documented position.

Shopify states that "only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs", and separately that "some Shopify Functions capabilities are available only to stores on a Shopify Plus plan". Public apps distributed through the App Store containing functions are not restricted to Plus.

That distinction matters more than the headline. A store that is not on Plus cannot write its own checkout logic, but it can install someone else's. So the honest question for a non-Plus merchant is not "do we upgrade" but "does an App Store app already do this" — and for the common cases, one usually does. Upgrading to Plus to write one discount Function is the most expensive way to get a discount.

When Plus does pay for itself it is rarely a single rule but a set that only make sense together — B2B pricing with net terms and validation, multi-market delivery logic, a bundle model — plus the other things the plan carries. When we scope [a Shopify build](/services/build) that includes checkout, the plan question is settled by the whole list, never by one feature.

A one-page checkout. A custom field order. Our own payment step. A different layout on mobile. A progress bar of our own design. These arrive on almost every checkout brief and none of them is buildable, on any plan, at any budget.

We would not build them if they were. The last decade of ecommerce is full of bespoke checkouts that were a competitive advantage for a year and a liability for the five after it — unmaintained, untested against new wallets, quietly converting worse than the default that kept improving without anybody paying for it. A checkout you cannot change is a checkout that gets better while you work on something else.

The reframe that gets a brief unstuck is to stop asking how checkout should look and start asking what has to be true about an order. Trade customers must not see consumer shipping rates. Hazardous goods must not go by air. A gift order needs a message and a delivery date. Orders over a threshold need approval. Every one of those is a Function or an extension, all of them are enforceable, and none of them needs a line of the checkout page to move.

If after that the brief still contains something on the impossible list, the work is not in checkout. It is in the cart page — which is yours, which is where the decision actually gets made, and which is where we would spend the budget.

• Shopify store development
• Checkout UI extensions: what belongs in checkout and what does not
• Custom checkout logic with Functions: three worked examples