Shopify Functions replaced Scripts: what it means for you

If you are on Shopify Plus and someone built you custom checkout logic more than a couple of years ago, it was almost certainly a Shopify Script. Those are retired.

If you are being quoted for custom discount or shipping logic now, the answer should be Shopify Functions. If a quote mentions Scripts, that is a signal worth following up on.

Here is what changed, what it means for your store, and what to ask.

What this is about

Some commercial logic cannot be configured in the Shopify admin. Things like:

• Buy three, get the cheapest free, but only within one collection
• Wholesale customers get 20%, and 25% once they pass a spend threshold
• Hide express shipping for orders containing hazardous goods
• Only show purchase orders as a payment method to approved accounts
• Automatically apply the better of two competing discounts

Shopify's built-in discount and shipping settings do not cover any of that. You need custom code running inside the checkout, and there have been two generations of how that works.

Scripts, and why they are gone

Shopify Scripts were the Plus-only way to do this. Written in Ruby, edited in an admin app, running on Shopify's servers at checkout.

They worked, and they had two problems that mattered.

They only ran in the checkout. So the cart page and the checkout could disagree. A customer would see one price in the cart and a different total at checkout, and support would spend the day explaining it.

They were Plus-only, so everyone else configured apps into corners or gave up.

Shopify has retired them in favour of Functions. If you are still running Scripts, migration is not optional and the timeline is not yours to set.

What Functions changed

Functions are the replacement, and three differences are worth knowing as a merchant.

They are not Plus-only. Discount and delivery customisation Functions work on standard Shopify plans. A lot of logic that used to require a Plus upgrade no longer does, which occasionally means a merchant is paying for Plus for a reason that has expired.

They run everywhere the price is shown. Cart and checkout produce the same number, because the same logic runs in both. The class of support ticket where the totals disagreed largely disappears.

They are fast by design. Functions run inside Shopify's infrastructure with a strict execution budget, measured in milliseconds. They cannot make your checkout slow, which is not something you could promise about an app doing the same job with API calls.

The cases Functions cover

There are several types. The ones merchants actually ask for:

Discounts. Tiered pricing, volume breaks, bundles, customer-group pricing, complex BOGO. If your promotion cannot be expressed in the discount screen, this is the tool.

Delivery customisation. Hiding, renaming, or reordering shipping options based on cart contents, customer, or destination. Hiding overnight shipping for items that cannot fly, for instance.

Payment customisation. Which payment methods appear to whom. Purchase orders for approved wholesale accounts only.

Cart transform. Changing what is in the cart at checkout. Bundles that appear as one line to the customer but decompose into components for fulfilment.

Validation. Blocking checkout when rules are not met. Minimum order values, restricted items by region, licence requirements.

What it costs and how it is delivered

Being direct, because this is usually the missing part of the conversation.

A Function is a small piece of code you own, deployed through a custom app that exists only on your store. It is not listed publicly, there is no App Store review, and there is no revenue share.

No monthly fee. This is the part merchants are most often surprised by. A Function replacing a $99 a month discount app has no recurring cost. Over three years that is roughly $3,500 not spent, for logic that fits your business exactly rather than approximately.

Typical build: a straightforward discount or delivery Function is days, not weeks. Complex multi-rule logic with edge cases is longer, and should be quoted after someone has actually read your rules.

Maintenance is small but real. Shopify releases two API versions a year. Budget a few hours annually, not zero, and make sure whoever builds it hands you the source.

Questions worth asking a developer

"Is this a Function or an app?" If they are proposing an app for logic that is discount, delivery, or payment shaped, ask why. Sometimes the answer is good, an existing app genuinely fits. Sometimes it is that they have not built a Function before.

"Will the cart and checkout show the same total?" With Functions, yes. Ask anyway, because it tells you whether they understand the failure mode.

"Do I own the code?" You should. It should be handed over readable and commented, so another developer can maintain it.

"What happens at the next API version?" The honest answer is "it will probably keep working, and here is what it costs if it does not."

If you are still on Scripts

Two things to do.

Find out what your Scripts actually do. Frequently the person who commissioned them has moved on and the logic is undocumented. Get it written down in plain English before it is rebuilt, because a rebuild of logic nobody understands is a rebuild of a guess.

Then treat the rewrite as an opportunity rather than a like-for-like port. Scripts were written under constraints that no longer exist. Some of what your Scripts do may be simpler now, and some may be configurable in the admin without any code at all.

---

We build Shopify Functions for discounts, delivery, payment rules and cart logic, quoted fixed price, with the source handed over on completion and no monthly fee attached. We also migrate stores off retired Scripts.

Running custom checkout logic, or paying an app subscription for pricing rules? Book a free 30 minute call and we will tell you whether a Function replaces it and what that saves over three years. Or see our app development work.