Category guide
Promo abuse prevention for Shopify
Promo abuse, also called promotional abuse or coupon fraud, is the leak nobody puts on a balance sheet. The buyer is real, the card is real, the order ships. What is missing is the part where the discount was supposed to go to a new customer, or a referral was supposed to come from a different person, or the sample was supposed to ship to a different household. This page covers what the category actually includes, why Shopify cannot solve it on its own, and what enforcement at checkout looks like.
Published 21 May 2026. Updated 7 September 2026.
What counts as promo abuse: coupon fraud, referral fraud, loyalty fraud
The shortest definition that holds up: a buyer uses a promotional mechanic in a way the merchant did not intend, with their own valid payment. The buyer is not stealing a card. They are gaming an offer.
The reason this is its own category, separate from payment fraud, is that the existing fraud-prevention stack does not solve it. Signifyd does not solve it. Riskified does not solve it. Shopify's built-in risk score does not solve it. Those products are tuned for chargebacks and stolen cards. Promotional abuse leaves no chargeback trail. The order completes cleanly. The merchant just gave away margin to someone who was already going to buy.
The other reason this is its own category: it is structurally invisible to most merchants. There is no "promo abuse loss" line item in the Shopify admin. The discount was applied, the order shipped, the books balance. The loss is in the gap between "welcome discount spend per new customer" and "actual new customers acquired," and that ratio is one most merchants do not measure directly.
Six promo abuse patterns that account for most of the loss
From auditing 80+ Shopify Community threads and merchant interviews, these six show up over and over.
Pattern 1
Welcome-discount cycling
A returning customer enters a fresh email at guest checkout and claims your first-order discount again. Sometimes deliberately. Often not. Shopify sees a new email and applies the rule. The buyer was going to order anyway. You paid for the discount without getting a new customer in return.
How to catch it
Email normalization plus address or phone match. The buyer can change emails, but their shipping address tends to stay the same.
Pattern 2
Referral self-redemption
The sharer and the redeemer are the same person. Sometimes a buyer creates a second email to claim their own referral credit. Sometimes a single household runs the same trick. Loyalty and referral apps trust the identity at checkout. They do not verify it.
How to catch it
Match the sharer's identity against the redeemer's identity across all five signals. If they overlap on phone, address, IP, or device, withhold the credit. The order still ships at full price.
Pattern 3
Code leakage to coupon sites
A welcome code goes to Honey, Rakuten, RetailMeNot, or a Reddit thread. Strangers use it. The "first-order" gate fires for everyone because everyone is a first-order buyer of that one code. KeepCart and similar apps focus on the extension half of this. The identity-misuse half (people who already bought from you using the leaked code under a new email) is a separate problem.
How to catch it
Tie codes to identity, not just to discount-redemption count. Even if 10,000 strangers use the code once, none of your prior customers can redeem it again.
Pattern 4
Subscription intro-offer abuse
Buyer signs up, gets the intro price, cancels, signs up again under a new email. Repeats. This one annoys finance teams the most because the LTV math falls apart.
How to catch it
Match the subscriber's identity across email, phone, address, and device. The intro price is gated to first-time identities at the product or variant level, not first-time emails at the discount level.
Pattern 5
Free-sample stacking
Same household orders the trial-size SKU three times across the family. Sometimes the family is real. Sometimes it is one person with three emails. Either way, the unit economics on the sample go negative.
How to catch it
Fuzzy address match. "123 Main St Apt 4B" and "123 main street #4b" and "123 Main, Apt 4-B" resolve to the same address. Cap at the household level instead of the email level.
Pattern 6
Wholesale and VIP code use in guest checkout
Shopify's "specific customers" eligibility on a discount only fires when a buyer is logged in. In guest checkout, anyone with the WHOLESALER code can use it. The code leaks once and the discount becomes public.
How to catch it
Server-side validation of customer-tag eligibility at checkout, independent of login state. The check uses the same identity signals to know whether the guest buyer is the wholesale customer the code was issued to.
How to detect promo abuse at checkout
Every pattern above comes down to the same question: is this buyer someone who has ordered before? Email alone cannot answer it. These three checks, run together and server-side, can.
Email normalization and disposable domains
Strip Gmail dots and plus aliases, fold googlemail.com into gmail.com, and flag relay addresses from Apple Hide My Email, DuckDuckGo, and Firefox Relay. Disposable domains are refused outright. This alone catches the casual repeat buyer who thinks a new alias is a new identity.
Phone and address matching
Phones are compared on their last ten digits so +1, 001, and local formats all match. Addresses are compared at building level after expanding street abbreviations, removing unit designators, and collapsing ZIP+4. "123 Main Street Apt 4B" and "123 Main St #4B" are the same household. Billing address is checked separately, which is how a fresh shipping address with the same card holder gets caught.
Device fingerprint and visitor cookie
A web pixel records screen size, timezone, hardware profile, and browser client hints on the first page view, long before checkout. A first-party visitor cookie persists for a year. Incognito mode clears the cookie but not the hardware profile, which is why the two are kept as separate signals. Together with the IP address, they identify a returning device even when every typed field is new.
How the five signals combine into one decision: see the checkout flow.
Why Shopify's “limit one per customer” does not solve it
Shopify has three things that look like they should help. None of them do, fully.
The first is the discount-level "limit to one use per customer" toggle. It checks the email on the checkout, or the customer ID if the buyer is logged in. Both are buyer-controlled. A Gmail dot trick, a plus-alias, or a logged-out checkout all look new.
The second is the "specific customers" eligibility on a discount, which lets you restrict a code to a customer tag or segment. It only fires when the buyer is logged in. In guest checkout, the gate opens for everyone. Most wholesale-code leaks happen here.
The third is Shopify Flow and the post-purchase risk score. Both run after the order is placed. They can tag a flagged order, hold its fulfilment, or trigger a refund workflow. What they cannot do is stop the discount from being applied in the first place. By the time Flow fires, the offer is already gone.
The honest summary is that Shopify's discount engine was built around code redemption, not buyer identity. Every gap in this guide comes from that one architectural decision. The fix has to sit somewhere else.
What promo abuse prevention at checkout looks like
The pattern that holds across all six abuse modes above is the same: the surface identifier the buyer presents (an email, a customer account, a referral code) can be changed without effort. The harder signals (phone, shipping address, IP, device) tend not to change. Combining the easy signal with one or two hard ones gets you a reliable identity match.
The right place to do that match is inside Shopify checkout, before the order is placed. Shopify's Checkout Extensions API was built for exactly this. The check runs server-side, cannot be bypassed from the browser, and decides in under 100ms whether the buyer is who they say they are.
Five signals are usually enough. Email gets normalized: Gmail dots stripped, plus aliases collapsed, common providers canonicalized. Phone gets E.164-normalized and compared on the last ten digits. Shipping and billing address get fuzzy-matched so that "123 Main St Apt 4" and "123 Main Street #4" resolve as the same. IP and device signature combine into a probabilistic match, never a hard block on their own.
A composite score is more useful than any single signal. Block when two or more strong signals align (email plus phone, or address plus device). Warn when one strong signal aligns alone. Let it through when nothing does. False positives stay close to zero, which matters more than the catch rate does.
Rewards without referral fraud or loyalty points fraud
Most merchants think of promotional abuse prevention as a fraud problem. It is. But it is also half of the rewards problem, and treating them separately is what makes the leak persistent.
Your loyalty app pays out points to a buyer your fraud app never verified. Your referral app credits a sharer your fraud app never checked against the redeemer. The two stacks do not talk. The buyer behind a fresh email looks new to both.
The same identity check that catches abuse also decides who deserves the reward. Treating them as one question lets you run aggressive welcome offers, real referral incentives, and intro pricing without losing the margin to the buyers you do not want to reward. The same call that says "block this discount" also says "mint this reward token." OfferGuard ships both.
Where to start
If you have not measured the leak yet, that is the first step. Most merchants overestimate it once they think about it (a small group of determined abusers feels like a lot) and underestimate it before they think about it (the casual reuse is invisible). The numbers usually land somewhere between 3% and 12% of discounted orders, with welcome offers running highest and subscription intros close behind.
The free Watchdog plan on OfferGuard runs email-normalization checks on every checkout and flags matches. It costs nothing and runs in about 30 days of normal traffic before the picture is clear. Whether you go on to the paid tiers depends on what the picture shows.
Questions merchants ask about promo abuse
What is promo abuse (promotional abuse)?
Promo abuse, also called promotional abuse or coupon fraud, is the reuse, sharing, or gaming of promotional offers by buyers who do not qualify for them. The most common patterns are welcome-discount cycling (same buyer, fresh email), referral self-redemption, code leakage to coupon sites, intro-offer abuse on subscriptions, free-sample stacking to one household, and wholesale-code use in guest checkout. Most of it is technically allowed by Shopify's default settings, which is why it persists.
How is promotional abuse different from payment fraud?
Payment fraud is someone using a stolen card. Promotional abuse is someone using your offer in a way you did not intend, with their own valid payment. The buyer is real, the card is real, the order ships. The leak is in margin, not in chargebacks. Enterprise fraud platforms like Signifyd and Riskified focus on payment fraud and chargeback guarantee. Promotional abuse is a separate category and needs a different toolset.
Why does Shopify's built-in "limit one per customer" fail?
It checks the email on the checkout, or the customer ID if the buyer is logged in. Both are controlled by the buyer. A fresh Gmail address, a plus-aliased version of the same address, or a logged-out guest checkout all look like new customers to the setting. The buyer does not even have to be deliberate about it. Many will not realize they are bypassing anything.
Does promotional abuse prevention require turning off guest checkout?
No, and turning off guest checkout usually costs more in conversion than the abuse it prevents. The right approach is identity matching that works whether the buyer is logged in or not. Five signals (email, phone, address, IP, device signature) checked server-side at Shopify checkout will catch most of the abuse without forcing logins.
Can OfferGuard's free plan show me whether I have a problem?
Yes. The Watchdog plan runs email normalization on every checkout against your order history. Most of the abuse pattern shows up in the first 30 days as flagged orders where the same normalized email appears multiple times under different surface-level addresses. If that comes back small, you probably do not need to upgrade. If it comes back large, the paid tiers add the other four signals.
Is it illegal to abuse promo codes?
Usually not in the criminal sense. Reusing a welcome code under a second email or claiming your own referral breaks the offer terms, not the law, so the remedy is the merchant's: cancel the order, withhold the reward, or block the checkout. Counterfeit coupons and organised coupon rings are a different matter and have led to prosecutions. For a Shopify store the practical answer is enforcement at checkout, because chasing buyers after the fact costs more than the discount.
How do you detect promo abuse or coupon abuse at checkout?
Normalise the email (Gmail dots and plus aliases, relay addresses, disposable domains), match the phone on its last ten digits, compare the shipping and billing address at building level after stripping unit and abbreviation differences, and match the device against a passive fingerprint and a first-party visitor cookie set on the first page view. Any two signals matching a previous order is a strong repeat-buyer signal. All of it has to run server-side before the order completes, or it can be bypassed.
Related reading
Why Shopify's "Limit One Per Customer" isn't enough
The four enforcement modes (guest, logged-in, new-customer, lifetime cap) and where Shopify's built-in setting fails in each.
Best Signifyd alternatives for Shopify
Nine alternatives ranked by use case, with the line between payment fraud and promotional abuse drawn explicitly.
How to prevent discount code abuse on Shopify
Practical guide to email normalization, guest checkout protection, and the detection methods that actually work.
The eight discount-abuse patterns OfferGuard handles
Side-by-side breakdown of each pattern with the merchant quote and the rule that catches it.