Troubleshooting

Restriction or limiter isn't blocking

Why a cart restriction or product limiter doesn't enforce — or fires when it shouldn't — and how to fix each cause.

This is the inverse of "a discount won't apply": you built a restriction or a limiter to stop something, and the shopper sailed through anyway — or your rule blocks the wrong carts. Restrictions and limiters run inside Shopify's checkout validation, so when enforcement misbehaves the cause is almost always a setting that quietly switches the rule off. Find your symptom below, confirm the cause, apply the fix.

Restrictions and limiters never run backend calls at checkout. They read a metafield that the app syncs from your admin. If a recent change isn't enforcing, the first thing to suspect is a stale metafield — jump to General fixes and force a Sync.

Symptom: my restriction never fires

You added a restriction, the cart clearly matches its rules, and the shopper still checks out. Walk these causes in order — most "dead" restrictions are caught by the first three.

CauseWhat's happeningFix
Status is DraftA new restriction defaults to Draft, and only Active restrictions are pushed to Shopify with enforcement enabled.Open the restriction and switch its status to Active.
No rules addedThe extension skips any restriction with zero rule groups — an empty restriction is treated as "nothing to check."Add at least one rule group with one rule.
Neither stage enabledIf both Run on cart and Run at checkout are off, the restriction has nowhere to run.Enable Run on cart, Run at checkout, or both.
Outside the scheduled windowA restriction with a date range only fires between its start and end.Confirm the current date is inside the window, or clear the range.
Customer-tag rule, guest shopperA Customer tag rule can only evaluate a logged-in customer. A guest has no tags, so the rule can't match.Test logged in as a customer who carries the tag.
Market excludes the shopperIf the restriction is scoped to specific markets, shoppers outside them are never evaluated.Widen the market scope or test from a targeted market.
Metafield not synced yetEdits sync to Shopify asynchronously; for a brief window the old (or missing) rules are still live.Use Sync/re-save, wait a few seconds, retest.

The most common dead restriction is Draft status combined with no rules — both are the defaults on a brand-new restriction. A restriction with an empty rule list is silently skipped even when it's Active, so adding the first rule and flipping to Active are two separate steps you must both complete.

Recipe: "minimum $50 to check out" that does nothing

You created a "require $50" restriction but small carts still reach checkout.

Confirm it's Active, not Draft

Open the restriction. If the badge reads Draft, switch it to Active and save.

Confirm a rule exists

You need a Cart total (or Cart subtotal) rule with a matcher like is less than 50. An empty restriction never fires.

Confirm a stage is on

Set Run at checkout on so the cart is checked when the shopper proceeds. Enable Run on cart too if you want the block to appear earlier, in the cart.

Sync and test in incognito

Force a Sync, then test in a private window with a sub-$50 cart.

Symptom: it fires at the cart but not at express checkout

A shopper is correctly blocked in the cart drawer, then breezes through Shop Pay, Apple Pay, or another express button without ever hitting the error.

This is a stage problem, not a bug. The two toggles are independent:

  • Run on cart evaluates the restriction when items are added or quantities change in the cart.
  • Run at checkout evaluates it when the shopper proceeds to checkout — including express and accelerated buttons, which skip the cart page entirely.

If only Run on cart is enabled, express buttons that jump straight to payment are never checked.

Express and accelerated checkouts (Shop Pay, Apple Pay, Google Pay, PayPal) bypass the cart page. A restriction that runs only on the cart will not stop them. Enable Run at checkout so enforcement happens inside Shopify's checkout validation, where express flows are still covered.

See Restrictions & limiters with express checkout for exactly which buttons hit which stage.

Symptom: the wrong or a blank message shows at checkout

The restriction blocks correctly, but the text the shopper sees is generic or empty.

CauseWhat the shopper seesFix
English message is emptyWhen no English message is set, the app falls back to a default string: "Please review your cart before continuing."Fill in the English error message body.
Shopper's locale has no translationIf you wrote a message for the shopper's language but later removed it, the checkout falls back to your English text.Add a translation for that language, or rely on the English fallback.
You edited the error titleThe error title field is stored with the restriction but is not displayed to shoppers at checkout.Put the full explanation in the error message body, not the title.

English is the fallback language. If a shopper's locale has no message, they get your English text — and if your English text is blank, they get the generic default. Always set the English message body, even if your store is primarily another language.

Symptom: a limiter isn't enforcing

You set a maximum (or minimum) on a product but the shopper still over- or under-orders.

CauseWhat's happeningFix
Limiter is inactiveOnly active limiters are written to the enforcement metafield.Activate the limiter.
No min and no maxA limiter with neither a minimum nor a maximum has nothing to enforce, so it's dropped from the metafield entirely.Set a maximum, a minimum, or both.
Wrong scope chosenA SKU limit can't match a product that has no SKU; a Product limit checks each variant separately rather than capping a "combined family" total.Pick the scope that matches your intent (see Counting & priority).
Higher-priority match masks itLimiter priority is SKU > Variant > Product. If a SKU or variant limit also matches the line, your product-level limit never applies to it.Remove the overlapping higher-priority limiter, or move the cap up to that level.
Too many limitersThe enforcement metafield is capped at 10,000 characters. If your active limiters exceed that, a warning is logged and some limits are not written.Reduce the number of active limiters until you're under the cap.

The Product scope is not a "whole family" cap. A product-level limit of 3 on a T-shirt is checked per variant — the shopper can hold 3 Small and 3 Medium and 3 Large. If you expected the combined total across variants to be capped at 3, the Product limiter cannot do that; use a cart restriction with a quantity rule instead.

If you have many active limiters and one near the end of the list stops enforcing, you've likely crossed the 10,000-character metafield size limit. The app logs a warning and silently skips the limits that didn't fit. Deactivate limiters you no longer need to bring the total back under the cap.

Symptom: the limit blocks more or less than expected

The limiter enforces, but the threshold it applies surprises you. This comes down to how lines are counted and which scope wins.

How quantities are counted

Cart lines are grouped by product + variant and their quantities summed before the limit is checked. If a shopper has the same variant on two separate lines (for example, added at different times), those quantities add together against one limit — they aren't treated as two independent lines.

Which scope is applied per line

For each cart line, exactly one scope decides the limit, using this priority:

SKU limit (highest)

If the line's SKU has a limit, it's used and the variant/product limits are ignored for that line.

Variant limit (next)

Used when no SKU limit matches the line.

Product limit (lowest)

Used when neither a SKU nor a variant limit matches — and applied to each variant individually.

Because only one scope wins per line, a Product limit and a Variant limit don't add up. A line with a matching variant limit is governed by that variant limit alone; the product limit applies only to the other variants that have no limit of their own.

Symptom: a discount made my min-spend restriction block unexpectedly

A "minimum cart total" restriction starts blocking carts that should qualify, but only once a discount is on the cart.

The cause is which amount your rule reads:

  • Cart subtotal is the amount after discounts. A discount can pull the subtotal below your threshold and trip the restriction.
  • Cart total is the amount before discounts.

If your "spend $50" rule is built on Cart subtotal, a $10 discount on a $55 cart drops the measured value to $45 and the restriction fires.

Switch a minimum-spend restriction from Cart subtotal to Cart total if you want the threshold measured on the pre-discount amount. Otherwise discounts will count against the shopper's qualifying spend.

Symptom: I hit the 20-restriction or 25-validation ceiling

You try to activate another restriction and it won't turn on, or new validations stop being created.

There are two limits stacked on top of each other:

  • Shopify's platform ceiling — a store can have at most 25 active cart validation rules total, across all apps.
  • The app's per-plan limit — the app caps active restrictions below that ceiling (the Enterprise plan allows up to 20).
PlanActive restrictions
Free1
Starter5
Growth10
Pro15
Enterprise20

If another validation app (a different checkout-rules or fraud app) is consuming Shopify's 25 slots, you can hit the platform ceiling even while you're under your plan limit. Remove or deactivate cart validations you don't need — in this app or others — to free a slot. Deactivating a restriction releases its slot immediately.

See Plans & billing for the full plan comparison.

General fixes

When you've ruled out the symptom-specific causes above, these three resolve most remaining cases.

Where to go next

If a restriction or limiter still misbehaves after these steps, contact support with your store URL, a screenshot of the rule's settings, and the test cart that should (or shouldn't) be blocked.

On this page