Promo abuse prevention

Industry estimates put losses from promo abuse at 20 to 30% of total promotional budget in 2026. The attack surface is broad (sign-up bonuses, referral codes, first-purchase discounts, loyalty points, free trials, cashback) and the operators are well-organized. The defense that holds up is device-level identity, because the operator can produce unlimited emails and addresses but only owns a finite set of devices. This article covers the patterns, the detection approach, and how to keep promotions targeted at legitimate users.

This is the fourth post in the abuse cluster, alongside account takeover prevention, credential stuffing, and fake account prevention.

The umbrella covers any deliberate manipulation of a promotional offer that extracts value beyond what the promotion was designed to give. The major patterns:

Multi-accounting

The most common form. The user creates multiple accounts to claim a per-account benefit repeatedly. A “first 10 orders 50% off” promotion gives one customer ten discounted orders if they sign up ten times. A “$10 free credit on signup” gives one operator unlimited credit at the cost of unlimited signups.

Self-referral

The user enters their own details (perhaps with a small variation: different email, different shipping address, different phone) as a referral and collects both the referrer and referee bonuses. The variant where the operator runs a small network of accounts and refers between them is functionally identical.

Coupon stacking

The user finds promotional codes meant for separate offers and combines them, exploiting ordering logic that does not enforce mutual exclusivity. Sometimes works against legitimate discount infrastructure; usually works against marketplace platforms where individual sellers and the marketplace each issue codes that interact.

Coupon enumeration

The user (or a script) discovers private or single-use promo codes by enumerating likely patterns or by brute-forcing the code namespace. Once a code is found, it spreads on coupon-sharing forums quickly.

Loyalty point arbitrage

The user games loyalty programs by exploiting earn-redeem asymmetries: earning points faster than the program designer intended, redeeming for goods worth more than the earning effort cost. Common against airline miles, hotel loyalty, gaming platform reward currencies.

Cashback abuse

The user makes purchases primarily to earn cashback, then returns the goods. The net effect is that the user keeps the cashback while the merchant takes the return loss.

Trial abuse

The user signs up for a 30-day free trial, uses the product, cancels before the bill, signs up again with a new identity. Common against streaming services, SaaS tools, AI services with credit-based pricing.

Each pattern has different economics and a different attacker profile, but they share the same defense problem: the same operator producing many apparently-distinct interactions.

Why the abuser wins against email and IP defenses

The traditional promotion defenses were:

Restrict to one redemption per email address.
Restrict to one redemption per shipping address.
Restrict to one redemption per IP address.
Restrict to one redemption per payment method.

Each is defeated independently.

Email. Disposable email services, plus-addressing, forwarding aliases. Already covered in detail in fake account prevention.

Shipping address. Variations in address formatting that the validation logic accepts as distinct (123 Main St vs 123 Main Street vs 123 Main St Apt 0). PO boxes. Drop-shipping services that accept packages on the user’s behalf.

IP. Residential proxies, public Wi-Fi, mobile carrier-grade NAT, household members sharing a router.

Payment method. Prepaid cards, virtual cards, multiple bank accounts, multiple PayPal accounts. Privacy.com and similar services produce essentially unlimited virtual cards.

Each defense layer raises the cost per fake redemption by a small amount. None of them is sufficient on its own, and the joint defense of “all four must look unique” is broken by an operator who is deliberate about each.

What works: the device behind the operator

The single defense that scales is device-level linking. The operator can rotate identities, addresses, payment methods, and IPs cheaply, but rotating the underlying device is much harder.

What makes promotion abuse defense work in practice is a device intelligence layer that produces:

A stable visitor fingerprint (visitor_fingerprint.id) per device.
A lifecycle history per fingerprint: when the device was first seen, when it was last seen, how many sessions it has produced.
A redemption ledger, kept by the application and keyed on the fingerprint, of which devices have redeemed which promotions.

With that in place, the promotion engine asks: “Has this visitor fingerprint redeemed this promotion before? Has a fingerprint linked to the same accounts redeemed it? Has this fingerprint been associated with promo abuse in the past?”

If no, allow. If yes, the redemption is suspect, and the right response depends on how strong the evidence is, which is what the graduated-response pattern is for.

Incognia, SHIELD and other device intelligence providers have all written on this approach with the same fundamental architecture (Incognia: Promo Abuse Prevention, SHIELD: Promo Abuse).

The graduated-response pattern

Hard-blocking promo abuse is satisfying but counterproductive in many cases because:

Real users sometimes look like abusers (the false-positive cases below).
The operator learns they are detected and adjusts.
Customer-support load increases.

The graduated response that works in production:

Low-risk redemption (clean device, no history with this promo, normal behavioral signal). Allow. Default behavior.

Medium-risk (device has redeemed this promo before, or its visitor fingerprint matches a prior abuser at low confidence). Allow at reduced value. A real user still gets the promotion; an abuser gets a fraction of it.

High-risk (visitor fingerprint is linked to known abuse, or attribution flags an anti-detect browser). Silent decline. The redemption “succeeds” in the user’s view but the actual reward is not credited. Customer support investigates if the user complains.

Confirmed abuse (device is on a maintained deny-list, or behavior matches an in-progress abuse campaign). Hard decline with a generic error.

The silent-decline tier is the most useful because it preserves operator ignorance about the defense. They run their scripts, the redemptions appear to succeed, and the value never accrues.

The false-positive cases the policy must survive

Device evidence alone will flag a meaningful number of legitimate users. Households and roommates share a laptop or tablet, so two “new customer” redemptions from one device can be two real customers. Gift purchases produce a known account redeeming on behalf of someone else, often to the buyer’s own address. Agencies and assistants legitimately manage multiple client accounts from a single machine, which looks exactly like a small farm. This is why the graduated response matters: device-level evidence should reduce or hold value, not hard-deny it, until account behavior corroborates abuse. A two-year-old account with purchase history that trips a shared-device check deserves the benefit of the doubt; ten zero-history accounts on one device do not. Link the device signal to account tenure, purchase history, and redemption pattern before denying anyone value.

Real-world examples from the literature

Some patterns that come up regularly in published case studies.

A ride-share offers a first-ride bonus to new users. Operators discover that the platform identifies users by phone number, email, and payment method. They build a system that automatically creates new accounts with disposable phones, throwaway emails, and prepaid virtual cards. They redeem the bonus thousands of times per day across a single physical location. Defense: link by device identity rather than by phone-email-card.

Referral chain on a fintech app

A fintech offers $50 to both referrer and referee when a referral signs up and completes their first transaction. Operators build self-referral networks: one operator runs 50 accounts, each refers the next. Defense: detect that the referrer and referee share device intelligence, IP cluster, or behavioral patterns.

Coupon discovery on an ecommerce platform

An ecommerce platform issues single-use coupons by email but the code namespace is predictable. Operators scrape coupons from social media and forums. Defense: rate-limit coupon redemption per visitor fingerprint regardless of email, and randomise the code namespace.

Free-trial cycling on a streaming service

A streaming service offers a 30-day free trial. Operators script the signup-watch-cancel-signup cycle with anti-detect browser profiles. Defense: rate-limit free trials per visitor fingerprint, not per email.

Operational signals the system needs

A promo abuse defense built on device intelligence needs the data layer to surface:

Per-device history of redemptions. Which promos has this device redeemed? When? For what value?
Linked-account history. Same question, scoped to every account this fingerprint has touched.
Behavioral-similarity signal. Does this session look like one we have seen recently from the same operator (similar interaction style, similar timing, similar navigation flow)?
Account graph. Which accounts have been touched by this device? Which other devices have touched these accounts?

The application uses these to decide whether the redemption should be processed normally, reduced, silently declined, or hard-declined.

What not to do

Three failure modes worth naming:

Generic errors for everyone. “We could not process your request” shown to a false-positive legitimate user is a support ticket and a lost customer, because it gives them nothing to act on. Reserve generic hard declines for confirmed abuse. For the uncertain middle, decline at the value-crediting step rather than the redemption-confirmation step: the user sees the same UI a legitimate user sees, and the value simply never accrues.

One-strike permanent bans. A device flagged for one suspicious redemption should not be permanently locked out of all promotions. Real users get false positives; the recovery path should be reasonable.

Public deny-list lookups. Some fraud-prevention services let you check whether a phone or email is on a public abuse list. These lists exist; the operators know they exist; the operators discard identifiers that show up on them. The signal value is lower than the marketing suggests.

How Foil supports it

Foil’s visitor fingerprint is designed for this case. The SDK collects device, network and behavioral signals and produces a sealed token; verifying it server-side yields the fingerprint id, a bot-or-human decision, and attribution labels that flag anti-detect browsers, headless frameworks, and agent tooling.

A typical promotion-redemption integration:

import { Foil, safeVerifyFoilToken } from "@abxy/foil-server";

const client = new Foil({ secretKey: process.env.FOIL_SECRET_KEY });

app.post('/api/promo/redeem', async (req, res) => {
  const result = safeVerifyFoilToken(req.body.foilToken, process.env.FOIL_SECRET_KEY);
  const { promoCode, accountId } = req.body;
  const promo = await promos.get(promoCode);

  if (!result.ok || result.data.decision.verdict === 'bot') {
    return silentDecline(req, res, accountId, promo, 'automation');
  }

  const { visitor_fingerprint, session_id } = result.data;
  if (!visitor_fingerprint) {
    return silentDecline(req, res, accountId, promo, 'no_fingerprint');
  }
  const visitorId = visitor_fingerprint.id;

  const priorByVisitor = await redemptions.countByVisitor(visitorId, promo.id);
  if (priorByVisitor >= promo.maxPerDevice) {
    return res.status(400).json({ error: 'promo_already_redeemed' });
  }

  // Accounts previously attached to this fingerprint's sessions
  const priorByLinkedAccounts = await redemptions.countByLinkedAccounts(visitorId, promo.id);
  if (priorByLinkedAccounts >= promo.maxPerOperator) {
    return silentDecline(req, res, accountId, promo, 'linked_account_limit');
  }

  const session = await client.sessions.get(session_id);
  if (session.attribution.labels.some((l) => l.kind === 'evasion' && l.value === 'anti-detect-browser')) {
    return reduceAndCredit(req, res, accountId, promo, 0.5);
  }

  return processRedemption(req, res, accountId, promo, visitorId);
});

The application encodes the graduated response and keeps the redemption ledger keyed on the visitor fingerprint. Foil provides the fingerprint, the decision, and the attribution evidence; linking fingerprints to accounts (sessions.attachClientUser at signup and login) is what powers the linked-account check.

The broader account-abuse picture is in the sibling posts linked at the top of this article.