How to design a referral program that can't be gamed
Every automated monetary incentive is, underneath, a security system. The rules that separate a healthy referral program from one that self-destructs.
A referral program looks, at first glance, like a simple feature: one user shares a code, another uses it, both get a credit. The real complexity shows up once you recognize what it actually is: a system that automatically gives away money based on a condition the user themself controls. Any system shaped like that will be attacked, not because users are inherently dishonest, but because a poorly protected monetary incentive is, literally, an invitation.
The most obvious attack vector, and why it isn't the only one
The most obvious fraud is self-referral: creating a second account to "refer yourself" and collect the credit on both sides. Blocking this with just a unique: true on the referral code isn't enough, because the attacker doesn't reuse the same data, they change the email, change the phone number, sometimes even change the shipping address. The design question isn't "how do I stop the same data from being used twice?" It's "what signals, combined, make two accounts likely to be the same person?"
Some signals that generalize well:
- Shared shipping or billing address between the referrer and the new user.
- Same device or network fingerprint at the time both accounts were created.
- Suspicious timing pattern: accounts created seconds apart, repeatedly.
No single signal is conclusive on its own, a shared address can be legitimate (a couple, a family). The correct design doesn't block on one signal, it accumulates evidence and decides with a threshold, the same way a payment fraud detection system does.
The second vector: volume abuse, not identity
Even with verified identity, an uncapped referral program is vulnerable to volume abuse: someone generating dozens of technically legitimate referrals in a pattern that, while valid, isn't the behavior the program intended to incentivize. The defenses here are different: caps on accumulated credit, expiration windows that force the benefit to be used soon instead of piling up indefinitely, and per-period limits that make scaling the abuse unprofitable.
The design rule that keeps repeating
What ties both vectors together is a simple idea: an automated incentive should never depend on a single condition that's easy to fake. "New buyer" isn't a robust condition if "new" is defined only by a different email. "One use per order" isn't robust if it isn't also tied to the actual identity of the buyer. Every naive business rule ("only new buyers can use the code") needs to translate into two or three independent technical signals, because an attacker only needs to find the weakest one.
Why this generalizes beyond e-commerce
Any system that automatically hands out value based on a user action, referral credits, cashback, rewards for completing an action, inherits this same problem. The security engineering here isn't exotic: it's applying the same defensive thinking you'd use for authentication or payments to a place that intuitively feels like "just a marketing feature." Treating a monetary incentive as a product feature, without the security rigor it deserves, is the most common way these programs end up costing more than they generate.