For years, customising Shopify checkout meant Scripts — a Ruby sandbox available only on Plus, hard to test and harder to hand over. Shopify Functions replaced that model with something closer to real software: versioned code, deployed as part of an app, running inside Shopify’s own infrastructure at checkout speed.
This guide covers what Functions actually are, what you can and cannot do with them, how they differ from Scripts and apps, and how to decide whether your discount or delivery requirement needs one.
What Shopify Functions are
A Function is a small piece of code, compiled to WebAssembly, that Shopify executes at a defined extension point in its own backend. You do not host it. You do not scale it. It runs where the decision is made, which is why it can influence checkout without adding latency to your storefront.
Functions ship inside an app, which means they get version control, a deployment pipeline and a rollback story. Compared with a Script pasted into an admin field, that is the whole point: Shopify Functions made checkout logic reviewable.
What you can build
The Functions APIs cover a defined and growing set of extension points. The ones merchants ask for most:
- Discounts — logic no promotion builder expresses: tiered by quantity, conditional on customer tag, bundle-aware, capped per order.
- Delivery customisation — reordering, renaming or hiding shipping options based on cart contents, address or customer group.
- Payment customisation — hiding a payment method for B2B accounts, or surfacing net terms only for approved companies.
- Cart and checkout validation — blocking checkout when a rule is broken: minimum order value, restricted product and region combinations, licence requirements.
- Cart transform — merging or expanding line items, which is what makes bundle pricing work correctly at checkout.
What you cannot build
This is the part sales conversations skip. Functions run at specific extension points with strict limits: execution time is capped, network calls from inside a Function are not how it works, and input is limited to what the API exposes at that point.
If your rule needs to call your ERP mid-checkout to check a credit limit, that is not a Function. If it needs data Shopify does not pass to that extension point, no amount of engineering makes it one. The honest framing is that Shopify Functions are for decisions that can be made from cart and customer data alone, quickly and deterministically.
| Requirement | Right tool |
|---|---|
| Tiered discount by quantity or tag | Discount Function |
| Hide express shipping for oversized carts | Delivery customisation Function |
| Net terms only for approved B2B accounts | Payment customisation Function |
| Block checkout below a minimum order | Validation Function |
| Live credit check against an ERP | App + pre-checkout flow, not a Function |
| Rewriting checkout layout | Checkout UI extension |
Shopify Functions versus Scripts
If you are still running Scripts, the migration is not optional in the long run and is worth doing deliberately rather than under deadline.
The practical differences: Scripts lived in the admin and were effectively untestable; Functions live in a repository with a deploy pipeline. Scripts were Plus-only and opaque; Functions are versioned, reviewable and diffable. Scripts silently misbehaved when edge cases appeared; Functions fail in ways you can reproduce locally.
The migration cost is real, because Script logic accumulated over years is usually undocumented. Budget the archaeology, not just the rewrite.
Do you need Shopify Plus?
Extension points differ by plan, and the checkout-adjacent ones — discounts, delivery and payment customisation — are where Plus matters. Before assuming an upgrade is required, write the rule down and check which extension point it needs. We have talked several merchants out of a Plus upgrade that a native discount would have covered, and into one where the rule genuinely required checkout logic. Our Shopify Plus pricing breakdown covers the wider cost picture.
Performance is the quiet advantage
The reason to care about Shopify Functions is not elegance. It is that the logic runs inside Shopify rather than in a third-party app that adds a network round trip at the worst possible moment.
An app-based discount engine calling out mid-checkout adds latency exactly where abandonment is most sensitive. A Function does not. For high-traffic stores that difference is measurable, and it compounds during the peak periods when it matters most.
Testing and rollback
Because Functions ship inside an app — see the Functions API reference — they inherit an app’s release process — and you should use it. Write the rule as test cases before writing the Function, run them locally, deploy to a development store, and verify against real carts rather than synthetic ones.
Rollback deserves a plan of its own. A discount Function with an inverted condition can sell your catalogue at a loss faster than anyone reads the alert. Decide in advance who can roll back, how, and what the monitoring signal is — the number that would tell you something is wrong within minutes rather than at the end of the day.
Common Shopify Functions mistakes
- Rebuilding what is already native. Shopify’s own discount types cover a lot. Check before you build.
- Undocumented stacking rules. Functions interact with automatic discounts, codes and B2B price lists. Write down the intended combination or discover it in production.
- Building the rule the stakeholder described rather than the one the business runs on. Ask for the exceptions first; there are always exceptions.
- No monitoring. A Function that stops matching silently produces full-price orders, and nobody complains about that until the promotion report arrives.
- Treating it as a one-off. Checkout logic changes with every season. Build it to be edited.
When an app is the better answer
If your requirement is standard — volume discounts, simple BOGO, a countdown promotion — an established app does it today, with a UI your merchandising team can operate without a developer. That is worth more than architectural purity.
Use a Function when the rule is specific to your business, when it must run at checkout speed, or when the app you would otherwise buy cannot express the condition. Our Shopify Plus development team scopes these the same way each time: write the rule in plain English, find the extension point, then decide build or buy.
Working with a merchandising team, not around them
The most common organisational failure with Shopify Functions is building logic that only a developer can change. A discount rule hard-coded into a Function means every seasonal adjustment becomes a ticket, a deploy and a wait.
The better pattern is to build the mechanism in the Function and expose the parameters as configuration — metafields, or a small admin UI in the app. The Function reads “minimum quantity” and “discount percentage” rather than embedding them. Merchandising changes the numbers; engineering owns the logic.
That distinction is worth insisting on at scoping time, because it costs little to build in and is expensive to retrofit once the rule is live.
What Shopify Functions cost to own
The build is usually modest — a well-scoped discount Function is days rather than weeks. The ownership is where the real cost sits, and it is worth pricing honestly.
You now have an app in your account that needs a home: a repository, a deploy path, someone who can release it. Shopify’s APIs version, and extension points evolve; a Function written today will need attention within a year or two. And the logic itself changes as the business does.
For a merchant with an agency retainer or an internal developer, none of that is a barrier. For a merchant with neither, a Function is a dependency on somebody being available when the promotion needs changing — and that is a genuine argument for choosing an app instead, even when the app fits less precisely.
A worked Shopify Functions example
A common request: “give trade customers 20% off, but not on sale items, and cap the discount at £500 per order.”
Native discounts handle the first clause and struggle with the combination. An app might handle two of the three. A discount Function reads the customer’s company or tag, filters line items by whether a compare-at price is set, applies the percentage, and caps the total — deterministically, at checkout speed, with the thresholds in metafields so finance can change the cap without a deploy.
That is the shape of a good Shopify Functions use case: a rule with several interacting clauses, needed at checkout, where the parameters change more often than the logic.
How to start
Take the single checkout rule that currently lives in a spreadsheet or in somebody’s head, and write it as a sentence with its exceptions. That sentence tells you the extension point, whether Plus is required, and whether Shopify Functions are the answer at all.
If the sentence needs data from outside Shopify to be true, you have learned something more valuable than any tutorial: the work is an integration problem first, and a checkout problem second. Our technical audit often starts exactly there.
