The Shopify Order-Rules Recipe Book: How to Stack MOQ, Max, Per-Customer & Cutoff Rules (2026)

One order rule is easy. Shopify itself will cap how many of an item go in a single cart. The problems that actually cost merchants money need several rules working together: a wholesale store that needs a minimum and a pack multiple and a max; a drop that needs a per-customer cap and a cutoff and a stock ceiling; a kitchen that needs store hours and a same-day cutoff and a capacity limit. Overselling and mis-ordering aren't small problems either — analysts at IHL Group have pegged the global cost of out-of-stocks and overstocks at north of $1 trillion a year (IHL Group — directional, but the order of magnitude is the point).

This is the recipe book for stacking those rules on Shopify. Each recipe is a real merchant scenario, the exact rule stack that solves it, the gotcha that breaks it if you're careless, and where native Shopify runs out of road. It's meant to be skimmed: find the scenario closest to yours and copy the stack.

Quick answer: how do order rules stack on Shopify?

Order rules are AND-combined — every applicable rule must pass, so the strictest wins. Layer them by scope (store, collection, product, variant): quantity rules, a per-customer cap, and timing rules (store hours, cutoff, capacity), then enforce the stack at checkout via a Shopify Function. Shopify's only native control is a per-checkout add-to-cart limit, so stacking needs an app like OrderRules.

The rule ingredients

Every recipe below is built from these building blocks. Learn the ingredients once, then the recipes are just combinations.

The through-line: Shopify natively gives you exactly one of these (a per-item, per-checkout add-to-cart limit). Everything else — and every combination — comes from enforcing rules at checkout with a Function. For the mechanics, see how Shopify checkout validation blocks orders.

The one principle: rules are AND-combined

Before the recipes, the rule that governs all of them: when several rules apply to the same cart, they combine with AND — every one must pass, and the strictest is what the customer experiences. A cart of 8 against a minimum of 6, a step of 2, and a max of 20 passes all three. A cart of 7 fails the step. A ninth unit against a per-customer cap of 8 fails the cap even if the quantity rules are fine.

Two consequences worth burning in:

• Contradictions lock the product. Set a minimum above a maximum and no quantity can ever satisfy both — the product becomes un-buyable. Always design the stack as a narrowing range.
• Overlapping scopes both apply. If a product sits in two collections that are each capped, both caps are live and the tighter one wins. Deliberate stacking is powerful; accidental stacking is a support ticket.

Keep that in mind and the recipes below compose cleanly.

Recipe: B2B / wholesale case packs

Scenario: you sell to trade buyers in fixed case packs and want a real minimum, pack multiples, and a ceiling.

The stack:

• Step of 6 (or your pack size) — buyers can only order 6, 12, 18…
• Minimum order quantity of 6 — a multiple of the step, so the floor and the pack agree.
• Maximum per order (e.g. 240) — a sane ceiling that flags mistaken bulk entries.
• Optional minimum order value for a currency floor on top of the unit floor.

The gotcha: a minimum without a step doesn't enforce the pack — a buyer orders 6, then 7, then 13, and your case-pack logistics break. The minimum must be a multiple of the step. Full detail in selling in multiples / case packs and the MOQ guide.

The native wall: Shopify's native B2B quantity rules cover increments only in B2B/wholesale contexts and per variant, with no pooling; the add-to-cart limit can't set a store minimum at all.

Recipe: A fair limited drop

Scenario: a hyped, limited-stock release you want spread across real customers, not cleared by one buyer or bot. On the hottest drops, anti-bot vendors report inorganic traffic spiking toward ~99% (Kasada, Queue-it — vendor-reported, directional).

The stack:

• Per-customer limit of 1, tracked across orders — not per cart.
• Block guest checkout / require login — so the cap attaches to an identity.
• Daily / stock cap equal to the run, so it can't oversell.
• Drop cutoff — checkout opens and closes at set times.

The gotcha: a per-checkout limit isn't a per-customer limit — ten separate orders each pass a per-cart cap. And guest checkout is the hole a per-customer limit can't cover. See per-customer vs per-checkout limits and the anti-scalping guide.

The native wall: Shopify has native bot CAPTCHA but no per-customer purchase cap for a normal storefront. Pair this stack with a raffle or queue app for the biggest drops — see running a limited drop without chaos.

Recipe: Same-day perishables

Scenario: a bakery or fresh-food shop taking same-day orders it has to actually make and hand over.

The stack:

• Order cutoff (e.g. 2pm) — after which same-day ordering closes and rolls to the next day.
• Per-day capacity cap — the most orders the kitchen can produce that day.
• Store hours — checkout blocked when you're closed, so no 2am orders you can't fill.

The gotcha: cutoffs are timezone-sensitive — set the cutoff in the store's timezone or a customer three zones over slips past it. And a capacity cap only works if it's enforced at checkout, not just shown as a note. See setting up cutoff times and delivery capacity limits.

The native wall: Shopify has no native cutoff, no per-day order cap, and no store-hours checkout block. All three come from the rules layer — start with how to set store hours.

Recipe: Made-to-order studio

Scenario: furniture, ceramics, or custom goods built to order, where you sell capacity rather than stock. Demand is real — Deloitte found roughly one in three consumers interested in customized products, willing to pay around a 20% premium (directional).

The stack:

• Lead-time delivery date — customers see "ships in 3–4 weeks" and can't pick an impossible date.
• Per-week production cap per product — slow, high-effort pieces get a tighter cap than quick ones.
• Delivery cutoff — the last order that can still hit a chosen date given the lead time.

The gotcha: inventory ≠ capacity. Shopify counts stock; a made-to-order shop has none, so native inventory limits don't model "how many can I build this week." Cap the rate. Full playbook in made-to-order lead times & production caps.

The native wall: no native lead-time engine, no per-week order cap, no production cutoff. OrderRules is the capacity/lead-time layer; pair a product customizer for the options themselves.

Recipe: Pre-order batch without overselling

Scenario: you're taking pre-orders for a batch you'll manufacture once, and you must not sell more than the batch will hold.

The stack:

• Total pre-order cap equal to the batch size — a per-product order limit that stops when the batch is spoken for.
• Per-customer limit so a single buyer can't corner the whole run.
• Pre-order cutoff date — the point where pre-orders close and production locks.

The gotcha: pre-order isn't made-to-order — pre-order sells a fixed batch that will ship on a date, so the binding limit is total units, not a per-week build rate. Turning on Shopify's "continue selling when out of stock" removes the brake entirely, letting pre-orders run past the batch. Cap the total instead. (For build-after-purchase goods, use the made-to-order recipe.)

The native wall: Shopify has no native "cap pre-orders at N total" — inventory either blocks at zero or oversells without limit.

Recipe: Local food delivery

Scenario: a food store delivering in its own area, wanting a real order minimum, open-hours enforcement, and per-slot capacity.

The stack:

• Store hours — no checkout when the shop is closed.
• Minimum order value — a delivery floor so small orders don't lose money.
• Per-slot capacity cap — limit orders per delivery window.
• Pickup option alongside delivery.

The gotcha: native Shopify Local Delivery only works with Shop Pay — not Apple Pay, Google Pay, Amazon Pay, or PayPal — so a wallet buyer can dodge a native delivery setting. Server-side rules enforce across every payment method. Scenario walk-through in local delivery for a food store.

The native wall: the Shop-Pay-only limitation above, plus no native MOV or per-slot cap.

Recipe: Subscription box windows

Scenario: a monthly box that sells out per cycle and needs to close signups when full.

The stack:

• New-signup cap per cycle — cap how many new subscribers you accept before a cycle.
• Signup cutoff — a date after which new signups roll to next cycle.
• Per-collection capacity if several box tiers share a production ceiling.

The gotcha — the big one: checkout-validation Functions run on the new signup/checkout but are not supported for subscription recurring orders. So this stack gates who joins and when, not the renewals that follow. Don't try to throttle renewals with these rules — they won't be evaluated. Detail in Shopify for subscription boxes.

The native wall: subscription apps (Recharge, Appstle, Seal) bill the cycle but don't cap boxes-per-cycle or close signups when full — that's the rules layer beside them.

Recipe: Flash-sale fairness

Scenario: a timed promo you want to reach many customers, not a handful clearing the deal.

The stack:

• Per-customer limit on the promo items.
• Maximum per order as a second ceiling.
• Store-hours / time window so the sale only runs when intended.

The gotcha: front-end "limit 1" banners are cosmetic — a shopper on an express wallet never sees the cart-page script. Enforce the cap server-side. Related: per-customer order limits.

The native wall: no native per-customer cap; the add-to-cart limit caps one cart, so repeat orders pass.

The recipes at a glance

Where native Shopify hits a wall

The recipes keep landing on the same wall, so it's worth stating plainly. Natively, Shopify gives you:

• One quantity control — a per-item, per-checkout add-to-cart limit (Settings → Checkout).
• B2B quantity rules — minimums and increments, but only in B2B/wholesale contexts, per variant, with no pooling across variants.
• Bot CAPTCHA on logins and high-risk forms.

That's it. There is no native store-wide minimum, no per-customer-across-orders cap, no store-hours checkout block, no cutoff, no per-day capacity, and no way to combine any of them. Historically some merchants bridged the gap with Shopify Scripts, but Scripts are being retired (checkout Scripts stop running in 2026) in favor of Shopify Functions — which is exactly the mechanism a modern rules app uses. The broad picture is in the complete guide to Shopify order rules.

How to build your own rule stack

Building a stack is the same five moves every time, whatever the recipe:

1. Scope it. Decide whether the rule hits the whole store, a collection, a product, or a variant — scope is what lets different products carry different rules.
2. Set the quantity rules. Minimum, maximum, step. Keep the minimum a multiple of the step.
3. Add the per-customer limit. Across orders, with login required so it attaches to an identity.
4. Add the timing rules. Store hours, cutoff, capacity — so orders only land when you can fulfill them.
5. Enforce and test. Run the whole stack at checkout via a Function, then test each rule by trying to break it.

Gotchas when stacking rules

The cross-cutting mistakes that turn a good stack into a support queue:

• Minimum above maximum locks the product — no quantity qualifies.
• A minimum without a step doesn't hold a pack size.
• Overlapping scopes double up — the stricter rule wins, sometimes surprisingly.
• Guest checkout defeats any per-customer limit — require login.
• Renewals aren't evaluated — subscription rules gate signups, not recurring orders.
• Timezone drift lets a far-away customer slip a cutoff — set times in the store's zone.
• Front-end-only limits are cosmetic — express wallets bypass them; enforce server-side.

Test your stack before it goes live

A stack you haven't tried to break is a guess. Before launch, place test orders that violate each rule in turn:

• One under the minimum and one over the maximum — both should block.
• A quantity off the step (7 against a step of 6) — should block.
• A second per-customer order on the same account — should block.
• An order after the cutoff or outside store hours — should block.
• An express-wallet checkout (Shop Pay) — confirm the stack still holds, not just the cart page.

Five minutes of trying to break your own stack catches the misconfiguration that would otherwise reach real customers.

The bottom line

Single rules are table stakes; the merchant problems worth solving live in the combinations — a minimum and a multiple and a cap and a cutoff, all true at once. The principle is simple (rules are AND-combined, the strictest wins), the recipes are just proven combinations, and the whole thing only works when it's enforced at checkout where it can't be bypassed. Find the recipe closest to your store, copy the stack, and test it by trying to break it.

Start OrderRules free, build your first stack, and let your checkout enforce exactly the orders you want — and quietly refuse the ones you don't.