Checkout Extensibility and Shopify Functions: What Replaced Scripts, and What Your Store Already Lost

If your Shopify store runs on any plan below Plus, your Thank you and Order status pages changed on August 26, 2026, and Shopify made the change for you if you hadn’t made it yourself. That was the deadline to upgrade those pages, and Shopify’s help center is blunt about what happened to stores that missed it: “Stores that weren’t upgraded by that date were upgraded automatically.”

App script tags followed the same split. They “were sunset on those pages on August 28, 2025 for Plus stores, and are sunset for non-Plus stores on August 26, 2026,” according to Shopify’s checkout.liquid documentation, which still writes that second clause in the present tense even though the date has passed. Both dates are behind us now, and the upgrade guide is where the auto-upgrade is documented.

None of it throws an error. An additional script that stopped firing looks identical to one that’s still firing: the checkout loads, the customer pays, the order lands in your admin. The only place the change surfaces is in numbers reported by systems that live outside Shopify, so a store can lose its Thank you page conversion pixel in August and not find out until somebody questions the ad spend in October.

Every date, quotation and figure below comes from Shopify’s documentation, changelog or help center, and each one links to the page it came from. Where Shopify is making a marketing claim about its own product, we say so inside the sentence instead of laundering it into a neutral fact. We build and rebuild these checkout stacks, so this is the analysis we’d hand a client.

We wrote up the tracking half of this same cutoff separately, in how Shopify conversion tracking dies silently on August 26th. This piece is the whole framework: what checkout extensibility is, what Shopify Functions replaced, what you can and can’t get back, and the one deadline in this story that’s still in front of you.

What is checkout extensibility? It’s Shopify’s app-based architecture for customizing checkout, and it exists because the previous method was editing a theme file. Under checkout extensibility, customizations arrive as extensions inside apps, and you place and configure them in the checkout and accounts editor, which Shopify describes as the tool that lets you “customize and manage the functionality and appearance of your checkout, thank you and order status pages, and customer accounts pages” in its checkout extensibility overview. Note the name: Shopify’s current help center calls it the checkout and accounts editor, so a tutorial working from the older “checkout editor” label may not match the admin you’re looking at.

Shopify’s marketing describes checkout extensibility as “a framework of apps, branding tools, and back-end logic that is regularly updated and improved by Shopify,” on its enterprise blog. That’s vendor phrasing, but the description is structurally accurate. The 2023 deprecation changelog gives the reasoning in Shopify’s own words: the new model is “app-based, upgrade-safe, higher-converting, and integrated with Shop Pay”. Three of those four are architecture claims you can verify by reading the docs, and the fourth is a marketing claim we’ll come back to.

On the developer side, checkout extensibility is four extension types. Shopify’s start building guide names them:

Styling sits beside those four, in the checkout branding API. Access is gated: the mutation reference states it “requires access to checkout branding settings and the shop must be on a Plus plan or a Development store plan,” and it splits customization into a designSystem layer for colors and typography and a customizations layer for specific components. That same checkoutBrandingUpsert page now carries a deprecation notice telling developers to “use checkoutAndAccountsConfigurationUpdate instead.” If your developer is working from a branding tutorial written before that notice went up, the mutation in their code is on the way out.

The plan line inside checkout extensibility runs between the checkout steps themselves and the pages that follow them. Checkout UI extensions “for the information, shipping, and payment steps are available only to stores on a Shopify Plus plan,” per the checkout UI extensions reference. Basic and above get the checkout and accounts editor plus eligible apps on Thank you and Order status. Shopify’s own Checkout Blocks help page draws the line in exactly the same place, which is how you know it’s the real line and not documentation drift.

Eight dates matter here, and six of them are history. Every one below is sourced from a Shopify page, and the two future rows are the only ones you can still act on before the fact.

Merchants conflate these constantly, and each one has a separate timeline, so a store can be fine on one and dark on another. Additional scripts were the plain JavaScript and Liquid text box under Settings, Checkout, Order processing, used mostly for tracking and small page tweaks. Shopify Scripts, the Ruby ones written in the Script Editor, were Plus-only business logic for discounts, shipping and payments. Script tags were the ScriptTag API that let apps inject JavaScript without touching your theme.

Additional scripts and checkout.liquid share the same fate. They went dead on the in-checkout steps on August 13, 2024, the date Shopify set in its 2023 deprecation changelog, and the checkout.liquid docs now record that file as “unsupported for the Information, Shipping, and Payment checkout steps.” Shopify’s replacement instruction for that field is specific: “you need to replace those customizations using pixels,” app pixels first, and “if there isn’t an app that meets your needs, then you can create a custom pixel,” per the additional scripts upgrade page.

On Thank you and Order status, Shopify publishes two dates that it never reconciles. The developer docs say checkout.liquid and additional scripts “were sunset for the Thank you and Order status pages on August 28, 2025,” with no plan qualifier on that sentence at all. The help center says August 26, 2026 “was the deadline to upgrade and replace your Thank you and Order status pages” for non-Plus stores, after which they were upgraded automatically. Read the first as when Shopify stopped supporting the old surface and the second as when non-Plus stores actually lost it.

Script tags are the one with a future. They stopped running on Order status on those same two plan dates, per Shopify’s blocking script tags doc, but the online store half of the deprecation only got announced on August 24, 2026, and it runs into 2027. That gets its own section below, because it’s the piece of this you can still get ahead of.

There were two Scripts dates, not one. Shopify’s developer changelog lists them together: on April 15, 2026, “editing and publishing new Shopify Scripts will no longer be possible,” and on June 30, 2026, “all Shopify Scripts will cease to execute entirely,” per the Scripts deprecation changelog. The gap matters because it changed what a fix looked like. From April 15 onward, a store whose tiered discount script had a bug couldn’t patch the bug, and the only remaining move was to rebuild the logic somewhere else.

Shopify’s non-Plus guide opens by naming its audience: “This guide is for stores that are on a non-Plus Shopify subscription plan,” in the checkout upgrade documentation. The same page notes that stores on the Pause and Build plan “are upgraded automatically,” and it’s explicit about the cost of the upgrade: “your existing Thank you and Order status pages and any existing customizations on those pages are replaced with the new versions of those pages.” Replaced, not migrated. Whatever was on those pages is not carried forward by the checkout extensibility upgrade.

That upgrade is a one-way door, and Shopify says so in a single sentence: “You can only reactivate an additional script when your Thank you and Order status pages haven’t completed their upgrade. If your Thank you and Order status pages are upgraded, then you can’t reactivate your additional script.” That’s from the additional scripts page, and it rules out the recovery plan most merchants reach for first. You can’t flip the field back on to read what was in it and you can’t flip it back on to buy time.

Shopify’s help center now writes about Scripts in the past tense: “As of June 30, 2026, Shopify Scripts has been deprecated,” and “any Scripts that were still published on your store have been deactivated and no longer work,” on the transitioning to Functions page. Deactivated with nothing underneath. A store that ran a volume discount through a Script didn’t fall back to a simpler discount on July 1; it fell back to no discount.

The categories that lived in Script Editor were tiered and volume discounts, shipping rate renaming and hiding, payment method gating, and wholesale or B2B pricing rules. Unlike the tracking failures, these announce themselves. A customer who should have gotten 20% off at six units and got full price will tell you, and the discount that quietly stopped applying shows up in average order value inside Shopify’s own reporting.

Shopify Functions are the replacement for Scripts and the back-end half of checkout extensibility. The definition Shopify uses is one line: “Shopify Functions allow developers to customize the backend logic of Shopify,” from the Functions overview. Where a Script was Ruby running in Shopify’s environment, a Function is a compiled WebAssembly module. The same page says function logic “is written in any language that can compile a WebAssembly module which meets function requirements,” that templates and client libraries exist for Rust and JavaScript, and that “Shopify strongly recommends Rust as the most performant language choice to avoid your function failing with large carts.”

That Rust recommendation isn’t stylistic. The Functions API index explains that “Rust’s memory safety and zero-cost abstractions help ensure your function runs efficiently and stays within resource limits,” which means a JavaScript function can be correct and still fail on a large cart by running out of budget. Functions are built and shipped with the Shopify CLI: shopify app function build compiles to Wasm, shopify app dev rebuilds the extension draft as files change, and shopify app deploy “builds the app, then deploys your app configuration and extensions,” creating an app version, per the CLI reference.

The Functions API index lists nine Function APIs, and the current stable API version is 2026-07 as of this writing:

Two limits are easy to design past and expensive to discover late. Shopify caps delivery customizations: “you can activate a maximum of 25 delivery customization functions on each store,” per the delivery customization docs. And network access is restricted in a way that kills a whole class of Script-era pattern: the fetch target “is limited to custom apps installed on Shopify Plus and Enterprise stores,” you have to “request network access for Shopify Functions,” and it isn’t available on development stores, per the Discount API docs. If your old logic called an external pricing service mid-checkout, that architecture doesn’t port straight across.

The Discount API also consolidated in version 2026-07. Shopify’s docs describe the unified schema this way: “a single function processes one discount (either code-based or automatic), but can apply savings across three discount classes: product, order, and shipping.” That’s one function where a Scripts-era setup often used separate logic per discount type, and it’s the change most likely to make an old migration plan out of date.

Spring ’26, the Shopify Edition released June 17, 2026 under the name “Everywhere,” added several checkout extensibility capabilities on the Functions side. Per the Spring ’26 Editions page, you can now query billing address and PO number inside cart and checkout validation functions, use metaobject entries in checkout functions for custom discounts and personalized logic, and use a new prerequisites field in product discount functions for buy X get Y offers. The same release added discount stacking on the same product, discounts by market, and a redesigned checkout that Shopify says makes “delivery options easier to scan, elevates the pay button, and reduces scrolling on mobile.”

Getting this one wrong sends non-Plus merchants looking for workarounds they don’t need. The gate isn’t on Functions. It’s on how a Function reaches your store. Shopify states it in two lines on the Functions API index, repeated verbatim on the Functions build overview:

In plain English: any plan can install an App Store app that contains a function, and only Plus can install a bespoke custom app that contains one. A non-Plus merchant isn’t locked out of Shopify Functions. They’re locked out of their own private Function. Shopify adds one qualifier alongside those lines, that “some Shopify Functions capabilities are available only to stores on a Shopify Plus plan,” so individual API pages still govern.

The practical consequence for a non-Plus store is a sourcing problem rather than a technical one. If an App Store app already does what your old Script did, you’re covered on any plan. If nothing in the App Store matches your rule, the custom app route requires Plus, and there is no documented admin-only way to publish a Function. Functions ship as extensions inside apps.

Shopify checkout UI extensions are the visible half of the framework: “extensions add custom UI and logic into any step of the Shopify checkout experience,” per the checkout UI extensions docs. They come in three target types. Block targets are “flexible placement targets that merchants can position using the checkout and accounts editor.” Runnable targets “provide data or functionality without rendering UI components.” Static targets “appear at fixed locations in checkout, such as before actions, after contact fields, or after cart line items.”

Placement has a hard ceiling that catches teams late in a build. Shopify’s checkout apps documentation states “there is a maximum limit of 3 apps per highlighted area.” If your plan is a trust badge, a delivery date picker, a gift message field and an upsell in the same region, one of them is getting cut.

Checkout Blocks is Shopify’s own no-code entry point into checkout extensibility, and on a non-Plus plan it’s the route that doesn’t require a developer. Shopify describes it as a way to “customize your checkout without using code, including adding custom fields, reordering payment and delivery methods, creating and enforcing order value limits, and setting up custom discounts with advanced rules,” on the Checkout Blocks page. The plan gate on that same page is precise: “merchants on the Basic plan or higher can use the dynamic content and static content blocks, and can place them only on their Thank you and Order status pages. All other features of Checkout Blocks are available only to Shopify Plus.”

The blocks overview lists what ships in the app:

Two of the Spring ’26 items route through this app specifically: address format validation is enforced “using Checkout Blocks,” and so are minimum and maximum order value limits. If you’re on Basic and you had an order minimum enforced by an additional script, Checkout Blocks is where that rule goes now, subject to the Plus gate on in-checkout placement.

Start with Scripts, because Shopify built a report for exactly this and it may not survive the deprecation. The help center currently directs merchants to Apps, then Script Editor, then “Replace Shopify Scripts” in the banner, which generates a customizations report showing the name, description and source file of each Script, grouped into Payment gateways, Shipping and Product discounts, with recommended replacement apps and links to the relevant Functions guides. That’s per the transitioning to Functions page, which also sets expectations honestly: “some customizations can be recreated by installing an existing app, and some customizations might require you to manually recreate them using an included Shopify Functions API guide.”

For additional scripts, the Upgrade guide page in your admin has an Additional scripts section showing what was in the field. Read it before you assume it’s empty, and read it knowing you can’t turn the field back on once the Thank you and Order status upgrade has completed.

Then go outside Shopify, because that’s where the silent failures are visible. Pull conversion counts by day from every ad platform, affiliate network, analytics tool and email platform that was ever fed by a Thank you page tag, and look at the shape of the curve across the relevant cutoff date. Shopify’s order data won’t move. The receiving system’s will, and the gap between the two is your inventory of what broke.

Shopify’s replacement path for tracking is pixels, and the pixels overview splits them into “app pixels, which are installed through marketing and data collection apps, and custom pixels, which can be manually added by a developer.” Pixels “automatically load on the Storefront, Checkout, Thank you page, and Order status page,” while customer account pages require a connected custom subdomain and fire only page_viewed. App pixels run in a strict sandbox and custom pixels in a lax one, per the Web Pixels API docs.

The sandbox is where checkout extensibility takes something away that no rebuild gets back. Shopify’s own list of what custom pixels can’t do covers rendering UI elements like buttons, forms, banners or modals; automatically detecting DOM-scraped events, metadata or user information such as email or phone; detecting outbound link clicks by DOM scraping; tracking page scrolling; and capturing clicks and mouse movement for heatmaps. Sandbox URLs “include a sandbox version and not exactly reflect the main window’s URL,” with the real URL available from the page_viewed event. If your old additional script scraped the DOM for anything, plan on that data ending rather than moving.

Google Tag Manager runs as a custom pixel, with the same ceiling. Shopify’s GTM tutorial states that “for security, tag managers loaded in our sandbox have the same restrictions as any other pixels.” Your dataLayer.push calls become Shopify.analytics.publish(), pushing data from checkout requires a UI extension, and Shopify’s pixel migration guide tells you to hunt down old pixel code in theme.liquid, checkout.liquid and Additional scripts, and to remove the old pixel before connecting the new one if you care more about avoiding double counting than about missing a few events.

On August 24, 2026, Shopify published the deprecation that isn’t behind you yet. Online store script tags are ending in two stages, per the online store script tags changelog. From October 1, 2026, scriptTagCreate and scriptTagUpdate mutations begin returning errors across every API version, while “existing script tags will keep running.” From March 1, 2027, “Shopify will stop injecting script tags into storefronts.”

Read the October date as a freeze, not a shutdown. What’s already installed keeps working, but an app can no longer create or update a script tag, so any app you install after October 1 cannot reach your storefront through that method, and any app that needs to update an existing tag cannot. That turns a March 2027 problem into an October 2026 problem for anything you were planning to install, replace or reconfigure in the months ahead.

Shopify’s replacement guidance is specific by surface. For the online store, “replace each script tag with an app embed block, which you ship in a theme app extension,” and for analytics or conversion tracking “use a web pixel instead, which needs no action from the app user.” For Order status, the blocking script tags doc points to customer account UI extensions for interface work and web pixels for analytics, with one honest caveat attached: “web pixels work on any store, but can’t render UI. Customer account UI extensions can, but only on upgraded stores.”

The work between now and October 1 is an inventory, and it isn’t a developer task. List every app installed on your store, and for each one ask the vendor a single question: does your app inject anything into my storefront using the ScriptTag API, and if so, what’s your timeline for moving to a theme app extension or a web pixel. Vendors that have already moved will answer immediately. The ones that take a week to answer are the ones to watch through March.

Order the work by how quietly each failure happens, not by how severe it looks on paper. A discount that stopped applying generates customer emails within a day and gets fixed by whoever’s on call. A conversion pixel that stopped firing generates nothing, and it keeps generating nothing while your ad platforms optimize toward a signal that no longer arrives. Rank the queue by silence:

Two things on that list get easier if you take them in the right order. Check the App Store before you commission a custom Function, because a public app clears the plan gate on any plan and a custom app doesn’t. And check the three-apps-per-highlighted-area limit before you design a checkout layout, because discovering it after two builds are done means throwing one away.

Branding lands last for a reason that has nothing to do with taste. Spring ’26 added a customized branding capability that lets you “set your logo, colors, and typography once, and it gets applied consistently across checkout, customer account, and sign-in pages,” per the Spring ’26 Editions page. Doing branding first means doing it against a surface whose functional blocks aren’t placed yet, and then doing it again.

You’ll see two numbers used to justify this migration, and both belong to Shopify. On its enterprise blog, published November 17, 2024, Shopify says the extensible checkout delivers “two times faster checkout interactions and page transitions that increase conversion by over 1% on average.” That’s Shopify’s own marketing claim about Shopify’s own product, and it isn’t framed as a controlled head-to-head against checkout.liquid. It’s the closest thing to a checkout-extensibility-specific conversion figure Shopify publishes.

The bigger number is platform-level and older. Shopify’s upgrade page says “Shopify’s overall conversion rate outpaces the competition by up to 36% and by an average of 15%, based on a study completed in April 2023 in partnership with a Big Three global management consulting company.” Again, Shopify’s own claim, the consultancy is unnamed, and the study is from April 2023, which makes it more than three years old today. It also measures Shopify against other platforms rather than measuring checkout extensibility against the thing it replaced.

The performance claim is narrower and easier to accept on its face. Shopify says “the WebAssembly platform that runs Shopify Functions offers better performance than Shopify Scripts, executing code in under 5 milliseconds,” on the transitioning to Functions page. That’s a vendor benchmark of a vendor runtime, and it’s also consistent with the architecture, since compiled Wasm should beat interpreted Ruby.

Here’s our position on all three. Don’t build the business case for checkout extensibility on Shopify’s conversion numbers, because they won’t survive a finance director who reads footnotes. Build it on the dated, documented fact that the old surfaces stopped executing. The conversion upside, if it shows up, shows up in your own data after you’ve rebuilt tracking well enough to see it.

The script tag deprecation is scoped to the online store, and Shopify’s own replacement guidance is an app embed block shipped in a theme app extension. That’s a theme construct. If you’re running a custom storefront rather than a Shopify theme, the theme app extension route isn’t the one available to you, and the web pixel route is, which is the more portable of the two options Shopify names. We’ve written separately on what running Hydrogen looks like in 2026 if that’s the architecture you’re on.

The other reason to finish this work has nothing to do with deadlines. Checkout extensibility moves your checkout logic out of theme markup and into apps, functions and pixels, which is the same direction of travel as a checkout that something other than a human has to be able to complete. We covered that shift in our piece on agentic commerce on Shopify. A checkout whose rules live in markup is a checkout only a browser can read.

Most of these deadlines already ran. What’s left is finding out what they took, and you usually can’t answer that from the admin alone, because the evidence lives in the platforms that stopped receiving data. Not a guess. Not a hunch about which pixel broke.

We do this work: mapping what your store lost across each cutoff, rebuilding tracking as app pixels or custom pixels, moving Script-era logic into Shopify Functions, and clearing script tag dependencies before October 1 turns a routine app install into a dead end. Start with our ecommerce checkout optimization services, or talk to us directly about what your checkout is doing right now.

Or take the free Growth Audit. A clear, no-obligation look at why your store isn’t getting seen or converting, with a roadmap for fixing it. You built something worth finding. Your checkout shouldn’t be the reason it doesn’t get found.