One human, one welcome offer
Every promotion is priced on an assumption about how many distinct people will claim it. Multi accounting breaks the assumption, and no amount of rule tuning repairs it, because rules operate on accounts and accounts are free.
Picture a growth lead at a delivery company on the Monday after a referral campaign. The dashboard is magnificent. Referral signups are up four hundred percent week on week, the cost per acquisition looks like the best number anyone has posted in eighteen months, and there is a slide being prepared about it for the board.
Two weeks later the cohort analysis arrives, and the referred users have a second order rate of almost nothing. Not a poor rate. Almost nothing. They took the credit, placed the qualifying order, and vanished, and a striking number of the qualifying orders went to a handful of postcodes.
Finance gets there a quarter after that, which is how long it takes for promotional credit to move from a marketing accrual into a line somebody reconciles. The campaign did not acquire customers at a remarkable price. It bought inventory for a small number of people who had worked out that the referral bonus was worth more than the effort of claiming it repeatedly, and who had industrialised the effort.
Nobody did anything unusual. The fraud rules were on. The device intelligence vendor was deployed and had flagged some of it. The signups had real email addresses, real phone numbers, real payment cards, and real delivery addresses. Every account was, individually, entirely plausible. There were just far fewer people behind them than the budget assumed.
How do retailers stop coupon and promo abuse today?
Almost every merchant runs the same stack, and it is worth laying it out honestly before criticising it, because each layer was a reasonable answer to the thing that came before it.
There is device and browser intelligence, which tries to recognise that these fifty accounts came from one machine. There is payment instrument deduplication, which tries to recognise the same card behind multiple accounts. There is address normalisation and deduplication, which tries to catch the same delivery point. There is velocity limiting, which caps redemptions per hour by some key. And there is behavioural clustering, which looks for accounts that resemble each other more than accounts should.
Underneath all of them sits a promotion engine, whether homegrown or a product like Talon.One or Voucherify, which enforces the terms: one per customer, new customers only, minimum basket, expiry.
The phrase to look at hard is one per customer. Every promotion engine in the world offers that constraint, and every one of them implements it as one per account, or one per email address, or one per card, or one per device, because those are the identifiers a merchant actually holds. Not one of them can implement it as one per customer, because no merchant has a reliable handle on a customer as a person. The rule everyone writes and the rule everyone enforces are different rules, and the gap between them is the entire industry of promotion abuse.
Why do rules on accounts always lose?
Here is the analogy. Imagine a cinema running a promotion where the first ticket is free, and enforcing it by writing your seat number on a list. Seats are free to move between. You can sit in any seat you like, as many times as you like, and each time the list records a different seat. The list is accurate, well maintained, and answers a question nobody asked.
That is what every account level control is doing. It is meticulously recording an identifier that costs the abuser nothing to change.
Work through the identifiers one at a time and the pattern is consistent.
An email address is free and unlimited. Catch all domains cost a few pounds a year and generate infinite valid addresses. This is so well understood that no serious fraud team counts it as a control.
A device is not free, but a device signature is. Browser profiles, virtual machines, mobile device farms, and residential proxy networks all exist as commercial services with published prices. More importantly, the raw material for device recognition is being deliberately reduced: the W3C has published guidance on mitigating browser fingerprinting, and browser vendors have been cutting passive entropy for years. A control whose input the platform vendors have publicly committed to degrading is a control on a schedule.
A payment card looks like a strong anchor and is not. Virtual card numbers are a mainstream banking feature offered to ordinary consumers for good privacy reasons, and prepaid cards are sold in supermarkets. A farm that clears ten pounds per redemption can afford a fresh card number per account without thinking about it.
An address is the one that produces the most collateral damage, which we will come back to. Parcel lockers, forwarding services, and the simple fact that a large apartment building contains hundreds of households at one street address all defeat address deduplication. Meanwhile the family who lives at one address gets caught by it.
So the farm's marginal cost per redemption stays somewhere near zero, and the merchant's promotion budget is being spent against an adversary with an unlimited supply of the only thing the merchant is counting.
How big is this, honestly?
Smaller than the vendors say and larger than the board thinks, and the truthful answer is that nobody outside each company knows.
Merchants do not publish promotion abuse rates. The reason is not mysterious: the number is commercially embarrassing, it implies the reported acquisition figures were inflated, and disclosing it would tell farms exactly which offers are worth attacking. Industry bodies such as the Merchant Risk Council and vendors such as Ravelin publish survey work in which promotion abuse appears consistently among the leading merchant fraud types, and those surveys are worth reading as directional evidence, with the caveat that they are self reported by respondents who are also buying anti fraud products.
So use your own numbers instead. Take annual promotional spend, take the share of redemptions your own cohort analysis says never came back, and be prepared for a figure that is uncomfortable rather than catastrophic. A retailer spending fifty million a year on promotions with ten percent leakage is losing five million, which is an illustrative calculation and also a real conversation to have with a chief financial officer.
Why does every current defence cost more than it saves?
Each layer in the stack has a cost that shows up somewhere other than the fraud team's report, which is why the stack persists.
| Control | Abuse it stops | Honest customers it blocks | Data you must retain and justify |
|---|---|---|---|
| Email deduplication | Almost none | Almost none | Email address |
| Device and browser intelligence | Unsophisticated multi accounting, for a while | Shared computers, families, workplaces, privacy tooling users | Extensive device and browser signals about non customers |
| Card deduplication | Reuse of one real card | Households sharing a card, users of virtual cards | Payment instrument identifiers |
| Address deduplication | Crude farms | Apartment buildings, shared houses, students, families | Address graph |
| Velocity and clustering | Bursts | Anyone who resembles a burst, at random | Behavioural history |
| One human, one offer | Multi accounting per person | People who decline the check | A one way key, nothing else |
The false positive nobody counts
This column deserves more attention than it gets, because it is where the real money hides.
When a fraud control blocks an abuser, nothing happens. There is no complaint, no support ticket, no churn, and the fraud team records a win. When the same control blocks a real customer, they experience it at the worst possible moment, which is checkout, with a basket assembled and a decision made. They see a declined promotion or a locked account and a message that does not explain itself, because explaining itself would help the abusers.
Some of those people contact support, which costs you a contact. Most do not. They abandon the basket and form a durable opinion about your company. That cost lands in conversion metrics and churn cohorts, months later, attributed to anything but the fraud rule that caused it. The fraud team's dashboard shows a clean win, and the growth team's dashboard shows unexplained softness, and the two are the same event.
The populations these controls are hardest on are also predictable and unflattering: shared households, students, people in dense housing, people using privacy features their bank actively markets to them, and people in countries where the device population looks different from the model's training data. If you have ever had to explain to a customer that they cannot use a welcome offer because someone else in their building already did, you have paid this cost directly.
What would one human, one offer actually look like?
The alternative is to bind the entitlement to the thing the promotion was priced against in the first place, which is a person.
At redemption, the customer completes a short device bound check: a passkey signature with a liveness step, a few seconds on their own phone or laptop. What your checkout receives is a receipt, signed and verifiable offline, plus a one way key derived on their device.
That key is stable for one person against your merchant, and it reverses into nothing. Not a name, not a face, not a document, not a key at any other merchant. It gives you exactly one capability: the ability to answer whether this redemption and that redemption came from the same person. It cannot tell you who that person is, and it is useless to anyone who steals it.
The gate itself is unremarkable, which is the point.
POST /v1/promotions/redeem
// The client has completed the human check and holds a receipt.
const receipt = await manav.verify({ mode: "once", scope: "welcome-offer-2026" });
// Verify offline against the published Ed25519 key. No callback in the checkout path.
if (!verifyReceipt(receipt, PUBLISHED_ED25519_KEY)) return deny("invalid_receipt");
const humanKey = receipt.subject_key; // stable per person, per merchant, reversible into nothing
if (await hasRedeemed(humanKey, "welcome-offer-2026")) {
return deny("already_redeemed"); // the same person, not the same device or card
}
await applyDiscount(orderId);
await recordRedemption({ humanKey, offer: "welcome-offer-2026", receiptId: receipt.id });
Compare that with what it replaces. There is no scoring, no threshold to tune, no model to retrain, and no appeal process, because there is no judgment being made. The question "has this person already taken this offer" has a yes or no answer, and the answer does not degrade as the adversary adapts.
Note also what the family sharing a laptop experiences. Two people, one device, two different keys, two valid welcome offers. The control that a device based system gets most reliably wrong is the one this gets right by construction, because it was never looking at the device.
The referral case, which is the one that actually bleeds
Referral is the most abused mechanic and the most valuable, and it is worth treating separately because it has a structural weakness the others do not: it pays out on both sides, and the payout is often cash or credit rather than a discount on a purchase.
The classic loop is one person referring themselves repeatedly through new accounts, collecting both the referrer bonus and the referee bonus, and where credit is transferable or the qualifying purchase is cheap, the loop is directly profitable. Fraud teams respond with graph analysis, looking for referral structures that are too dense or too self contained, and it is genuinely clever work that generates genuinely painful false positives, because a real person who refers their whole family and their entire team at work produces a dense, self contained graph too.
With a human bound entitlement, the loop simply does not close. A referrer and a referee who are the same person produce the same key on both sides of the transaction, and the payout condition is never satisfied. There is nothing to detect, because the rule is checkable rather than inferable. Referral fraud detection does not get better, it becomes unnecessary for this class, which is a different and much cheaper outcome.
What this cannot do
The boundaries matter, and a control sold without them is being oversold.
It does not stop an abuser who commands many real people. Distinct humans produce distinct keys. What changes is the price: the marginal cost of a redemption moves from a card number to a human minute, which is enough to end most farming businesses and not all of them.
It does not stop a person who qualifies once and then abuses a different mechanic, such as serial returns, or exploiting a stacking bug between two offers. That is promotion design, and no identity control substitutes for reading your own terms adversarially.
It adds a step at checkout, which is the most conversion sensitive moment you own. This is the real objection and it deserves a real answer: gate the offer, not the purchase. If the check fails or the customer declines, the order should still complete at the undiscounted price rather than blocking the sale. Failing closed at checkout would cost more than the abuse.
Uniqueness is per merchant by design. The key is scoped to you, which is the privacy property that makes it safe to deploy, and it also means a customer's enrolment elsewhere does not spare them the check with you.
It does not fix your attribution. Removing farmed redemptions will make your acquisition numbers worse before anyone thanks you for it. Prepare the organisation for a cost per acquisition figure that gets less flattering and more true at the same time.
What to do this week
- Run the cohort, not the campaign. Take your last three promotions and measure second purchase rate by acquisition source. Farmed cohorts have a distinctive shape: strong first order, near zero repeat, and geographic concentration.
- Count your false positives properly. Pull every promotion decline and account lock from the last month, sample fifty, and have a human decide whether each was a farm or a family. Most teams have never done this and are startled by the answer.
- Read your own offer terms adversarially for an hour with the fraud team and the growth team in the same room. Stacking bugs and referral loops are usually found in the terms, not in the traffic.
- Move the constraint from the account to the redemption. Even before you change the control, enforcing at redemption rather than registration gives you a cleaner place to intervene.
- Put a per offer budget ceiling with a circuit breaker on referral payouts specifically, because that is the mechanic that can run away fastest.
- Pilot a uniqueness proof on one high value offer and measure exactly two things: redemptions per unique human, and second order rate of the resulting cohort. Those two numbers decide it either way.
- Check your PSD2 position if you sell in Europe, because strong customer authentication already sits in your checkout and any additional step should be sequenced sensibly with it rather than stacked on top.
The coupon abuse demo and the discount and signup fraud demo both run in a browser with no signup, and the integration path is in the developer documentation.
Frequently asked questions
How do retailers stop coupon and promo abuse? Today, mostly by scoring accounts, devices, cards, and addresses, all of which an abuser rotates cheaply. The durable approach binds each redemption to one unique human using a one way key with no identity collected, so the constraint everyone writes into their offer terms, one per customer, becomes the constraint the system actually enforces.
What is referral fraud? It is a person collecting referral rewards for accounts they control, most often by referring themselves through new accounts and claiming both the referrer and referee bonus. Where the reward is transferable credit and the qualifying purchase is cheap, the loop is directly profitable, which is why referral is the most abused promotional mechanic.
Why did my first order discount get declined? Usually because a fraud control matched something about your order to a previous redemption: your device, your card, your address, or your ordering pattern. These controls cannot tell a household from a farm, so shared computers, apartment buildings, families sharing a card, and virtual card numbers all produce declines for people who have done nothing wrong.
Does device fingerprinting stop multi accounting? Partially and temporarily. It catches unsophisticated reuse and misses anyone using a fresh browser profile or a residential proxy. It also blocks households sharing a machine, and the browser signals it depends on are being deliberately reduced by browser vendors, so its effectiveness declines over time by design.
Can you enforce one offer per person without collecting identity? Yes. A device bound check with liveness can produce a one way key that is stable for one person at one merchant and reversible into nothing. It answers whether two redemptions came from the same person and cannot reveal who that person is, so it enforces the rule without building a customer identity database.
Will this block families who share a device? No, and that is a substantive improvement over device controls. The proof is bound to the person, not the machine, so two people using one laptop produce two distinct keys and both receive their offer, which is the case device intelligence gets wrong most often and most visibly.
What happens if the check fails at checkout? It should fail open on the sale and closed on the discount. The order completes at the undiscounted price and the customer is not blocked from buying. Blocking a completed basket to protect a promotion is a trade that loses money in almost every configuration.
Sources
- Open Web Application Security Project, Automated Threats to Web Applications, including OAT-002 Token Cracking, which covers automated discovery and redemption of voucher and coupon codes: owasp.org/www-project-automated-threats-to-web-applications
- Merchant Risk Council survey work on merchant fraud types, useful as directional evidence and self reported by respondents who also purchase anti fraud products: merchantriskcouncil.org
- Ravelin published research on promotion and referral abuse in e-commerce: ravelin.com/insights
- W3C, Mitigating Browser Fingerprinting in Web Specifications, on the deliberate reduction of passive device entropy: w3.org/TR/fingerprinting-guidance
- European Banking Authority materials on strong customer authentication under PSD2, relevant to sequencing any additional checkout step: eba.europa.eu
- General Data Protection Regulation, Article 5, data minimisation, relevant to retaining device and behavioural data about non customers: gdpr-info.eu/art-5-gdpr
Every promotion engine offers one per customer, and every promotion engine implements one per account. The distance between those two sentences is the whole business of promotion abuse.