How to prevent promo abuse in ecommerce

Promo abuse is one shopper claiming a discount meant to be claimed once, many times, by spinning up accounts that each look like a new customer. You prevent it not by blocking coupon codes or IP addresses, which an abuser swaps for free, but by reading the device and network behind each redemption, scoring how new the shopper really is, and acting on that score before the discount applies.

Some parts of an account a shopper can swap and others stay put: the email, the coupon code, and the IP all change between accounts, while the device behind them does not. This guide covers the ecommerce-specific tactics, the signals that expose them, and how to read a redemption at the moment it happens. It is the ecommerce view of the broader offer-abuse mechanic; the casino-bonus version of the same problem plays out in how to prevent bonus abuse in iGaming, and the full account-side picture a store faces is mapped in account and offer abuse in ecommerce.

Key takeaways

• Promo abuse is one customer presenting as many to claim a first-order discount, promo code, or referral payout repeatedly. It quietly drains a marketing budget meant to win new buyers.
• The ecommerce tactics have their own shapes: coupon stacking, first-order-discount farming, reseller bulk-redemption, and self-referral between a shopper's own accounts.
• Coupon-code rules and IP blocks miss it because both are trivial to swap per redemption. The device and network behind the checkout are what stay consistent.
• The cheapest place to stop it is at the redemption, by scoring how new a shopper really is before the discount is applied or the referral pays out.
• Detection produces evidence, not a verdict. The score and the named signals are yours to act on, and your own checkout rules decide what a risky redemption gets.

What is promo abuse in ecommerce?

Promo abuse is the practice of redeeming a promotion more times than its rules allow, by checking out as accounts that each look like a separate first-time customer. The offer is usually a first-order discount, a promo or coupon code, free shipping, store credit, or a referral payout, and the move is always the same: one shopper presenting as many fabricated identities, the dynamic John Douceur named in The Sybil Attack, published at the 2002 IPTPS workshop, each redeeming the offer once so that together they redeem it many times. It is the same one-user-many-accounts pattern behind multi-accounting, pointed at the discount instead of the account.

In ecommerce that pattern takes a few recognizable shapes, and naming them helps because each one leaves a slightly different trail:

• First-order-discount farming. The most common form: a store offers "15% off your first order," so an abuser creates a fresh account for every order and stays a perpetual first-time customer. The discount that was meant to convert one new buyer subsidizes a regular instead.
• Reseller bulk-redemption. A reseller or a small operation runs a one-per-customer promo or a limited drop across dozens of accounts to acquire stock at the discounted price, then resells it. The promo budget becomes the reseller's margin.
• Coupon stacking through duplicate accounts. Combining codes that were never meant to combine, or re-running a single-use code under new accounts. Pure code-stacking is an offer-logic gap you close in your promo rules, but stacking that depends on fresh accounts to re-use a one-time code is the identity problem this guide is about. How to prevent coupon abuse takes the coupon-specific version further, including how it differs from coupon fraud.
• Referral self-dealing. Inviting yourself. A shopper refers their own throwaway accounts to collect both sides of a refer-a-friend payout, which is offer abuse that pays out in real store credit or cash.
• Promo-code leaking and sharing. A code meant for one segment escapes to a deal forum and gets redeemed at volume by people who were never the intended audience. The redemptions are real accounts, but the device and network footprint behind a coordinated run still clusters.
• Code guessing. When promo codes follow a predictable pattern, an abuser does not always need many accounts at all: a script tries sequential or common codes until valid ones land. This one is an offer-design gap you close by making codes random and single-use, separate from the identity layer the rest of this guide is about, but it is worth naming because a leaked or guessable code multiplies whatever account abuse rides on top of it.

The wrapper changes, the underlying move does not: many "new" shoppers that resolve back to one device, one network, or one payment trail. That shared root is why multi-accounting owns the mechanics of why address-based checks fail, and why this guide focuses on reading the redemption rather than re-explaining them.

The offers abusers target most

Some offers attract more abuse than others, and which ones is predictable:

• First-order and new-customer discounts, because they pay out before any loyalty is built.
• Refer-a-friend payouts, self-referred between a shopper's own throwaway accounts.
• Limited drops and fixed discount pools, where bulk redemption corners scarce stock before real buyers arrive.
• Free shipping and welcome credits, harvested across many accounts at once.
• Loyalty points and cashback, farmed by accounts cycled just long enough to qualify for the reward.

The offer changes, the underlying tell does not: the redemptions trace back to fewer real people than accounts.

Promo abuse can scale fast in the open: in one widely reported case, a single Uber user ran a per-referral credit up to roughly $50,000 by sharing a custom referral code far beyond his own contacts before the program shut it down. That loud, code-sharing version is the one redemption limits and code design catch. The quieter version, one person running many look-alike accounts so each reads as a new customer, is the one that slips past those controls and the one device-level detection is built to read.

What promo abuse costs an online store

Multi-account abuse is common enough to measure: Stripe's 2025 analysis of first-party fraud tied 7.4% of signups at AI companies to suspected multi-account abuse, the same mechanic an ecommerce promo invites. An abused promo then charges you more than the face value of the discount, because each fake redemption hits the business in several places at once:

• Margin given away on repeat. Every duplicate redemption is another first-order discount or another referral payout handed to someone who was never a new customer. Each one is small, which is why it runs unnoticed until the cumulative total shows up in the margin report.
• Acquisition numbers that lie. A discount campaign reports itself through new-customer counts and cost-per-acquisition, and a farm inflates both: every fabricated redeemer reads as a fresh win. The campaign looks cheaper and more effective than it is, so the team pours more budget into a channel that is partly subsidizing one shopper's tenth order.
• A capped budget drained before real customers reach it. When a promo is limited, a fixed discount pool or a stock-limited drop, a farm does not only cost margin, it empties the pool. Genuine shoppers arrive to a dead code or sold-out units, so the campaign's real reach collapses while the dashboard reads as a sell-out.
• Real money out the door. Referral payouts and store credit move actual funds or near-cash to the abuser, which is what makes promo abuse a favorite first step before heavier payment fraud.
• Operational drag. Every suspected farm is someone's afternoon: pulling order logs, matching accounts, and deciding what to reverse. The discount is the visible cost; the team-time spent chasing it after the fact is the quiet one, and it grows with the abuse.
• A seasonal spike you plan around. Promo abuse tracks the promo calendar, so it concentrates in the fourth-quarter sale season when the biggest discounts run. A store that is ready for that timing loses less than one that treats the peak as ordinary traffic.

The signals that flag an abused promo

What exposes an abused promo is the gap between what a shopper can fake and what they cannot. A disposable inbox, a rented IP, and a shared coupon code are all cheap to produce for every account; a genuinely different device and home network for every redemption are not. So the useful question is never whether one flag is present, but how many independent signals converge on the same redeemer. The ones that carry the most weight at a redemption, and the risk each points to, read like this:

No single row is proof. A real customer can shop over a VPN, and two people in one household can share a network and a delivery address. The read is correlation: a redemption that lights up several rows at once, especially a device already seen behind other discounts, is the one worth holding.

Swapping the email or rotating the IP changes none of the device traits underneath, which is why the device, not the address, is the anchor that holds. That the cheap-to-change attributes move while the expensive-to-change ones repeat is the device-layer version of a problem researchers have studied for years, detecting fabricated accounts at scale, which USENIX NSDI research approached from the social graph.

We tested that anchor directly. Running the same shopper through a checkout with a fresh inbox behind a new IP and a different coupon on each pass, every attribute a code-or-IP rule keys on changed while the device behind the redemption held, so the accounts still lined up as one. That is the quiet version of a pattern measured at scale: in 2025, Stripe's first-party fraud analysis put suspected multi-account abuse at 7.4 percent of signups at AI companies, traffic that reads as many new customers but resolves to far fewer real people.

One more tell lands after the redemption rather than during it. An account that places one discounted order, claims the referral credit, and never returns is behaving like a harvested account, not a customer. You read that arc in your own order data, and it pairs with a high score at checkout that flagged the account in the first place.

How to read the risk at the redemption

Promos hand you one advantage the abuser cannot take away: you choose the moment to check. The discount has not shipped yet when the redemption reaches your server, so you can read who is behind it and decide before the code applies, rather than reconciling a margin report a month later.

With ShieldLabs, a JavaScript snippet identifies the visitor on the page, and your checkout reads the score for that session the moment a promo code, first-order discount, or referral is redeemed. The response carries the visitor, the device behind them, a score, and the named signals that moved it:

{
  "event_type": "identification.scored",
  "schema_version": "2026-06-01",
  "created_at": "2026-06-11T14:08:00Z",
  "data": {
    "request_id": "f1c0a93e-7b22-4d18-9a4e-2c7d51e9a330",
    "visitor_id": "b7d2e4a1-3c6f-49b8-a012-5f8c2d9e7b41",
    "device_id": "9c3a17f2-5d84-4e60-bb19-7a0c4e2f6d83",
    "connection_type": "proxy",
    "risk_score": 75,
    "detection_flags": { "proxy": true, "datacenter_ip": true },
    "observed_at": "2026-06-11T14:08:00Z"
  }
}

The risk_score is a single 0-to-100 read, and the detection_flags name the reasons it landed there instead of leaving you a black box to trust. The redemption above scored 75 because the session checked out through a datacenter proxy, the kind your checkout holds before applying the discount; a clean session would come back low and redeem untouched.

The piece that does the linking is device_id: it is derived from the device, so it reappears behind the next "new" account even after the email and the IP are swapped, which is the connection a fresh inbox was meant to hide. The evidence comes back from detection; the rule that acts on it stays in your checkout code.

A playbook to prevent promo abuse

No single control ends promo abuse, so the working setup is a stack of cheap checks around the redemption, each one easy to add and each one leaky on its own. Stacked, they turn a one-click farming run into slow, manual work that is no longer worth the discount. The six below run from the easiest floor to the read that actually does the linking.

• Raise the cost of a throwaway identity. Email and phone verification, plus tying a first-order discount to a verified payment method, make each fake account cost a little to stand up. Treat it as a floor, not a fix: disposable inboxes and plus-addressing slip past verification on their own.
• Key the discount to the device, not the inbox. Bind each redemption to the device and connection behind it, so a swapped email does not reset a returning shopper to new. This is the one layer that survives when the coupon code, the cookie, and the IP all change at once.
• Rate-limit by device, not just by code. Cap redemptions per device, network, and fingerprint, so one footprint cannot run a dozen first-order discounts in an hour even when every email is unique.
• Delay the cashable part. Release referral credit after a return window, or hold a high-value discount behind a small qualifying purchase, so a fabricated redemption never reaches the withdrawable value on day one. Slowing the money down beats trying to wall the account out.
• Decide at the redemption, not in the report. Roll the signals into one score the moment the code is entered and act on the high ones, instead of spotting the farm later in a margin reconciliation. Upstream is the cheapest place to act.
• Make the math fail. The aim is not a perfect wall; it is to make one redemption cost the shopper more than the discount returns. Once the economics break, a bulk operation moves to a softer target.

Score, do not block: your checkout owns the verdict

What ties the six controls together is the split between evidence and action. A good detection layer returns a risk score and the named signals behind it, then stops. Your checkout code reads that score and decides whether a given redemption is applied normally, held for a closer look, or stepped up to a verification check.

That separation is what lets a genuine customer on a VPN check out while a reseller farm gets held, and it keeps the policy, which shifts every promo season, in your hands rather than a vendor's.

Detect at the redemption, before you add friction

The default reflex is to bolt an identity check onto every checkout, but a verification step taxes every honest shopper to catch a few abusers, and that friction is exactly what costs conversion at the worst moment. Reading the device and network first inverts the order: you catch the duplicate-account pattern silently, from signals the device and browser already expose, and reserve a heavier verification step for the small set of redemptions that actually look risky.

This is also why promo abuse is awkward to own. The marketing team runs the offer to win customers and the risk team is asked to stop the farm, but a blunt block that protects margin can quietly kill the conversions the campaign was launched for. A read that scores every redemption silently and adds friction only to the risky few is what keeps both goals intact, which is why the two teams tend to land on the same answer: detect quietly, decide explicitly.

Preventing promo abuse with ShieldLabs

ShieldLabs runs on your signup, checkout, or redemption page through one JavaScript snippet, and it risk-scores every visitor on the first visit, so you have a read on the shopper behind a redemption before the discount applies. At the center is persistent identification that ties a "fresh" account back to a device already seen, even after the shopper switches email, clears cookies, and rotates IP, the exact disposable layers a discount farmer counts on. It works in the background, with no friction for a real customer.

Around that identifier, each visit returns a risk score from 0 to 100 with the anonymity signals behind it: an anti-detect browser, a VPN or anonymous proxy, a datacenter connection, and others. Across redemptions, the pre-built patterns surface which accounts trace back to one device, so your team can watch a discount farm as a trend in the dashboard rather than chasing redemptions one at a time.

ShieldLabs scores every visitor and names the signals behind that score. You read the risk score and named anonymity signals through the API and webhooks and decide, by your own rules, what a risky redemption gets, whether that means letting a clean shopper check out normally, holding a high-risk referral payout for review, or stepping a borderline redemption up to verification.

Because that logic runs in your own checkout rather than inside a sealed verdict engine, you set the threshold, change it as you learn, and can always say why a given redemption was held. The same identity layer carries over to multi-accounting prevention and promo abuse prevention, since the duplicate discount, the recycled code, and the self-referral are one problem read at one layer.

Sources

1. Wikipedia: Disposable email address
2. Cao, Sirivianos, Yang, Pregueiro: Aiding the Detection of Fake Accounts in Large Scale Social Online Services (USENIX NSDI, 2012)
3. Douceur, John R.: The Sybil Attack (IPTPS, 2002)
4. Stripe: Analyzing first-party fraud trends: account, free-trial and refund abuse (2025)
5. Business Insider: This guy got $50,000 in credit from Uber and ended up with free Uber rides for life (2014)