Shopify Scripts are gone. What replaces them?

If you are on Shopify Plus and something about your checkout quietly stopped working this summer, this is probably why.

Shopify Scripts are over. The dates were:

date	what happened
15 April 2026	editing and publishing Scripts stopped working
30 June 2026	all Scripts stopped executing entirely

There was no grace period after the second date and there is no way to turn them back on. If you had a Script doing something at checkout, it is not doing it now.

The short answer

Scripts are replaced by Shopify Functions. But "replaced" is doing a lot of work in that sentence, because Functions are a genuinely different thing, and the difference is the reason this migration has been harder than it looked.

A Script was arbitrary Ruby that ran on Shopify's servers during checkout. You could express almost anything, and you could put it live yourself from the Script Editor.

A Function is a small WebAssembly module that answers one specific question the platform asks it: what discounts apply to these cart lines?, should this cart be allowed to check out?, which payment methods should be shown? Each question is a separate extension target. You cannot write a Function that does something the platform never asks about, and you deploy it as part of an app rather than pasting it into the admin.

That is the migration in one line: you are not porting code, you are picking which of several fixed questions your old Script was really answering.

What each kind of Script maps to

Scripts came in three kinds, and they do not all land in the same place.

Line item scripts are the ones that changed prices, applied volume breaks, gave a customer group a different price, or zeroed out a gift. These become either a discount function, which adds a named discount the shopper can see, or a cart transform, which silently rewrites the line price so the shopper only ever sees the lower number. Cart transform is Shopify Plus only. Discount functions work on every plan.

Shipping scripts are the ones that hid, renamed or reordered delivery options. These become a delivery customization function.

Payment scripts are the ones that hid a payment method for certain carts, most often to stop people putting a high-value or restricted order on a particular method. These become a payment customization function.

Payment customizations are plan-restricted, and the way they fail is worth knowing before you rely on one: on a plan that does not support them, the function still runs, still returns its output, and the platform ignores it. There is no error and no warning: the method simply stays visible. Confirm yours took effect on a real cart rather than reading a clean deploy as proof.

If your Script did more than one of those, it becomes more than one Function. That is normal and it is not a sign you have done something wrong.

The trap that catches people: rounding

This is the single most common thing to go wrong after a migration, and it is worth understanding even if you never write a line of code yourself.

A percentage discount on a cart line is a multiplication, and a multiplication on a price almost never lands exactly on a whole cent. If a Function calculates in floating point and only rounds when it formats the number for display, the rounding error moves depending on where in the calculation it happens. Do that in two places (say, a Function that decides the discount and a cart that recalculates the total) and the two can disagree by a cent on a large enough basket. The shopper sees one number, the order records another, and nobody can reproduce it on a small test cart.

The fix is not clever, it is just disciplined: hold money as an integer number of minor units (cents) for the whole calculation, and round exactly once, at the boundary where the number leaves your code. If you are having a Function written for you, that is a reasonable thing to ask the person writing it, and a reasonable thing to expect a yes to.

It matters more than it sounds, because a rounding disagreement does not fail loudly. It produces a store that is correct almost all the time, which is the hardest kind of bug to be told about by a customer.

What you can do yourself, and what you have to buy

The honest split:

Write it yourself if the logic is genuinely specific to your business: a discount that depends on something only your catalogue knows, or a validation rule tied to your own operational constraints. Functions are open, the tooling is public, and if you had a developer maintaining Scripts you already have the person who can do this.

Buy an app if what you had was one of the common shapes. Volume breaks, trade pricing by customer group, order minimums, hiding a payment method, blocking product combinations: these are the same handful of patterns in every store, and the fixed cost of building, deploying and maintaining an app extension for them is not worth paying twice.

Shopify's own migration note says the same thing, in its own words: it tells merchants to move their customisations to Functions or public apps.

One thing to check on any app you shortlist, because it is invisible from the listing: whether it needs your shoppers' addresses. A cart's delivery address is classified by Shopify as protected customer data, and not just the postcode: the country and province codes and the geolocation fields are all covered. So an app that offers destination rules, hiding a payment method by country or blocking checkout by region, has to request access to that data and be approved for it. That may be exactly what you want. It is worth knowing you are choosing it, rather than discovering later that a checkout rule was the reason an app reads where your customers live.

If you are only finding out now

Check three things, in this order:

1. Your discounts. Put a real basket through checkout that should trigger your old pricing. If the price is full, that logic is gone and nothing is telling you.
2. Your payment methods. If a method used to be hidden for certain carts, it is showing now.
3. Your delivery options. Same again: anything a shipping Script used to hide is visible.

Nothing about this is urgent in the sense of being recoverable if you hurry. It has already happened. The urgency is only that every day it stays unnoticed is a day of orders priced on rules you thought were in force.