Skip to content

What you can and can’t customise in Shopify checkout

On any plan, you can change checkout branding through the admin and add functionality by installing apps built on Shopify’s checkout extension APIs. Building your own checkout UI extensions, and using the checkout editor for the core checkout steps, requires Shopify Plus. Editing checkout templates directly is no longer possible on any plan.

That last sentence is the one that catches people out, because a lot of published advice predates it.

What replaced what, and when

Two separate deprecations ran in parallel, on different timelines, and they get confused constantly. They’re different systems solving different problems.

checkout.liquid was the Liquid layout that rendered checkout, available to Plus merchants. It’s now unsupported for the Information, Shipping, and Payment steps. For the Thank You and Order Status pages, checkout.liquid and Additional Scripts were sunset on 28 August 2025. Script tags on those pages were sunset the same day for Plus stores, and on 26 August 2026 for non-Plus stores.

Shopify Scripts was the Ruby runtime for discount, shipping, and payment logic, also Plus-only. Editing and publishing new Scripts stopped being possible on 15 April 2026. All Scripts ceased executing on 30 June 2026. That deadline had already moved twice — from August 2024 to August 2025 to June 2026 — which is part of why so many stores treated it as soft.

If you’ve read that checkout.liquid was retired in June 2026, that’s the Scripts date being attached to the wrong system. The two are unrelated beyond both being replaced.

What you get instead

Three technologies, each with a different job:

Checkout UI extensions render interface into predefined slots. They run in a strict sandbox with no access to the rest of the page. This is where trust badges, custom fields, gift messages, and upsell blocks live now.

Shopify Functions run logic — discounts, shipping rules, payment method rules. They’re compiled WebAssembly executing inside Shopify’s infrastructure rather than interpreted Ruby in a sandbox, and they’re distributed as apps.

Web Pixels handle tracking. Each pixel runs in its own sandboxed iframe with no DOM access. This is the only supported path for post-purchase tracking, and it’s also the correct pattern for storefront tracking generally.

The sandboxing is the point. The old model let you do anything, including break checkout, and Shopify couldn’t ship updates without risking merchant customisations. The new model is narrower and survives platform updates.

What’s gated behind Plus

Available on every plan:

  • Branding settings through the admin
  • Public App Store apps built on checkout extensions
  • Thank You and Order Status page extensibility
  • Shopify Functions, though Basic is limited to one

Plus only:

  • The checkout editor for the core checkout steps
  • Building and deploying your own UI extensions to your own store without publishing to the App Store
  • The Checkout Branding API, for design-system level control
  • B2B checkout customisation with company-location-aware extensions

The practical implication: on Basic, Shopify, or Advanced, if you need a custom checkout field, your options are to find an app that provides it or to upgrade. Plus starts around $2,500 a month, so that maths only works at volume.

What you still can’t do

Even on Plus, the sandbox is real:

  • You can’t restructure the checkout steps
  • You can’t inject arbitrary JavaScript into the checkout page
  • You can’t read or manipulate the checkout DOM from outside an extension
  • Extensions render into defined slots, not anywhere you like

If a requirement genuinely can’t fit, the remaining route is headless checkout through the Storefront API — a substantially larger commitment than it sounds.

How to check what your store is actually running

Go to Settings → Checkout in the admin. If you see a code editor for checkout.liquid or a warning banner, you still have legacy customisations. If you see the checkout and accounts editor, you’ve been migrated.

Being migrated isn’t the same as being intact. Automatic upgrades remove legacy customisations rather than converting them. If Shopify migrated your store for you, something you were relying on may simply be gone.

The failure mode here is quiet. Checkout keeps taking orders. What breaks is the analytics layer underneath — conversion tracking stops firing, and the symptom looks like underperforming ad spend rather than a technical fault. Stores have run for months on bad attribution data without noticing.

If you’re auditing a store now

  1. Settings → Checkout, confirm which system is live
  2. Check the Additional Scripts field. Anything still in it is no longer executing
  3. In Settings → Customer Events, confirm your pixels are present and firing
  4. Check the Scripts customisations report in the admin for what Scripts used to do — it lists every Script that was active before deprecation and points at replacements
  5. Verify each installed app supports the current extension APIs
  6. Compare conversion data across the relevant deadline dates. A step change means tracking, not demand

Point 6 is the one that finds problems nobody reported.