Discount logic that survives your next promotion

Every discount project should begin with somebody actually trying to build the promotion in the admin, because the answer is often that it already works. Native discounts cover amount and percentage off, buy X get Y, free shipping, minimum quantity and minimum spend conditions, customer segment targeting, product and collection targeting, and both automatic and code-based application.

The reason to care is not purity. A native discount is visible to everyone in the business, editable by a merchandiser at 9pm without a deploy, and understood by every report and app that reads discount data. A Function is a codebase with a release process. Both are legitimate; only one of them is free to change on the day of the campaign.

The honest boundary: if you can describe the rule in one sentence and it refers only to quantities, spend, products and customers, try it natively first. If describing it needs the word "unless" twice, you are in Function territory.

Discount Functions inject your logic into Shopify's backend at the point the cart is priced. You define a GraphQL input query, Shopify hands your function the resulting JSON, and you return operations describing the discounts to apply. Product and order class discounts are returned through the cart lines discounts generate run; shipping discounts through the delivery options equivalent. The discountClasses field on the discount instance declares which targets run.

That gets you rules the admin cannot express: discounts driven by metafields on the customer or product, tiering computed across a mixed basket, bundle logic that depends on which variants are present, contract pricing for B2B accounts, and exclusions expressed as code rather than as a collection somebody has to maintain by hand.

What it does not get you is an escape from the platform rules. A Function cannot make a shipping discount stack with another shipping discount — Shopify documents only one shipping discount per order. It cannot raise the 25 active automatic discount ceiling. It cannot make two product discounts apply to the same line item on a plan where that is not available. Those are decided above your code, and discovering them after the logic is built is the most common way one of these projects goes over budget.

Two numbers deserve to be on the plan before anyone writes code.

Twenty-five active automatic discounts, app-based ones included. That sounds generous until you meet a store with a permanent free-shipping-over-£50 rule, a loyalty tier discount, a bundle discount, an outlet rule, and then a seasonal campaign with eleven variants of the same offer by category. Retailers hit this in November, at which point the fix is a rewrite of the campaign structure under time pressure.

The structural answer is to prefer one Function with data-driven rules over many discounts with identical shapes. A single Function reading tiers from a metaobject or metafield is one active discount regardless of how many tiers it expresses, and the tiers become data a merchandiser can edit. Eleven near-identical automatic discounts is eleven of your twenty-five spent on what is really one rule.

Five codes plus one shipping code, and only among discounts explicitly marked as combinable. If your customer service team habitually issues goodwill codes, they are competing for those five slots with your campaign codes. Decide deliberately which discounts are combinable rather than ticking the box everywhere, because "combines with everything" is how a basket ends up at 80% off through a route nobody modelled.

Functions run with published limits, and they are generous right up until the cart is large. Shopify documents a compiled binary limit of 256 kB, runtime linear memory of 10,000 kB, stack memory of 512 kB, and — for carts up to 200 line items — around 11 million execution instructions, 128 kB of function input and 20 kB of output. Beyond 200 lines the dynamic limits scale with the number of cart lines. The input query itself is capped at 3,000 bytes with a maximum query cost of 30, list arguments at 100 elements, and metafield values over 10,000 bytes are not returned at all.

Shopify states plainly that languages compiling directly to WebAssembly outperform dynamic ones, and recommends Rust for public apps, large line-item volumes or complex computation, noting that JavaScript exhausts the instruction budget sooner. Take that seriously in proportion to your biggest carts, not your average one.

The failure mode this creates is nasty precisely because it is invisible in development. A function that comfortably prices a five-line test cart can run out of budget on the 80-line trade order that arrives during your busiest week. Test against a cart the size of your largest real one, measure it with the CLI, and treat headroom as a requirement rather than a nice result.

The metafield ceiling has a similar shape: a rules metaobject that grows through the year is fine until the day it passes 10,000 bytes and simply stops being returned. If your Function reads configuration from metafields, assert that the configuration arrived before you use it, and fail loudly rather than silently discounting nothing.

A fair number of complex discount briefs are attempts to encode a pricing strategy that has never been written down anywhere else. The Function becomes the only place the commercial rules exist, which makes it both a development dependency and a single point of confusion, and it is why these builds get expensive.

If the promotion cannot be explained to a customer in one line, it will not convert as well as a simpler one, and it will generate support tickets from people who believe they qualified. We have more than once quoted a discount Function, walked the client through the combination matrix and the code limits, and watched them choose a simpler offer that performed at least as well. That is a good outcome, and it is cheaper for everyone.

• Shopify store development
• Shopify UX and checkout audit
• Shop Pay, express checkout and the conversion you are leaving