A purchase limit is one of the plainest promises a store can make. Two per customer, so everyone gets a fair shot at the drop. One per household, so the allocation you fought your supplier for actually reaches new customers instead of a handful of resellers. It is the kind of rule a shopper reads on the product page and nods at, and the kind of rule a merchant assumes the platform will hold up. So you set the cap, you launch, and the product sells out in the first few minutes exactly as you hoped. Then you open the orders list and the good news curdles: the same name, or the same address, or the same card, over and over, each order neatly at or under your limit, adding up to a stack of units that was supposed to be spread across dozens of people. The cap you advertised did nothing, because Shopify never counted the customer. It only ever counted the cart.
This is the quiet reality of running any allocation-limited product on Shopify, and the merchant communities are full of the same question asked a dozen ways. How do I limit quantity per customer. How do I stop one person buying all my stock. Why does my two-per-order limit let someone place ten orders. How do I enforce one per customer during a launch. The answers underneath are always some shape of not natively, use an app, or write a checkout function. The merchant is not asking for anything exotic. They want the obvious thing every fair drop depends on: the limit is per person, so the store recognizes the person, and the forty-first unit to the same buyer simply does not go through.
Shopify can cap how many units fit in one cart. It cannot cap how many carts one customer fills. So the limit you advertised holds for the honest shopper who reads it and does nothing to the reseller who was always going to place ten orders.
What Shopify does and does not do about purchase limits
Give Shopify credit for the part it does, because it is real and it is where the confusion starts. Shopify has a native add-to-cart limit, set under checkout preferences, that caps the maximum quantity of a given product a shopper can put in their cart in one order. If you never want more than one of an item to leave in a single order, you can set it, and the cart will refuse the second. For the narrow case of stopping an obvious over-buy in a single transaction, it works, and it is worth turning on.
The trouble is that a per-cart limit is not a per-customer limit, and the gap between the two is exactly where every drop leaks. The native limit runs into three walls the moment you are trying to protect a real allocation. First, it is per variant, not per product or per customer. The cap applies to each variant independently, so a tee sold in three colors with a limit of two lets one shopper take two red, two blue, and two green in the same cart, six units against a limit that reads like two. Second, it resets on every order. The limit lives on the cart, so the instant a checkout completes the counter is gone, and the same person can start a fresh cart and buy again, and again, with nothing tracking the running total across their orders. Third, it does not know who the customer is. The rule never looks at email, address, card, or account, so it cannot tell that twenty separate orders are one buyer, and it does not apply at all in Shopify POS, on draft orders, or for B2B profiles.
The limit Shopify enforces per cart but never per customer
The heart of a purchase limit is a single move Shopify does not make: recognize the buyer across orders, keep a running count of what they have already taken, and refuse the order that pushes them over. That is what makes a limit a limit. Everything Shopify gives you stops one step short of it. The add-to-cart rule can guard a single cart, but the counting resets the moment that cart is paid for, and no native setting ties this order to the last one from the same person. So the merchant, or a theme edit, or an app becomes the thing that has to remember the customer, and that is exactly the work that is fiddly to build and easy to evade. It is the same shape of gap as the minimum order Shopify will not enforce: the platform can describe a rule about one cart but has no reliable native hook to enforce it against a customer on every path they take to checkout.
And that phrase, every path, is where the usual fix quietly fails. The common workaround is code on the product or cart page that blocks the button once the quantity is too high. But a modern Shopify store has many doors into checkout that never touch that page: the Shop Pay, Apple Pay, and Google Pay wallet buttons that jump straight from the product page, a buy-it-now button, a saved cart link, a checkout permalink shared in a group chat where the resellers trade them. A limit enforced by cart-page code is simply absent on all of those, the very paths a determined buyer will use. Underneath even that sits the harder problem, which is identity: a limit that keys off a logged-in account is walked around with a guest checkout or a second email, and one that keys off a browser cookie is beaten by an incognito window or a cleared cache. The people you most want the limit to stop are the ones most willing to open a new tab.
Why the usual workarounds don't hold
Faced with a platform that can cap a cart but will not cap a customer, merchants reach for a handful of moves, and each one gives back something you did not want to lose.
"I will use the add-to-cart limit." The right tool for stopping an obvious over-buy in one cart, and the wrong shape for protecting a drop. It counts each variant on its own, so a shopper takes the maximum of every size and color at once, and it resets the moment the order is placed, so the same buyer just checks out again. You have capped the cart and left the customer completely uncapped, which on a hyped product is the difference that matters.
"I will add cart-page code." The classic fix, and the one that leaks. A script that blocks the checkout button above a quantity works on the cart page and is invisible on every other path into checkout, so the wallet buttons, the buy-it-now flow, and the shared checkout link all skip it, the same blind spot that undoes a cart-page minimum. It also breaks on the next theme update, and because it only sees the cart in front of it, it never counts what the same person bought an hour ago in a different session.
"I will require accounts and limit by login." Reasonable instinct, easily evaded. Forcing shoppers to log in lets you tie a limit to a customer record, but it also adds friction that costs you real conversions, and it does nothing to the reseller who simply signs up with a second email, a third, a burner for each order. An account-based limit stops the honest customer who was never the problem and waves through the practiced buyer who is.
"I will build a Flow." Reasonable instinct, wrong tool for the enforcing part. Shopify Flow reacts to an order after it is placed, so it can tag or even cancel an order that looks over the line, but it fires one order at a time and cannot natively hold a running per-customer total across orders or block the checkout before the money moves. It can help clean up afterward, which matters, but it cannot be the thing that stops the over-limit order from going through in the first place, and by the time it acts the unit is already off the shelf.
"I will install an order-limit app." Often the right call, and still a fixed rulebook bolted to your store. The good ones do enforce a per-customer cap, and the best use a server-side checkout validation so the wallet-button paths are covered, which is real progress and proof the native gap exists. But an app applies the rules you set in advance the same way to every order: it does not notice that two orders to the same building are a genuine couple rather than one reseller, that a wholesale account should be exempt from the retail cap, that an order is a gift going to a different address, or that a near-match is too uncertain to cancel on automatically. It enforces. It does not judge.
What the automation actually has to do
The real job is not "cap the cart." It is "recognize the buyer across their orders, keep a running count against the limit for this product and this window, refuse the order that goes over on whatever path they take to checkout, undo the ones that slipped through by canceling and restocking the excess, tell the customer plainly, and pull in a human only for the calls that are genuinely judgment." That is a read, an identity match, a decision, an action at checkout, and a set of corrections after the fact. As a Dugong playbook, in plain prose, it reads like this:
# trigger
On a new order or checkout
# steps
1. Read the items and quantities, and the per-customer
limit for this product, collection, and launch window
2. Identify the buyer across orders: email, shipping
and billing address, payment fingerprint, account, device
3. Decide if this order takes them over the limit once
you add what they already bought in the window
4. Enforce at checkout on every path in: cart, wallet
buttons, buy-it-now, saved links, checkout permalinks
5. Clean up what slipped: cancel or trim the excess,
refund it, restock the units for real customers
6. Tell the customer the limit clearly and confirm
kindly when an order was trimmed to the cap
7. Hold a shared-address household, a wholesale exempt,
a gift, or an uncertain match for a humanSeven lines. The compiler fills in the rest: matching a new order to past ones across several weak signals instead of one exact key, holding a running total per customer across a launch rather than resetting each cart, enforcing at the checkout itself so a wallet button cannot slip a bulk order past the cart-page rule, and undoing the over-limit orders that did land by canceling the excess and putting the units back on the shelf. The merchant never wrote a line of theme code or a checkout function. They described how a careful launch manager would guard the allocation, and let the compiler run it on every order, in real time.
Why this is a compiler problem, not an app problem
There are capable order-limit apps on the Shopify App Store, and a store running drops should look at one. But the thing that makes a purchase limit hold is not one more quantity field. It is judgment about each specific order: is this the same buyer as that earlier order or just a coincidence of name, is this second order to the same street a household or a reseller, should this account be exempt because it is wholesale, did this order slip past the cap and need its excess canceled and restocked, and is the limit landing on the wallet-button path as well as the cart. Those answers change per order, per customer, and per minute of a launch, which is exactly what a fixed rulebook handles badly and a person cannot watch across a flood of orders at once. It is the same reason reading a burst of orders as an attack resists a single setting: the right call lives in the pattern across orders, not in one threshold on one cart.
A natural-language compiler fits because a purchase limit was never a single action. It is a read of the order, an identity match against everything the same buyer has done, a decision about whether this one goes over, an action at the checkout on whatever path they took, and a stream of corrections for the orders that got through. You can describe the whole behavior in a paragraph. You could never keep up with it by hand across every order, every checkout path, and every fresh email a reseller invents. It sits in the same family as the product drop that will not go live on time, where a launch is only as good as the mechanics running underneath it, and the overselling problem no one automates, where the whole point is keeping the true count of a scarce thing honest in real time.
The workflow worth building this week
If you run drops, flash sales, collabs, or any product where you have promised a limit per customer and later found one buyer took a stack of it, this is the automation to set up now, because a limit that fails does its damage on exactly the products you cared most about protecting. It pairs naturally with the launch and scarcity work we have written about, like the product drop that will not go live on time, since a limit and a launch have to fire together, and the minimum order Shopify will not enforce, which is the same enforce-on-every-checkout-path problem pointed the other way, and it feeds the same flywheel as the Shopify automations no one builds, where the work that compounds is the part merchants never get to.
Describe it the way you would brief a careful launch manager: watch every order, figure out who the buyer really is across their orders, keep a running count against the two-per-customer cap for this drop, refuse the order that goes over on whatever path they used, cancel and restock anything that slipped through, tell the customer kindly what the limit is and when an order was trimmed, and bring me anything where a shared address might be a real household, a wholesale account should be let through, or the match is too close to call. That is the whole brief. The compiler does the reading, the matching, the deciding, and the corrections, on every order, in real time. Your real customers get a fair shot at the drop, and the reseller who was going to place ten orders gets one.
If you are a Shopify merchant who has built something that holds a real per-customer limit through a
hyped drop and still lets the genuine household order through, or you have a story about a launch a
handful of buyers cleared in minutes, the inbox is open:
field-notes@dugong.live. We are collecting case studies for the next issue.