I’m a developer scoping a new app and want to verify a problem before I build. Searching this forum I found multiple threads from 2021 to 2025 asking the same thing:
“How to Limit a Customer to Purchasing a Product Only Once (Lifetime Limit)?”
“Limit one per customer (and NOT per checkout)”
“Product lifetime limit for guests”
“Purchase once per year”
A Shopify staff reply on one of these threads said the leading app (MinMaxify) “does not allow for customer limits or limits across multiple orders for a customer.” MinMaxify’s own developer acknowledged the same in another thread. KOR Order Limits’ lifetime mode only works for logged-in customers. Evlop has 2.5 stars and multiple reviews saying it stopped working.
So the question for the community in 2026:
1. Do you still need this? If you sell limited drops, samples, intro offers, regulated goods, or anything where one customer = one purchase ever - what app are you using today, and what’s failing?
2. What’s the bypass scenario that hurts you most?
Customer completes one order, then opens a new cart and buys again
Guest checkout (no account, no tracking)
Apple Pay / Google Pay / Shop Pay express checkout
Same person with two email addresses or two shipping addresses
3. Would you pay a monthly app fee for a focused fix? What’s your range - $5, $10, $20?
I’m aware Shopify Functions now exposes a cart.validations.generate.run target that lets apps block checkout server-side (including express checkouts). That’s the technical reason this is finally solvable correctly in 2026 vs 2021. But I don’t want to build it if the demand has moved on.
Honest reply welcome - including “we figured it out with Flow” or “switched off Shopify.”
Honestly, even if you did implement a one-time purchase per customer, there’s nothing stopping them from buying with a different email…
That said, there are checkout rules apps that can block a customer from checking out if certain criteria is met. This criteria would most easily be a tag. i.e. customer buys product a, customer gets product_a tag, on a future purchase a checkout rules app like SMART or Blockify reads the tag and blocks the customer from completing the purchase and shows a custom message.
Already doable in the most basic way, but if you want to create an app just for one-time purchasing or whatever, and make it more streamlined, go for it.
It’s still a real gap, and the reason those 2021 to 2025 threads never got a clean answer is two-fold. Native discount and order-limit logic caps usage per code or per checkout, not across a customer’s full purchase history. To enforce a true lifetime limit you have to look up every past order for that customer at the moment of checkout, and checkout validation doesn’t get clean access to historical order data without your own backend indexing purchases by customer.
The harder half is identity. Like Maximus said, email is trivially bypassed with a second address, and guests have no stable identity at all, which is why the guest version is basically unsolvable without forcing account creation. Anchor on a required customer account and you can make it solid, anchor on email and it leaks.
What identity are you planning to key off, and are you ok requiring login to buy? That one decision pretty much decides whether this is buildable or whack-a-mole.
Fair point on the email bypass and lumine raised the same below and it’s the core problem! On the tag-based approach via SMART/Blockify- yes, that pattern works for slow buyers, but it has a race condition. The customer tag is written after the order completes, so a customer can place two orders 30 seconds apart (or within the same session via “Buy now → back → Buy now”) and both complete before the tag exists. Server-side cart-validation via Functions runs before payment captures, querying purchase history at validation time… so the race is closed.
Curious.. are you running a store with this pain today, or evaluating from a builder angle? Either way useful, just helps me weigh the signal.
This is the right question and I appreciate you cutting to it. Honest answer: the only enforcement that’s truly bulletproof is required customer accounts + verified email… and yes that costs conversion. So the realistic product has to be tiered, with the merchant picking their tradeoff:
Standard: guest checkout allowed, identity keyed on normalized email + billing-address hash + (optionally) device fingerprint. Catches the casual “second account” abuser, leaks against a determined adversary. ~95% effective in real-world data for limited drops.
Soft: visible “limit 1 per customer” copy at PDP/cart + email-only check + post-purchase fraud flag. Honor system with a paper trail. ~70% effective, zero conversion drag.
The bet is that most merchants who ask for this aren’t trying to stop a coordinated reseller botnet.. they’re trying to stop the same person ordering twice on a sample box or a discounted intro pack. For that, Standard wins. The merchants who need Strict already know they need it.
Question back to you: in your experience, do merchants who ask “lifetime limit” actually want bulletproof, or do they want “good enough that the support tickets stop”? Those are different products.
I build the per-order version of this (Mastiff), not the lifetime one, so this is a builder’s view rather than a pitch. Per order is settled: a checkout validation function rejects the order whichever button they used, express wallets included. Lifetime is the part nobody has done properly, and your race condition is why. A tag written after the order completes is always too late for a second order placed a minute later. The only version that really stops it reads order history at checkout, which needs protected customer data approval and a required login. That’s the conversion cost you already named, so your tiered plan looks right to me. Most merchants asking for this want the obvious repeat buyer stopped, not a guarantee, and they’ll take guest checkout being imperfect if you tell them up front.