Category guide
Promotional abuse prevention for Shopify
Promotional abuse 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.
What counts as promotional abuse
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.
The six patterns that account for most of it
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.
Why Shopify alone 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 durable enforcement 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.
The reward half of the same question
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.
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.