Build vs. Buy>Discounts & Promotions>Discount stacking rules

Should You Build or Buy Discount Stacking Rules on Shopify?

Written by Deploi EditorialReviewed by Martin Dejnicki, Director of SEO & AI SearchUpdated August 2026Pricing verification pending

Discount stacking rules land on CUSTOMIZE for mid-market Shopify: native combination classes cover the common product, order, and shipping matrix free, and an estimated $5,000–$15,000 Shopify Functions layer (Deploi estimate, illustrative) encodes what checkboxes can't, like an order-level cap or dynamic sale-item exclusions. Apps can't exceed platform rules either. Scripts, stacking's old home, stopped executing June 30, 2026. Buy a rule-builder only when marketing needs self-serve controls now.

Your profile — see how the verdict shifts

VerdictCUSTOMIZE (native combinations + a Functions policy layer) · BUY for marketing-run rule builders
Buy score
5.0
Build score
7.6
Confidence
HighNative combination classes set a ceiling no app can exceed, so the only real custom surface is the Functions policy layer — and the Scripts shutdown already forced that migration
Reference scenario
$20M–$100M GMV · agency dev bench · single storefront
As of
August 2026

Decision at a Glance

Your profileVerdictWhy
Under $2M revenueWAITNative combination classes cover the simple matrix; don't pay a subscription or a dev bill for checkboxes Shopify includes.
$2M – $15MDEPENDSBuy a rule-builder if promos churn weekly and no dev bench exists; otherwise native settings plus one small Function covers the policy.
$15M – $75MCUSTOMIZEOrder-level caps and dynamic exclusions start protecting real margin at this scale, and the Functions layer that enforces them is a bounded one-time build.
$75M+CUSTOMIZEOne uncapped stacking pileup on a peak weekend costs more than the whole build; at Plus scale the policy layer is margin insurance you own.

What Discount stacking rules Actually Drives

OutcomeImpactHow it works
Revenue — directHighStacking control is margin defense: an uncapped pileup of code-plus-automatic discounts sells real units below the floor, so every blocked collision is revenue kept rather than revenue hoped for.
Operational efficiencyMediumA written, enforced policy ends the promo-night fire drill: no manual code disabling, no hand-edited orders, no morning-after triage when combinations misfire.
Customer experienceMediumPredictable discount behavior at checkout builds trust; a code that mysteriously won't apply, or a total that shifts at the payment step, is where carts abandon and tickets start.
Data & insightLowDiscounts land on the Shopify order on every path, so reporting parity is real; owning the policy adds a readable audit trail of why each combination was allowed or blocked.
Retention & LTVLowConsistent promo math protects your best customers; the people holding a loyalty code are exactly the ones hitting the stacking rules most often.

Spend ceiling: Price this as margin insurance, not a feature: the policy layer is a small Function, and the spend should track the size of the leak it closes. If a pitch prices stacking control like a promotion platform, you're buying the platform — the cap itself is a few hundred lines of code.

What buying enables (top apps)

  • + Live in days with a rule-builder UI: combination matrices, exclusion lists, and cap settings without a dev ticket
  • + Marketing edits stacking behavior mid-campaign from a dashboard instead of filing for a deploy
  • + Vendor-maintained updates as Shopify's discount API versions cycle every ~6 months
  • + Pre-built handling for the common collisions: code plus automatic, multiple codes, shipping promos

What building additionally unlocks

  • + Policy at your exact edge: your margin floor, dynamic sale-item exclusions from your own tags and metafields, per-segment cap math no generic rule builder ships
  • + One owned codebase deciding how every discount interacts — codes, automatic offers, gift lines, shipping promos — instead of app rules layered over native settings with no single owner
  • + A testable, versioned statement of discount policy that survives vendor churn and ports through API versions on your schedule
  • + No plan-tier gate between your cap logic and your customer, product, or metafield data

Find Your Verdict in 3 Questions

  1. Is every stacking rule you need expressible as combination checkboxes — which product, order, and shipping discounts may combine?

    Yes: Your verdict: WAIT — native combination classes include the common matrix; spend nothing and re-test it when a new promo type lands.

    No: Go to question 2.

  2. Do you need order-level policy — a total-discount cap, dynamic sale-item exclusions, or a margin floor?

    Yes: Your verdict: CUSTOMIZE — keep native combinations as the base and encode the policy in a Shopify Functions discount you own.

    No: Go to question 3.

  3. Does marketing change stacking rules most weeks without dev help?

    Yes: Your verdict: BUY — a rule-builder app earns its fee as a UI, knowing it runs on the same Functions surface underneath.

    No: Your verdict: CUSTOMIZE — the policy layer is small, and owning it puts no vendor between your margin and a promo night.

The TCC Scorecard — 12 Dimensions

TCC — Total Cost of Capability: what it actually costs to have this capability over three years, whichever way you get it. Each dimension is scored 0–5 for both paths. How we score →

DimensionBuyBuildWhy
Cost
Acquisition & implementationA stacking app configures in days; the combinations audit plus a policy Function is an estimated 2–5 weeks (Deploi estimate, illustrative).
Recurring feesRule-builder apps bill monthly for a matrix native combination classes now include; a deployed Function has no subscription line.
Maintenance & upgradesVendors track discount API changes for you; the build's upkeep is version bumps roughly every 6 months plus cap tweaks at promo season.
Switching & exitLow data gravity either way: policy rebuilds from a one-page rule sheet; the buy-side exit chore is re-testing every combination once the app stops answering.
Risk
Vendor riskStacking apps are small vendors wrapping the same Functions primitives; the build has no vendor to lose mid-promo.
Security & compliance surfaceFunctions run inside Shopify with no external calls; an app adds one more party reading cart and discount data.
Platform-deprecation exposureStacking control was a top Scripts use case and Scripts stopped executing June 30, 2026; Functions is the sanctioned successor both paths now stand on.
Value
Fit to requirementGood apps genuinely cover combination matrices and exclusion lists; only custom code matches your exact margin floor, sale-item logic, and per-segment cap math.
Time to marketDays versus a few weeks; buy wins when the promo calendar won't wait.
Performance & scaleBoth execute in Shopify's discount pipeline, so runtime parity is real; the build simply removes a third-party dependency from the checkout math.
Data ownership & AI-readinessHonestly minor here: discounts land on the Shopify order either way; what the build adds is a versioned, auditable policy codebase, not a data moat.
Focus & opportunity costThe policy layer is small, and a store porting dead Scripts logic already owes the Functions work; one ticket covers both.

The App Landscape

AppStatusPricingBest for
Shopify native discount combinationsNativeJuly 2026 research. Product, order, and shipping discount classes with per-discount combination checkboxes; the free base layer on every pathIncluded with your Shopify planThe common combine/don't-combine matrix with no app at all
Discount stacking apps (category)LiveRule-builder UIs wrapping the same Functions discount API; shortlist by cap and exclusion handling rather than pre-committing to a name$15–$100/mo bands (illustrative)Marketing-run stacking rules without a dev ticket

The Build Path

  • Native combination classes as the base: Start by encoding the combine/don't-combine matrix in Shopify's own product, order, and shipping discount classes. It's included, and every rule expressed there is one you never write code for.
  • Discount Function for the policy layer: A Shopify Functions discount enforces what checkboxes can't: cap the order's total discount percentage, exclude sale items dynamically from your own tags, or block code-plus-automatic pileups past your margin floor.
  • Policy config on metafields: Caps, exclusion collections, and code classes live in shop metafields, so merchandising edits the policy from admin and no deploy stands between a promo and its guardrails.
Effort band
$5,000–$15,000 build — Deploi estimate (illustrative); lands in the $10–25K contact-form band
Typical timeline
2–5 weeks (Deploi estimate, illustrative)
Maintenance, honestly
~15–20% of build cost per year (Deploi estimate, illustrative): discount API version bumps land roughly every 6 months, and cap or exclusion tweaks arrive with the promo calendar. There is no subscription line.
What you own — and what you take on
You own: the stacking policy as testable code, its behavior with every discount class, and the config merchandising edits. You take on: combination QA each promo season and the upkeep above.

3-Year Total Cost of Capability

Buy (app path)Build (custom path)
Year 0 (setup)$0–$500$5,000–$15,000
Years 1–3 (recurring)$540–$3,600$2,300–$9,000 (maintenance)
3-year total≈$540–$4,100≈$7,300–$24,000
Illustrative cumulative cost over 36 months$0$4k$8k$11k$15kMo 0Mo 12Mo 24Mo 36Buy (app path)Build (custom path)
Illustrative cumulative cost: on subscription math alone, cheap rule-builder tiers never cross the build line. The customize case rests on what the fee actually buys, since native combination classes already include the common matrix and apps can't exceed platform rules either — and one uncapped pileup on a peak weekend can outweigh the whole gap.
  • All figures illustrative samples for the reference scenario — not quotes, not verified pricing.
  • App path: mid-tier rule-builder pricing held flat over the horizon (real tiers climb with usage — conservative for the build case).
  • Build includes the combinations audit, one policy Function, and metafield config; three-year horizon.

What the Sticker Price Hides

On the buy path

  • Paying a subscription for the common matrix: native combination classes already handle product, order, and shipping combinations free (July 2026 research)
  • The ceiling is the platform's, not the vendor's: a rule Functions can't express stays impossible at every price tier
  • Vendor risk lands mid-promo: an app outage or silent logic change surfaces as wrong totals during your biggest sale (community-reported pattern)
  • Rule sprawl: app rules layered over native settings with no single owner produce the exact pileups you bought the app to stop

On the build path

  • The QA matrix is the real scope: every code class times every automatic discount times shipping promos, re-tested each promo season
  • Skip the metafield config layer and every cap change becomes a dev ticket, which quietly rebuilds the case for an app
  • ~15–20% of build cost per year in upkeep (Deploi estimate), with discount API version bumps roughly every 6 months

What Merchants Say

Scripts-deadline anxiety hit stacking logic hardest: combination rules that quietly guarded margin for years went dark on June 30, and some teams only noticed when codes started piling up at checkout.
community-reported (2026 research corpus)
The recurring complaint shape for discount tooling: codes combined when they shouldn't have, discovered in the morning numbers after a promo night — every one of those orders shipped below the floor.
app-store 1–2★ review theme

If You Change Your Mind Later

If you bought and outgrow it

Uninstall is low-drama on data: stacking rules carry no gravity, so the policy rebuilds natively or in a Function from a one-page rule sheet. The catch is silent reversion — the moment the app stops answering, carts fall back to native combination settings, so re-run the full collision QA the same day you uninstall.

If you built and want out

The Function and its metafield config are yours: the policy ports forward through API version bumps on your schedule, and if you ever retreat to an app, nothing is stranded. The code itself is the asset — a testable, versioned statement of your discount policy most merchants never had in writing.

When This Answer Changes

We're watching for:

  • Shopify expanding native combination controls toward order-level caps or dynamic exclusions; each release moves logic from the Functions lane to the checkbox lane
  • August 26, 2026: Shopify removes legacy checkout scripts, closing the last script-era discount surface (July 2026 research)
  • Discount API changes in the ~6-month version cycle that touch combination behavior; diary the changelog check

Verdict change log:

  • 2026-06-30While the script ran, keeping it was free and rational. The hard stop ended that: carts fell back to native combination settings, which allow pileups the script used to block, and the sanctioned home for the policy layer is now a Functions discount. The August 26, 2026 removal of legacy checkout scripts closes the last script-era surface.

Common Questions

Can discount codes stack on Shopify?

Yes, within limits you choose: native combination classes let each discount declare which product, order, and shipping discounts it combines with, from admin checkboxes (July 2026 research). What native can't do is enforce policy across the whole pile, like capping an order's total discount or excluding sale items dynamically. That layer belongs in a Shopify Functions discount, the same logic that lived in Scripts before June 30, 2026.

How do you cap the total discount on a Shopify order?

With a Shopify Functions discount: the Function evaluates the applied discounts, computes the order-level total, and blocks or trims the pile past your cap. No native checkbox enforces an order-level cap today (July 2026 research). Stacking apps implement the same cap on the same Functions surface, so you're choosing who writes and owns the code, not what's technically possible.

What replaced Shopify Scripts for discount stacking?

Shopify Functions, specifically its discount API. Scripts stopped executing on June 30, 2026, and stacking control was one of its top use cases (July 2026 research). Combination logic still living in Ruby is dark, and carts fall back to native combination settings, which may allow pileups your script used to block. Most stacking policies port to a Functions discount in a two-to-five-week build (Deploi estimate, illustrative).

Your Next Steps

If you're going with CUSTOMIZE(matches your selected profile)

  1. Write the policy on one page first: which classes combine, the order-level cap, and what's always excluded
  2. Audit live discounts against native combination classes and fix the checkbox matrix before writing any code
  3. Inventory anything that ran on Scripts before June 30, 2026 — stacking control was a top use case and that logic is dark now
  4. Ship one Functions discount enforcing the cap and exclusions, with config in metafields so merchandising edits it without a deploy
  5. QA the full combination matrix in a dev store before each promo season — a stacking bug is direct margin loss

If you're going with BUY

  1. Confirm the rule you're buying exceeds native combination classes, or you're paying monthly for included logic
  2. Verify the app runs on Shopify Functions, not legacy surfaces — those close August 26, 2026
  3. Test collisions in a dev store: code plus automatic, gift lines, shipping promos, and behavior at the cap
  4. Assign one owner for the combined native-plus-app rule set so no orphan rule stacks unnoticed
  5. Diary a re-decision when the subscription's running total passes the small-Function build estimate

Official Docs & Sources

Official documentation linked for verification — our verdicts and estimates are our own.

Ready to make your stacking rules enforce themselves?

A stacking bug is margin walking out the door. We audit what Scripts left dark, encode your policy in a Functions discount you own, and QA the collisions before your next promo window.

Contact us today

Ecommerce development at Deploi

Verdict scored for the reference scenario above. Estimates are not quotes; app pricing is re-verified quarterly. Full scoring anchors: see the TCC methodology.

Read how we score these decisions (the TCC Framework). No affiliate links, no paid placement — no app vendor pays to appear here.

No affiliate links. No paid placement. We make money building and integrating solutions — not on referral fees.