# Limit quantity per customer, not just per order > Source: https://primemoq.app/case-studies/limit-quantity-per-customer > Language: en Prime MOQ counts a customer's order history, not just the cart in front of them, so a repurchase limit caps what one buyer can take across separate orders. Set it per day, week or month, and schedule the rule to arm and disarm around a release window. A collectibles brand runs limited releases. They already cap each order at 2 units, and for a while that looked like enough. Then the resellers learned the shape of the cap. Two units, checkout, then straight back for another two, and another. Six orders later one buyer holds twelve units, every order individually within the rules, and the team spends two days cancelling them by hand. A repurchase limit counts a customer's history rather than their current cart. Two every 30 days means the second order is refused, so the drop stays fair without anyone watching the order feed. ## The rule: 2 per customer every 30 days - Limit type: Quantity - Scope: Collection: drops - Maximum: 2 units - Repurchase limit: 2 per 30 days - Schedule: Arms at drop time ## What you get - Repurchase limits count order history, so a second order cannot undo the first cap. - Fair drops without manual cancellations or refund storms. - Schedule rules so they arm and disarm around the release window. ## Merchant profile A collectibles brand running limited releases. Each drop is a fixed run with no reprint, announced in advance, and the audience is larger than the run on purpose. Scarcity is the product. The brand is not trying to sell out faster, it is trying to sell out fairly, because a release that lands entirely with resellers damages the thing that made the next release worth waiting for. ## The challenge A cap of two per order looked sufficient until the resellers learned its shape. Two units, checkout, then straight back for another two, and another. Six orders later one buyer holds twelve units and every single order was individually within the rules. The team spends two days unpicking them by hand, which means cancelling real customers by mistake as well. ## What they needed - Cap what one person can take across a release, not merely what they can take in one transaction. - Have the rule apply only during the release window, so it does not quietly throttle the product months later. - Remove the manual review entirely, because reviewing an order feed by hand is both slow and unfair to the orders reviewed last. ## Why it costs money The cost of a drop taken by resellers is not measured in that drop. It is measured in the next one, when the people who missed out do not come back, and in the secondary market that trains buyers to wait rather than to buy. Manual cancellation has its own cost, and it is worse than it looks. Two days of staff time, a queue of refunds, and a handful of genuine customers cancelled by mistake, each of whom now has a story about the brand. ## Approaches that fail ### Lowering the per-order cap to one It halves the reseller's throughput and does not stop them, because the constraint was never the size of a single order. Meanwhile every genuine buyer who wanted a pair for a friend is now blocked. ### Reviewing the order feed and cancelling by hand It is slow, it scales with the size of the drop, and it is applied unevenly because the orders reviewed last get a different standard than the ones reviewed first. It also cancels real customers who happen to look suspicious. ### Blocking addresses or payment methods after the fact It is a game of whack-a-mole against someone who can change both cheaply, and every false positive lands on a real customer who did nothing wrong and has no way to appeal before the drop ends. ## Weighing the options | Approach | Stops repeat orders | Runs without staff | Fair to real buyers | | --- | --- | --- | --- | | A lower per-order cap | No, only slows it down | Yes, but it does not work | No, it punishes normal buyers | | Manual review and cancellation | Partly, and slowly | No, it is entirely staff time | No, it is applied unevenly | | A repurchase limit with a schedule | Yes, it counts order history | Yes, once configured | Yes, the same rule for everyone | ## The rule they chose A repurchase limit counting a customer's order history across a window, set alongside the existing per-order cap. The two answer different questions: one asks how much is in this cart, the other asks how much this person has already taken. The rule is scheduled to arm when the drop opens and disarm when it closes. Scheduling matters more than it sounds, because the common failure is not a missing rule but a drop rule left switched on for months, capping a product that no longer needs protecting. ## What the buyer sees The limit is stated up front as part of the release terms, not discovered at checkout. For a drop this is the difference between a rule that feels fair and a rule that feels like a trap. A buyer who has already taken their allocation is told so plainly, which is more useful than a generic failure and considerably less likely to generate a support ticket. ## What could go wrong - Risk: The limit needs an identifiable customer to count history Mitigation: Require an account for limited releases. It is also what makes the limit meaningful, since a rule that counts history cannot count the history of someone who leaves none. - Risk: A reseller uses several accounts Mitigation: A repurchase limit raises the cost of that rather than eliminating it. Pair it with account requirements and a per-order cap so each additional account buys less than the last. - Risk: The rule is left armed after the drop Mitigation: Schedule the disarm at the same time you schedule the arm, so the end of the window is configured rather than remembered. ## What to take away - A per-order cap and a per-customer cap solve different problems, and shipping only the first invites exactly the behaviour it was meant to prevent. - Counting history is what closes the loop, because anything evaluated on a single cart can be defeated by using more carts. - Schedule the end of a rule when you schedule its start, or the drop rule becomes a permanent one nobody remembers setting. ## Questions merchants ask ### How do I limit how much one customer can buy over time? Use a repurchase limit, which counts a customer's order history rather than only the cart in front of them. Set the ceiling and the window, such as two units every 30 days, and a second order that would breach it is refused at checkout without anyone reviewing the order feed. ### How is this different from a maximum per order? A per-order cap looks at one cart, so a reseller can simply check out repeatedly and stay within the rules every time. A repurchase limit looks across orders in a window, which closes that loop. Most drops want both: a ceiling per order and a ceiling per customer. ### Does a repurchase limit work for guest checkouts? It needs an identifiable customer, because it counts history. Requiring an account for a limited release is the usual answer, and it is also what makes the limit meaningful: a rule that counts history cannot count the history of someone who leaves no history. ### Can I turn the limit on only during a drop? Yes. Rules can be scheduled to arm and disarm at set times, so the limit covers the release window and lifts afterwards. That avoids the common failure of a drop rule left switched on for months, quietly capping a product that no longer needs protecting. ### What window lengths are available? Per day, per week or per month, counted against the customer's recent orders. Choose the window to match the release cadence rather than the calendar: a monthly drop is well served by a 30 day window, while a weekly restock needs a shorter one to stay fair. ## Topics covered - Repurchase limits - Per-customer purchase caps - Order history counting - Scheduled rules - Limited releases - Reseller prevention