Shopify Checkout Extensibility: Every Deadline, and What to Migrate First

The dates, first, because they are the whole story

Shopify checkout extensibility is not a feature announcement any more, it is a series of deadlines, and if you are still reading blog posts from 2024 you have the wrong ones. Here is the actual sequence, straight from Shopify's deprecation notices:

• August 13, 2024 — checkout.liquid becomes unsupported for the Information, Shipping and Payment steps. This one is long past.
• August 28, 2025 — checkout.liquid and additional scripts are sunset for the Thank you and Order status pages.
• August 28, 2025 — script tags are sunset on those pages for Plus stores.
• August 26, 2026 — script tags are sunset on those pages for non-Plus stores. That was four days ago as I write this.
• October 1, 2026 — the one almost nobody has diarised. API version 2025-07 was the last to support React-based UI components in checkout UI extensions. After October 1 you are blocked from updating an extension that has not moved to Polaris web components.

If you own or maintain a store with checkout customisations, the first three are archaeology and the last two are your quarter.

What actually broke on August 26

Non-Plus stores that were still injecting script tags into the Thank you and Order status pages lost them. In practice that is: post-purchase survey scripts, referral-program widgets, some analytics and conversion tags, upsell embeds, and review-request pixels.

The failure mode is the ugly kind. The page still renders. Checkout still works. Orders still complete. The only symptom is that a number somewhere goes flat — a conversion count, a referral signup rate, a post-purchase survey response rate — and nobody connects it to a date.

If you have not looked, look now: pull your post-purchase conversion metric and your referral signups for the last two weeks against the two weeks before. A step change on August 26 is not a coincidence.

The Plus line, stated plainly

This is the thing merchants find out too late.

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 extensions are not restricted the same way, which is why the practical advice for a non-Plus store is: everything you wanted to do inside checkout is not available to you, and the post-purchase pages are where your remaining budget goes.

Custom payments extensions are Plus-only as well, and additionally restricted to approved partners on Shopify's Payments Platform. If a proposal you have been sent involves building a bespoke payment method, check both of those before anything else.

Block targets versus static targets

Once you are building, the first real decision is where the extension renders.

`purchase.checkout.block.render` is the general-purpose block target. It is not tied to a specific checkout section or feature, and the merchant chooses its placement in the checkout and accounts editor. It renders regardless of which checkout features are available, which makes it the safe default — an extension bound to a feature the store does not use simply does not appear.

Static targets render at fixed locations tied to specific sections. Use them when the extension only makes sense in one place, and accept that it will not render if that section is not present.

I default to the block target for anything a merchant might reasonably want to move, and static only when position is semantically load-bearing.

Block targets give you read access to cart contents, buyer identity and delivery details. To store custom data — gift wrap preference, delivery instructions, a PO number — write cart metafields through the Metafields API. And check cart instructions before calling a mutation, because which mutations are available depends on the checkout.

The blocking change from January 2026

This one changed behaviour under existing extensions, and it is worth understanding because it also changes the right architecture.

As of January 26, 2026, checkout UI extensions that support blocking default to non-blocking. A merchant must explicitly turn on the "Allow app to block checkout" setting in the checkout and accounts editor for blocking to work.

If your extension's entire purpose is validation — "you must accept these terms," "this address is not serviceable," "minimum order quantity not met" — it now silently does nothing until someone flips a switch you cannot flip for them. Shopify's guidance for extension authors is to detect this in the editor with the useExtensionEditor() hook and warn the merchant, and to include the step in your activation instructions.

The deeper recommendation is the useful one: build checkout validation with Cart and Checkout Validation Functions, not with UI extensions. Functions are more secure, more performant, and guaranteed to run across supported checkouts. A UI extension is a rendering surface; validation that matters belongs in a Function that runs server-side and cannot be bypassed by a client hitting the cart API directly. On a wholesale store, somebody will.

That is the same principle as order-quantity rules on a B2B storefront: theme-level or client-level validation is a suggestion, not a rule.

Thank you and Order status are two different surfaces

They look the same to a merchant and they are not the same to a developer.

Thank you page — target purchase.thank-you. The critical detail: the order is not yet created when the extension renders. The order id is available. You can use OrderConfirmationApi to get the confirmation number or the id, and then fetch the rest through the GraphQL API once order creation completes.

That constraint kills a whole class of naive designs. "Show the customer their loyalty points balance including this order" does not work on the Thank you page if you assumed the order exists. Design for the id, fetch later.

Order status page — target customer-account.order-status. Here the order is always available, and OrderStatusApi gives you the id, name and confirmation number directly. This is where post-purchase surveys, review requests, digital download links and order-lookup experiences belong.

And a limitation to plan around from the start: there is no support for mutating an order from a UI extension. You can fetch out to your own service, but if the customer needs to change what they bought, that is a post-purchase extension, not a UI extension on these pages.

The migration order that saves the most work

Shopify's own recommendation, and I have not found a case where it was wrong: plan the in-checkout, Thank you and Order status upgrades together.

The reasons are practical. You avoid maintaining two tech stacks in parallel. You apply styling once across the whole experience. And you manage one deadline instead of two.

If you genuinely cannot do them together, do in-checkout first and the after-purchase pages second.

Before any of that, use the report in the Shopify admin that identifies your existing checkout customisations and maps them to Shopify Extensions in Checkout. It exists specifically to make this review shorter, and I have watched teams reverse-engineer their own checkout by hand without knowing it was there.

The practical sequence

This is how I actually run one of these:

• Inventory what is live. The admin report plus a manual pass over the checkout in a real session. Every script, every app, every injected element. Status per item: KEEP / REPLACE WITH APP / REBUILD AS EXTENSION / REBUILD AS FUNCTION / DROP.
• Sort by whether it is validation or presentation. Validation goes to Functions. Presentation goes to UI extensions. Getting this split right up front avoids building the same thing twice.
• Check the Plus line for each item. If you are not on Plus, in-checkout items are not migrations, they are deletions or business cases for upgrading.
• Look for a public app first. Shopify keeps adding checkout apps built on extensions. Building custom is the last resort, not the first instinct, and this is one of the few places where I mean that.
• Rebuild against a current API version, with Polaris web components. Not React. The October 1, 2026 cutoff is real and it blocks updates, which means it blocks your ability to fix a bug in an extension you shipped.
• Test conversions last and watch them live. The single most expensive way to get a checkout migration wrong is to break the purchase event while fixing a survey widget. Order matters, and a broken conversion tag costs more than a missing feature.

The short version

• Non-Plus script tags on Thank you and Order status died on August 26, 2026. Check your post-purchase metrics for a step change.
• In-checkout UI extensions are Plus-only. Custom payments extensions are Plus-only and partner-gated.
• Use purchase.checkout.block.render unless position is semantically required.
• Validation belongs in Cart and Checkout Validation Functions, not UI extensions — and extensions no longer block by default anyway.
• On the Thank you page the order does not exist yet. Only the id does.
• Move to Polaris web components before October 1, 2026, or you cannot update your own extension.

Related services

Checkout customisation, Functions and extension work sit under Shopify expert development. B2B checkout requirements — PO numbers, net terms, quantity rules — are covered in Shopify B2B: company accounts, catalogs and price lists. If you need senior capacity on a deadline, hire a Shopify developer.

I migrate checkout customisations on stores where a broken checkout is not an option, and I do the conversion-tracking verification as part of the job. See [Shopify expert development](/shopify-expert) or [hire a Shopify developer](/hire-shopify-developer).

Direct: [WhatsApp +55 11 98851-2788](https://wa.me/5511988512788) · [contato.matheusabrahao@gmail.com](mailto:contato.matheusabrahao@gmail.com)