Shopify Plus Checkout Extensibility: The Deadlines, the Five Building Blocks, and What Your Checkout Can Still Do

Shopify Plus Checkout Extensibility – The short version

• Checkout customisation now lives in five places: the no-code Checkout and Accounts editor, Branding, UI extensions, Functions and web pixels. Everything from checkout.liquid gets reassigned to one of them.
• The deadlines are behind you. checkout.liquid and additional scripts on the thank-you and order-status pages were sunset for Plus on 28 August 2025, those pages are read only, and customer data inside them is restricted.
• From January 2026 Shopify upgraded stores automatically, which removed customisations on the legacy pages, analytics scripts included. Nobody got a warning call.
• Script tags on those two pages are sunset for non-Plus stores on 26 August 2026. If you are reading this later than that, the date has passed and the question is what it took with it.
• Plenty of it needs no developer: app blocks are dragged into place in the admin. Rules are the opposite. COD limits per emirate, BNPL thresholds and old Shopify Scripts are engineering work, mostly Plus only.

Open the checkout code of a Plus store built in 2021 and you can read the archaeology. A snippet hiding express payment buttons for wholesale customers. Two tag manager containers on the thank-you page. A block of jQuery that moves the discount field above the shipping options because somebody in a meeting once said it converts better.

All of that lived in checkout.liquid. All of it is gone.

Below: what replaced it, what it cannot do, what a rebuild costs, and how we handle it as a Shopify Plus agency in Dubai on stores with COD, Arabic and three payment gateways.

What checkout extensibility actually is

Checkout extensibility is Shopify’s replacement architecture for checkout customisation. Instead of editing a Liquid template and injecting JavaScript into the payment path, you attach small, sandboxed code to extension points that Shopify defines and versions.

You will read that this is mainly a styling change. That is only half true. Styling is the smallest part. The bigger part: your business logic moved out of the template and into Functions that run on Shopify’s servers before the checkout renders anything.

Why force it? Three reasons, only one of which is about you.

Upgrade safety first. While merchants could rewrite the template, Shopify could not change the checkout without breaking a share of stores.

PCI compliance second. Arbitrary merchant JavaScript on a page handling card data is a scope problem, and “an agency added a tracking snippet four years ago and nobody remembers what it does” is not an answer for an auditor.

Performance third. Additional scripts loaded in the browser, unbatched and often blocking, while UI extensions render inside Shopify’s pipeline. If store performance matters on your storefront, it matters more where the money moves.

In plain terms: you traded freedom for stability. Whether that was a good trade depends on how disciplined your old code was.

The deadlines, and what happens if you did nothing

28 August 2025. checkout.liquid and additional scripts for the thank-you and order-status pages were sunset for Plus stores, and those pages have been read only since. The information, shipping and payment steps had lost checkout.liquid support earlier still.

The PII restriction nobody mentions. Access to personally identifiable information inside the legacy pages is restricted. That is what quietly breaks integrations: an old snippet reading a customer name, email or address off the order status page into a CRM or a WhatsApp automation no longer gets that data. The page still loads. The data is not there.

January 2026. Shopify started upgrading stores automatically. The upgrade removes customisations on the legacy pages, analytics scripts included. Orders keep arriving, and a conversion tag stops firing without an error message.

26 August 2026. Script tags on those same pages are sunset for non-Plus stores too. If you run a standard plan and your GA4 or Meta purchase event hangs off a script tag there, your attribution is about to develop a hole.

So what actually breaks? Not the checkout. That is the trap. It keeps converting, so nobody escalates. What breaks is everything attached: purchase events, remarketing audiences, post-purchase widgets, wholesale-only messaging.

The pattern to look for is this. Paid social returns slide over a few weeks. The media buyer starts rewriting creative, because that is the visible lever. The actual cause sits in the checkout: an automatic upgrade removed the purchase event script. Conversions keep happening, invisible to the ad platform, which then optimises toward the wrong signal. If your numbers turned in the first months of 2026 and nobody can explain why, check this before you touch the campaigns.

The five building blocks

Everything you used to do in checkout.liquid now lives in one of five places. Assigning each old behaviour to the right one is most of the planning work; getting it wrong means building the same feature twice.

1. The Checkout and Accounts editor: the part that needs no developer

A large share of checkout customisation now happens in the admin, in a visual editor. You drag app blocks into the checkout, position them in the available slots and preview the result. An app that ships a checkout block (a trust badge, a delivery date picker) is placed by drag and drop.

What that does not cover is rules. If the request contains “only when”, “above” or “per emirate”, you have left the editor.

Rule of thumb: “show this here” is editor work. “Show this when” is code.

2. Checkout Branding: two levels, one deprecated mutation

Branding is configured through the API and splits into two levels. The design system covers colour schemes, typography and corner radius across the whole checkout. Customizations sit one level down: header, buttons, form fields, order summary, individual sections.

Work top down. Set the design system first, then override only what genuinely deviates, otherwise the checkout drifts away from the storefront after every rebrand.

One note that saves an afternoon: the Admin GraphQL mutation checkoutBrandingUpsert is deprecated, and Shopify points new implementations to checkoutAndAccountsConfigurationUpdate. Half the tutorials online still show the old one. Branding also needs a Plus plan or a development store, so a standard-plan client cannot preview it. This block overlaps most with regular theme and storefront development: nobody should notice the handover from cart to checkout.

3. Checkout UI extensions: you get slots, not a canvas

UI extensions render your own interface elements inside the checkout. The detail that decides your scope: you cannot place them wherever you like. Shopify defines static targets, each an anchor with an exact name.

A selection:

• purchase.checkout.block.render, the flexible one, which the merchant positions in the editor
• purchase.checkout.contact.render-after, plus purchase.checkout.delivery-address.render-before and render-after
• purchase.checkout.shipping-option-list.render-before and render-after, and purchase.checkout.shipping-option-item.render-after for a single option
• purchase.checkout.payment-method-list.render-before and render-after
• purchase.checkout.reductions.render-before and render-after, where discount code messaging lives
• purchase.checkout.cart-line-item.render-after and purchase.checkout.cart-line-list.render-after
• purchase.checkout.actions.render-before, directly above the pay button
• purchase.checkout.header.render-after and purchase.checkout.footer.render-after
• purchase.checkout.pickup-location-list and purchase.checkout.pickup-point-list, each with render-before and render-after

Plus two runnable targets for addresses, purchase.address-autocomplete.suggest and purchase.address-autocomplete.format-suggestion. More on those below.

“Can we put a box between X and Y” is now answerable in thirty seconds, and the answer is no more often than clients expect. That is the real break with checkout.liquid, where it was always yes and the cost surfaced later.

Restrictive? Yes, and it is why your checkout survives the next Shopify release without a hotfix.

4. Shopify Functions: the block people underestimate

Functions carry your logic. They compile to WebAssembly and run on Shopify’s servers, inside the checkout flow, before anything renders.

Shopify ships templates for Rust and JavaScript, and recommends Rust. Not a style preference: Functions written in JavaScript can fail on large carts. A wholesale order with 180 line items and tiered pricing is a normal Tuesday for a distributor in Al Quoz, and if the discount logic gives out there, the customer sees a wrong total on the biggest order of the week.

Where we land on this: if the function touches carts that can pass 100 line items, write it in Rust and stop debating it.

You can activate a maximum of 25 discount functions per store. They run at the same time, with no shared state and no execution order to coordinate through. Two campaigns that look sensible alone can produce a total nobody intended.

The counterweight: a single discount function can act on product lines, the subtotal and shipping costs at once. One well-scoped function beats four small ones arguing in production.

Then the cases where Functions do not run again, which is where support tickets come from:

• With draft orders, Functions that use network access are not supported.
• When an order is edited, Functions do not run again; what was applied at checkout stays.
• With subscriptions, Functions do not re-run for follow-up orders. Shipping discounts there apply at 100 percent to the follow-up shipments by default, regardless of the original value. A 20 percent shipping discount on the first order becomes free shipping forever on the recurring ones.

Function types that matter in checkout: discounts, payment customisation, delivery customisation, cart and checkout validation, plus bundles, fulfillment constraints, local pickup and location routing. Almost any rule you used to write in Liquid can be expressed, now as data flowing into the checkout rather than markup coming out of it. Building them means a custom app, which is how the code gets versioned and reviewed.

5. Web pixels, customer events and the post-purchase page

Tracking runs through web pixel extensions. They are sandboxed, with restricted access to customer data, which is the whole point after the PII restrictions on the legacy pages.

Practically: your tag manager no longer sees the checkout as it did. Every pixel has to be declared, mapped to the events you care about and tested against real orders. Plan a day, not an hour.

Thank-you and order-status extensions are the friendlier half, because they work on every plan. Reorder prompts, delivery tracking and review requests belong there, and so does your abandoned cart recovery programme.

Shop Pay and the one-page checkout

Stores that kept a customised checkout.liquid were locked out of Shopify’s newer checkout, including Shop Pay acceleration and the one-page layout. Your competitor’s returning customers checked out in one tap while yours filled three screens, because of a template nobody had touched since 2021.

Under extensibility that blocker is gone. One page instead of three steps, Shop Pay for returning customers, and every future improvement Shopify ships. Part of what you buy back is checkout speed you have been paying for in abandoned sessions. What that is worth in your store is a measurement job for conversion rate optimisation, not a migration promise.

App compatibility: the check almost nobody runs early enough

Give this its own owner. Sort every app into three buckets.

• Apps with a native checkout block or extension. Migration is re-adding the block in the editor and testing it.
• Apps still depending on script tags on the thank-you or order-status page. Dead code after the sunset dates, whether or not the app still shows in your admin. Loyalty widgets, survey tools, older upsell apps, some review platforms.
• Apps with no extension equivalent at all. The vendor never rebuilt, or rebuilt only half the feature set. You choose between replacing the app, which means new data and a new contract, or rebuilding the feature yourself as an extension plus function.

How to check: look for a checkout or post-purchase extension in the app’s listing, then place a test order and watch whether its element appears. Do not trust the marketing page.

Careful: an uninstalled app can leave script tags and metafields behind. Removing the app is not removing its footprint.

From Shopify Scripts to Functions: the most expensive line item

If you are on Plus and you used the Script Editor, this section is your budget.

Shopify Scripts were the Plus-only way to change discounts, shipping and payment options in the old checkout. Written in Ruby, deployed through the Script Editor, and over the years they collected logic that exists nowhere else: tiered wholesale pricing, free shipping thresholds per customer tag, payment restrictions, bundle discounts, stacking rules.

Scripts ran against the old checkout. Once a store runs on extensibility, that logic has to exist as Functions. Not a translation: a rewrite in another language with a different execution model.

The expensive part is rarely the code. It is that the requirements were never written down. A discount script from 2022 has six branches, three of which reference customer tags nobody assigns anymore. Somebody has to decide which branch is still a business rule and which is a fossil, and that needs commercial people, not only IT.

Rebuild behaviour, not code: most Script logic collapses into fewer, cleaner functions. And watch the 25 discount function ceiling, because a one-to-one port eats a surprising share of it.

What the Plus plan buys you

This question comes up in every scoping call, and the answer is rarely where people look for it. So, in one place:

Capability	Plan required
UI extensions on the information, shipping and payment steps	Shopify Plus
Custom apps that use Shopify Function APIs	Shopify Plus
Checkout Branding	Shopify Plus or a development store
Public App Store apps that use Functions internally	Any plan
Thank-you and order-status page extensions	Any plan

Read the first and the fourth row together, because that is the actual dividing line.

That gap is wider than it looks. On a standard plan you can install an app that applies a discount rule somebody else wrote. You cannot write your own. For a merchant whose pricing logic is specific to this market, that one line often justifies the upgrade. We break down the wider set of Shopify Plus enterprise features separately, and if the decision is still open, the comparison of Shopify vs Shopify Plus for this region is the better starting point.

On cost: the Shopify Plus pricing model changed in 2026, and what surprises finance teams is usually not the platform fee but what sits underneath it, including Shopify Plus transaction fees when you process through a third-party gateway.

What the migration costs in days

Nobody publishes numbers for this, which is why every quote feels arbitrary. Here is what we scope in our own projects, as a range from agency experience rather than a measurement or a quote. Your app list and Script history move these numbers in both directions.

Store profile	What is in scope	Effort we scope	What drives the price up
Small store, a few scripts	Tracking rebuilt as web pixels, two or three app blocks re-added, branding aligned to the storefront	3 to 6 days	Every extra ad platform, any app without an extension equivalent
Mid-size store with payment rules and tracking	The above, plus payment and delivery customisation functions, custom fields as UI extensions, a second language	10 to 20 days	Number of rules, COD and BNPL conditions, QA across payment methods and emirates
B2B or enterprise with Scripts and custom logic	The above, plus Script logic rewritten as Functions, wholesale pricing, validation rules, ERP touchpoints, subscriptions	25 to 60 days	Undocumented Script branches, large carts needing Rust, approval cycles

Two patterns hold across all three. Inventory and QA take more time than the code. And the biggest variable is not technical: it is how fast your team decides which old rules stay. A short consultancy session before you commit a budget is the cheapest step in the project.

One warning on quotes: a fixed price on a checkout migration before the inventory exists is a guess with an invoice attached.

What you can build for a UAE or GCC checkout

Cash on delivery with real rules

COD is still a serious share of orders across the UAE and the wider GCC, and unconditional COD is how you collect refused deliveries.

In the old world, merchants hid COD with a snippet in checkout.liquid. That was cosmetic: the hiding depended on the browser running your code, and a slow connection could show the button for a second before it disappeared. Orders have been placed in exactly that second.

Under extensibility the same rule is a payment customisation function. It runs on Shopify’s servers before the payment step renders, reading the cart total and the delivery address. The customer never sees the option, and there is nothing to bypass.

A workable setup for a furniture retailer usually comes down to two rules. COD is hidden above a threshold, say AED 4,000, the value where a refused delivery stops being an annoyance and becomes a logistics problem. And it is hidden in the address clusters where your own delivery data shows repeated failed attempts. Together: a few dozen lines of Rust and an afternoon of testing.

Delivery customisation functions cover the other half, hiding or reordering delivery options by emirate, so a Fujairah address is not offered a same-day slot that exists only in Dubai and Sharjah. Our guide to cash on delivery goes deeper.

BNPL that appears at the right moment

Tabby and Tamara make sense above a certain basket value and look odd below it. A payment customisation function hides or reorders them by cart total, so an AED 90 accessory order is not offered four instalments of AED 22.50. Which providers you offer at all is a separate decision, covered in our overview of payment gateways in the UAE.

TRN capture, addresses and pickup

For business buyers: a UI extension on the contact or address step, rendered only for customers tagged as business accounts, writing the tax registration number to the order so the invoice is compliant without a support agent chasing it by email. Once that number also has to land in the accounting system, it becomes an ERP and CRM integration question.

UAE addresses rarely have a street number, and a Makani code or a landmark carries more than a postcode. That is where the address autocomplete runnable targets earn their place: you shape the suggestions and how a chosen one is written into the fields. Delivery customisation plus a UI extension at the shipping option target lets you show “order within 2 hours 40 minutes for delivery today in Dubai” instead of a vague estimate. The logistics behind that promise is covered in our guide to shipping and fulfillment. If you run branches, the pickup targets connect the checkout to POS and local pickup inventory.

Purchase order numbers, Arabic and RTL

One field for wholesale customers, enforced by a checkout validation function so the order cannot be placed without it. Small feature, and it removes a whole category of finance work. If wholesale is a real channel, our piece on B2B and wholesale covers how the pieces fit on Plus.

Extensions inherit the checkout locale, so every string you add needs a translation, validation and error messages included. Those are the ones teams forget, and an English error inside an Arabic checkout reads like a bug even when the order goes through. Test in Arabic, on a phone, with a long name and a Sharjah address.

What is gone, and where migrations get expensive

Plainly gone: DOM manipulation of the checkout, third-party scripts in the payment path, custom fields injected by rewriting the template, and analytics that depend on script tags on the legacy pages.

The cost driver nobody estimates: behaviour that exists only as an undocumented conditional in a Liquid file, left by an agency that no longer exists.

If you are changing platform and rebuilding the checkout in one project, read our notes on moving your platform to Shopify Plus first. Teams moving from Magento in particular carry over checkout requirements that only existed to work around Magento’s constraints.

A migration plan that survives contact with reality

Phase 0, inventory. Pull the old checkout.liquid out of version history if you still have it. List every additional script, every script tag, every app with checkout permissions, every Script in the Script Editor. One line per behaviour: what it does, who asked for it, whether anyone would notice if it vanished. On a mature store, two to four days.

Phase 1, decide. Sort each item into keep, replace or drop, and be aggressive about dropping. In the inventories we run, a sizeable share of what turns up is a campaign nobody switched off.

Phase 2, assign. Map every “keep” to exactly one of the five blocks. If a requirement maps to no target and no function type, redesign it now, while that is cheap.

Phase 3, build. Functions first, because they carry the business risk. Then the UI extensions. Editor placement and branding come last, once there is something to place.

Phase 4, verify. Real test orders across every payment method, in both languages, on iOS and Android, domestic and cross-border. Check each one in the admin, in the ERP and on the invoice. Then reconcile every analytics platform against actual order counts, 48 hours after launch and again a week later.

Phase 5, watch. Shopify ships checkout changes continuously and extension API versions expire. Somebody has to catch a deprecation before it becomes an outage, which is the honest argument for a monthly support retainer rather than a project-and-goodbye engagement.

Mistakes we see in these migrations

Rebuilding the old checkout one to one. It was not sacred. It was ten small decisions and one designer who left. Use the migration to delete the two fields nobody fills in.

Choosing JavaScript for Functions because the in-house team knows JavaScript. Then a B2B cart with 200 lines fails during a campaign.

Treating branding as the project. It is visible, so stakeholders focus on it. The rules are the project.

Forgetting the order status page. Customers return to it while they wait for a delivery, and after a migration it usually sits empty.

Letting discount functions pile up. Twelve active functions from four campaigns, none aware of the others, until somebody buys AED 3,000 of furniture for AED 40.

Skipping subscription testing, so the follow-up shipping discount problem surfaces 30 days later.

Treating a migrated checkout as an optimised one. Field order, trust elements and payment method order are measurement questions, and our notes on optimising conversions apply directly to the new targets.

What this means for merchants in the UAE and GCC

Checkout logic here weighs more than in most European markets: COD guardrails, BNPL thresholds, a different address pattern, TRN handling, Arabic doubling the QA. Selling into Saudi Arabia, Kuwait and Oman adds a different payment mix, which is why selling across multiple markets usually turns into a conversation about running multiple stores under one brand.

So the honest conclusion: checkout extensibility here is not a design refresh for a freelancer. It is application development with a compliance deadline, and merchants migrating to Shopify from a legacy platform should budget it that way. The upside: rules that used to live in a courier’s spreadsheet or a support agent’s head are now enforced before the order exists. Our Shopify Plus case study from a Dubai build shows how that plays out.

FAQ

Which Shopify plans can use checkout extensibility features?

Every plan gets thank-you and order-status extensions, plus public apps that use Functions internally. The checkout steps themselves are Plus only, as is Branding.

Why did Shopify replace checkout.liquid?

So the checkout can be updated without breaking custom forks, so merchant JavaScript stays out of the payment path for PCI reasons, and so the page renders faster.

Does checkout extensibility work with Shop Pay?

Yes, and that is one of the reasons to move. A customised checkout.liquid kept stores off the current checkout, Shop Pay and the one-page layout included.

Which apps are compatible with checkout extensibility?

Apps that ship a checkout or post-purchase extension. Anything relying on script tags on the thank-you or order-status page is finished after the sunset dates. Verify with a test order, not the listing.

How do I add custom fields to my Shopify checkout?

With a UI extension at a defined target, for example after the contact section or around the delivery address, plus a validation function if the field is mandatory. Not anywhere you like.

Do I need a developer to customise the Shopify checkout?

Not for everything. App blocks, section order and branding are admin work in the Checkout and Accounts editor. Conditional rules, validated custom fields and old Shopify Scripts need development.

How long does the migration take?

A few days for a small store with tracking and two app blocks, several weeks for a Plus store with Script Editor logic, wholesale pricing and multi-language QA.

Where to start

If checkout tracking has not been verified since January 2026, start there. One hour, and it is the most common thing we find broken. Then run the inventory, one line per checkout behaviour, sorted into keep, replace or drop. That document shapes your budget more than any estimate will.

Send us the store URL and a rough list of what your checkout does today, and we will tell you what maps to a target, what needs a function and what is already dead. Talk to our team in Dubai.