A per-order maximum stops one large order. It does not stop ten small ones. To stop a customer accumulating more than their share of an allocated product, you need a limit that counts across orders — either a lifetime cap ("two per customer, ever") or a time-window cap ("three per 30 days"). Both depend on identifying the customer, which means a customer account, and neither is uncircumventable. What they do is raise the effort enough that casual bulk-buying stops.
Three limits that sound similar and are not
- Per-order maximum. "No more than two in this cart." Evaluated on one cart, remembers nothing. Stops the obvious grab and nothing else.
- Lifetime cap. "Two per customer, ever." Counts every order that customer has placed. Right for genuinely allocated products.
- Time-window cap. "Three per customer per 30 days." Resets. Right for consumables, where a permanent cap punishes a genuine repeat buyer.
Choosing between the last two is the decision that matters, and it comes down to one question: would a real customer legitimately want another one later?
For a limited-edition print, no — two is the allocation and it is permanent. For a supplement someone takes daily, obviously yes, and a lifetime cap turns your best customer into someone who has to email you.
Sizing the window
If a time-window cap is right, the window should match how long the product lasts.
A month's supply sold three at a time with a 30-day cap tells a customer they may buy three months' worth every month, which is not a limit. The same product with a 90-day cap matches consumption and stops stockpiling without inconveniencing anyone buying normally.
The way to get this right is to look at your own repeat-purchase interval rather than picking a round number. If your median gap between repeat orders is six weeks, a cap over eight weeks is generous and one over four is a support ticket.
What these rules actually rely on
Both count against a customer, which means the customer has to be identified — a logged-in account, or at minimum an email that matches a previous order.
That has consequences worth deciding rather than discovering:
- Guest checkout. If guests can buy, a cap is only as good as the email they type. Many stores require an account for capped products specifically, which is a reasonable narrow requirement.
- Multiple emails. A determined reseller will use several. No app on the Shopify App Store can honestly claim otherwise, and one that does is overstating.
- Households. Two people at one address with two accounts are two customers by any rule you can implement, and often one buyer in practice.
So be clear about the goal. These rules make casual over-buying stop and make systematic over-buying more work. They do not make it impossible, and a policy written as though they do will produce arguments you cannot win.
The message when someone hits the cap
A shopper blocked by a limit they did not know about, on a product they already own, needs more explanation than a shopper blocked by a minimum.
What the message should contain:
- The limit itself. "Limit 2 per customer."
- Where they stand. "You have already ordered 2." Without this, a customer who ordered months ago has no idea why they are blocked.
- Whether it resets, and when. "This limit resets on 14 October" turns a refusal into a wait.
- A route if they have a reason. A contact link, for the genuine case you did not anticipate.
That last one matters more than it looks. Caps produce false positives — a customer buying gifts, a small business buying legitimately — and a dead end converts a good customer into a bad review.
Say it before the cart
Enforcement belongs at checkout. Communication does not.
A limit stated on the product page — "Limit 2 per customer" — does three things a checkout block cannot. It sets expectation before effort is invested. It signals scarcity, which on an allocated product helps rather than hurts. And it removes most of the support contacts, because the answer was on the page.
Stores that hide the limit until checkout get the enforcement and none of the benefit.
Where the rule has to live
A cap that counts across orders cannot be enforced in your theme, because the theme does not know the customer's order history at the moment that matters and can be skipped entirely.
It has to be evaluated at checkout, which on Shopify means a Function. That is the same requirement as any other quantity rule, and the same test applies: build a cart permalink that violates the cap and see whether you reach payment. If you do, the rule is decorative.
Worth knowing: rules that ran on Shopify Scripts stopped executing on 30 June 2026. If you had a per-customer cap and have not checked it since, check it.
Refunds, cancellations and the count
A detail that surfaces about a month after any cap goes live: does a refunded order still count against the customer?
Both answers are defensible and they produce different outcomes:
- Refunds release the allocation. Fair to a customer whose order was cancelled because you could not fulfil it, and it is the behaviour most people expect. It also creates a loophole: buy, refund, buy again.
- Refunds do not release it. Closes the loophole, and punishes a customer whose order you cancelled through no fault of theirs.
The workable answer for most stores is to release on your cancellations and hold on customer-initiated returns, which matches who caused the outcome. Whether your app can express that distinction is worth checking before you need it.
The same question applies to orders that were never paid — an abandoned or failed checkout should obviously not consume an allocation, and an app counting attempts rather than orders will produce complaints you cannot reproduce.
When a cap is the wrong tool
Three situations where a limit is treating a symptom:
- The product is underpriced. If resellers are buying because they can profit, a cap slows them down and the price is still wrong.
- Demand is structurally higher than supply. A cap rations; it does not create stock. If every drop sells out in minutes, the conversation is about allocation, queuing or production, not limits.
- You want the wholesale revenue but not the wholesale terms. Bulk buyers who want quantity are customers. A cap turns them away; a wholesale tier sells to them on your terms.
Caps are right when the goal is distribution — getting a limited product to many customers rather than a few — and that is a narrower goal than "stop resellers".
Setting it up
- Pick lifetime or window using the "would a real customer want another later" test.
- Size the window from your actual repeat interval, not a round number.
- Decide on guest checkout for capped products.
- Write the message with the limit, their position, the reset and a contact route.
- State it on the product page.
- Test with a second order from the same account, not a bigger single one — that is the case the rule exists for.
With Limit, lifetime and time-window caps are on the $9.99 plan, with checkout enforcement on every plan including the free one.
Where to go next
If the aim is protecting a launch rather than a permanent allocation, a scheduled cap is usually better than a lifetime one — covered in quantity guardrails for flash sales. The wider picture on scopes and enforcement is in the MOQ guide.
