How to prevent bonus, promo, and coupon abuse: a detection playbook for developers

Almost every growth team runs an offer that hands real value to a new user: a welcome bonus, a first-order promo code, a referral payout, a coupon. Each one carries the same built-in incentive to game it, because the offer pays out per new customer and the only thing standing between a user and the next payout is one more account that looks new.

A disposable inbox and a cleared browser make that account nearly free to produce, and at volume. Stripe's 2025 analysis of first-party fraud tied 7.4 percent of signups at AI companies to suspected multi-account abuse, the same mechanic these offers invite.

That is what bonus abuse, promo abuse, and coupon abuse really are: one user claiming an offer over and over behind identities built to look brand new. The short answer to preventing it is to stop trusting the email and the IP, read the device and network behind each claim, and score it before you credit anything.

Key takeaways

• Bonus abuse, promo abuse, and coupon abuse are the same mechanic on different offer types: one person presenting as many to claim an incentive repeatedly.
• There is an honest line between bonus hunting (one identity working an offer within the rules) and bonus abuse (many fake identities working it as fraud). The detection question only matters past that line.
• Email and IP checks miss it because both are trivial to swap per claim. The device and network behind the claim are what stay consistent.
• The cheapest place to stop it is at the claim itself, by scoring how new a claimant really is before the bonus, payout, or discount is granted.
• No single check is enough. Verification, device-level deduplication, velocity limits, and a risk score work together, and your own rules decide what a risky claim gets.

What is bonus, promo, and coupon abuse (and what they have in common)?

Bonus abuse, promo abuse, and coupon abuse look like three different problems because they wear three different offer types, but underneath they are one mechanic: a single user claims an offer meant to be claimed once, many times, by presenting as many separate people.

The offer changes with the industry:

• In iGaming it is a welcome bonus, a deposit match, or free bets.
• In ecommerce it is a first-order discount, a coupon code, or a referral payout.
• In SaaS it is a free trial or onboarding credits.

The wrapper differs; the move does not.

In practice that move shows up as a few recurring tactics: reclaiming a one-time code or bonus under a fresh account, spinning up many accounts to take a one-per-customer offer again and again, and scripting bulk claims against a limited drop. One related tactic, stacking codes that were never meant to combine, is worth separating out, because that is an offer-logic gap you close in your promo rules rather than an identity you read at the device. Everything else on the list is the same one-user-many-identities pattern.

Because the mechanic is shared, the detection approach generalizes across all three. Whether the prize is a casino bonus or a 20 percent coupon, the user has to do the same thing: produce a stream of accounts that each look like a first-time customer.

That means a fresh email, a cleared browser, and often a new IP for every claim. The thing they cannot cheaply produce is a genuinely different device and network for each one, which is exactly why detection anchors there rather than on the address.

This is the same one-user-many-accounts pattern behind multi-accounting, applied specifically to offers. Multi-accounting is the broad practice and owns the mechanics of why address-based checks fail. This guide is the cross-industry overview of the offer-abuse case: the shared mechanic, the signals, and how to read a claim before you grant it.

Each offer type then has its own deeper playbook: the iGaming case, where the welcome bonus is richest, and the ecommerce case in how to prevent promo abuse, where first-order-discount farming and coupon stacking do the same work.

Where offer hunting ends and abuse begins

Not every person chasing an offer is committing fraud, so a playbook that ignores the line will flag real customers. The honest distinction is identity count, not enthusiasm. One real person who reads the terms, meets the requirements, and claims an offer once as themselves is working it hard but honestly, which is a terms-of-service question rather than a detection one.

Abuse begins the moment that one person becomes many accounts to claim the same offer over and over: that jump from one identity to many is exactly what detection is built to read, and reading it cleanly is what lets you act on the farm while leaving the aggressive-but-honest customer alone. The same line falls differently for casino offers, including matched betting and bonus arbitrage.

What bonus and promo abuse costs you

An abused offer charges you more than the face value of the bonus, because each fake claim hits you in several places at once:

• The incentive, given away on repeat. Every duplicate claim is another welcome bonus, another discount, or another payout handed to someone who was never a new customer. Each instance is small, which is why it runs unnoticed until the total is large.
• Acquisition metrics that read as wins. Offers are acquisition tools, so their performance feeds cost-per-acquisition and new-customer numbers directly. When a slice of claimants are one user in disguise, the campaign looks cheaper and more effective than it was, and the team doubles down on a channel that is partly feeding a farm.
• Real money out the door in payouts. Bonus and referral abuse are not only lost margin. A matched deposit that gets withdrawn, or a referral that pays cash, moves real funds to the user, which is what makes offer abuse a favorite first step before heavier fraud.
• A capped offer drained before real customers reach it. When an offer is limited, a fixed discount budget, a stock-limited drop, or a first-so-many-customers deal, a farm does not only cost margin, it empties the pool. Genuine customers arrive to a dead code or sold-out units, so the campaign's real reach collapses while the dashboard reads as a sell-out.
• A staging ground for worse abuse. A pile of bonus-funded or promo-funded accounts is raw material. The same identities get pointed at referral chains, resold, or recycled for the broader new-account fraud that targets any signup, so an unguarded offer becomes a supply line.

For scale, Juniper Research projects global ecommerce fraud losses rising from $56 billion in 2025 to 131 billion dollars by 2030, the broader problem that unguarded offers feed into.

The signals that flag an abused offer

An abused offer gives itself away through what the user cannot reissue per claim. The email is disposable, the IP is rentable, the cookie clears in a click, but the hardware behind the claim and the network it rides stay the same from one account to the next. Reliable detection ignores any single flag and asks instead how many independent signals land on the same claimant. The ones that move the needle most, and the weight each carries, read like this:

What you can read at the claim	Why it points to abuse	Risk it carries
The same device behind several bonus or promo claims	one user collecting the offer many times	High
An anti-detect browser or a spoofed device profile	a profile rebuilt to look unique per account	High
A VPN, anonymous proxy, or datacenter connection	network cover routed under each new claim	High
The same network footprint behind many "new" claimants	a farm working from one place	Medium-High
A burst of claims minutes apart from one footprint	automation, not organic demand	Medium-High
A registration region that disagrees with the network or payment origin	one place reused behind many faked identities	Medium-High
A reused card or payout destination across accounts	the same hand funding or cashing out many claims	Medium
Shared contact or address details across accounts	identities minted from one template	Medium

No single row is proof. A real customer can use a VPN, and two honest players can share a household network. The read is correlation: a claim that lights up several rows at once, especially a device already seen behind other claims, is the one worth holding. Correlating many weak signals this way is one practical answer to a problem academics have studied for years, including the work on detecting fake accounts in large-scale online services presented at USENIX NSDI, which ranked accounts by how likely they were to be fake. 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.

We ran a stack of look-alike claims to see what actually survives a reset, and only the device did: a swapped email, a wiped cookie, and a switched connection changed nothing about the traits underneath, which kept folding back onto one identifier. The address is cheap to rotate, which is precisely why it makes a poor anchor. That got truer in 2022, when Chrome began reducing the user-agent string and shifting device detail into structured client hints, thinning the surface a claim can forge while the layers beneath it held.

One more tell lands after the claim rather than during it. An account that grabs the bonus, pulls the cashable value right away, and then goes quiet is behaving like a harvested account, not a player. You read that arc in your own activity data, and it pairs with a high score at the claim that flagged the account in the first place.

How to read the risk at the moment of the claim

The leverage with offers is timing. You do not have to unwind abuse after a bonus is paid; you can read the claim and decide before you credit anything. With ShieldLabs, a JavaScript snippet identifies the visitor on the page, and your server reads the score for that session when a bonus, promo, or coupon is claimed. A scored claim 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-11T09:42:00Z",
  "data": {
    "request_id": "0c284695-cf0b-4755-8beb-0a2e9536595e",
    "visitor_id": "aa8c616a-8a25-4a5e-bee2-a9a08e5128a4",
    "device_id": "6a45967d-1371-9652-ba99-b01ea3992208",
    "connection_type": "vpn",
    "risk_score": 80,
    "detection_flags": { "anti_detect_browser": true, "vpn": true },
    "observed_at": "2026-06-11T09:42:00Z"
  }
}

The score is one number from 0 to 100, and the signals name what is behind it rather than hiding it in a black box. A claim like the one above, a high score on a session running an anti-detect browser over a VPN, is the kind you hold before granting the bonus. A clean session gets credited normally.

The device identifier is the part that survives the user's reset: the same device_id reappearing behind a "new" account is the link a fresh email was supposed to break. ShieldLabs returns the evidence; the rule that acts on it lives in your application.

A playbook to prevent bonus, promo, and coupon abuse

There is no single switch that ends offer abuse, so the working approach is to layer cheap checks around the claim until staying ahead of all of them at once stops being worth a user's time. Each control below leaks on its own; the point is the stack, which turns a one-click farming run into a slow, costly grind.

• Verify more than the address. Email and phone verification raise the floor, and tying a bonus to a verified payment method makes a throwaway identity cost something. It is a floor, not a fix, since disposable inboxes and plus-addressing walk straight through verification alone.
• Deduplicate on the device, not the credential. Bind each claim to the device and connection making it, so a new inbox does not read as a new person. This is the one layer that holds when the email, the cookie, and the IP all change between claims.
• Cap claim velocity. Rate-limit claims per device, network, and fingerprint, so a single footprint cannot rattle off dozens of bonus claims in an hour even when every email checks out.
• Meter the value, not just the claim. Release a bonus in stages, or hold a payout behind a wagering or activity bar, so a fabricated claim never reaches the cashable part on day one. Slowing the value down often beats trying to block the account outright.
• Score before you grant. Roll the signals into one risk read at the moment of the claim and act on the high ones, rather than finding the pattern later in a payout report. The claim itself is the cheapest place to intervene.
• Tilt the economics. The goal is not a perfect wall, it is to make a claim cost the user more than the bonus pays out. When the math stops working, a bulk pipeline moves on to an easier offer somewhere else.

What ties the six together is the split between evidence and action: the signals say how risky a claim looks, and your policy decides what happens next. That gap is what lets a genuine customer on a VPN through while a farm gets held.

Preventing bonus and promo abuse with ShieldLabs

ShieldLabs runs on your signup, claim, or checkout page through one JavaScript snippet, and it risk-scores every visitor on the first visit, so you have a read on the person behind a claim before you grant the bonus. At the center is persistent identification that ties a "fresh" claimant back to a device already seen, even after the user switches email, clears cookies, and rotates IP, the exact disposable layers an offer 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 IP, and others. Across claims, the pre-built patterns surface which accounts trace back to one device, so your team can watch a bonus farm as a trend in the dashboard rather than chasing claims 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 claim gets, whether that means crediting a clean visitor normally, holding a high-risk payout for review, or stepping a borderline claim up to verification.

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

Sources

1. Wikipedia: Disposable email address
2. Wikipedia: Matched betting
3. Cao, Sirivianos, Yang, Pregueiro: Aiding the Detection of Fake Accounts in Large Scale Social Online Services (USENIX NSDI, 2012)
4. Stripe: Analyzing first-party fraud trends: account, free-trial and refund abuse (2025)
5. Juniper Research: Fraudulent eCommerce Transactions to Surpass 131 Billion Dollars by 2030 (2025)