Merchant Stack Daily
Shopify app picks and stack advice for lean merchants

Field guide

Shopify Functions Explained: Discounts, Delivery, and Checkout Logic Without Script Editor

November 5, 2026

Interaction to Next Paint judges your worst interaction, and Google's good threshold is 200 milliseconds. Every app script that loads on the storefront competes to answer taps, so a stack of ten apps is not ten features; it is ten claimants on the same 200 milliseconds. Audit by removing weight, not by reading feature lists.

Functions are the successor to scripts, with a different shape

Shopify Functions let apps run custom logic on Shopifys own infrastructure at checkout, for discounts, delivery options, payment rules, and more. They replaced the old Script Editor, which Shopify retired, and the change of shape matters: instead of code a merchant pasted into their store, Functions arrive inside apps, run in milliseconds on Shopifys servers, and are managed from the admin like settings.

Shopify documentation is explicit about the trade. Functions are fast and upgrade safe, because the logic does not live in your themes checkout files. They are also bounded: a function can only do what its API surface allows, such as apply a discount combination, rename or hide a delivery option, or reorder payment methods. A promotion idea that falls outside those surfaces does not get built by wishing harder. It gets redesigned.

The discount jobs Functions actually changed

The most used surface is discounts: volume tiers, bundles, buy X get Y with conditions the standard discount builder cannot express, and combinations that stack in a controlled order instead of the all or nothing conflicts merchants remember. Apps built on Functions provide the interface, so a merchant picks a template or rules, and the function executes the logic at checkout speed.

Delivery and payment customisation are the quieter wins. Hide a courier option for postcodes it serves badly. Rename free shipping to state the threshold honestly. Move a preferred payment method up for specific markets. Each is small, unglamorous, and exactly the kind of checkout friction that used to require Plus scripts or a developer on retainer.

When you still need a developer, and when you do not

If an established app covers your rule, you do not need a developer, you need an afternoon of testing, including the edge cases: discounted items already on sale, mixed carts, the bundle broken by a removal at checkout. Custom functions need a developer to build and maintain, and that cost only makes sense when the logic is a durable competitive edge, a pricing model competitors cannot copy from an app store listing.

Test any function in a draft or controlled rollout before a campaign depends on it, and keep a plain language record of every active customisation, what it does and why it exists. Checkout logic nobody remembers installing is how stores end up explaining a discount to a customer that nobody on the team can reproduce. Functions moved the code onto solid infrastructure. The discipline still has to be yours.

Related reading

If this topic is useful, these earlier guides go deeper on connected questions: Shopify POS Explained: One Inventory, Two Front Doors, Shopify Markets Explained: One Store, Many Front Doors Abroad, and Shopify Rollouts Turned Your Theme Into an Experiment. Run It Like One.

Frequently asked questions

What are Shopify Functions?

Functions are a way for apps to run custom logic on Shopifys infrastructure for discounts, delivery options, payment rules, and checkout behaviour. They replaced Script Editor, run quickly at checkout, and are managed through apps in the admin.

Do I need a developer to use Shopify Functions?

Not if an existing app provides the function you need, which covers most discount, delivery, and payment customisations. A developer is needed for fully custom functions, which suit durable, unusual pricing or checkout logic.

What discount logic can Functions handle?

Volume tiers, bundle pricing, conditional buy X get Y offers, and controlled stacking combinations beyond the standard discount builder. The function runs at checkout in milliseconds, so complex rules do not slow the buyer down.

How should I test a new function before a sale?

Run it against edge cases: items already on sale, mixed carts, quantities crossing tier boundaries, and items removed at checkout. Keep a written record of every active customisation and what it is for, so the team can explain checkout behaviour later.