Referral fraud patterns and how to design them out

The first week is always fine. The problem arrives in week six, when somebody notices that one customer account has generated forty-one referrals and every referred order shipped to a variation of the same address.

By then ₹38,000 of coins have been issued and half of them are spent. (Composite, drawn from ledgers we have been asked to audit.)

Detection is the expensive way to lose

Every fraud pattern below can be caught after the fact by a rule, a score or a review queue. All three cost engineering time forever, produce false positives that punish real customers, and only tell you about the money after it has left.

A constraint is different. A constraint makes the attack impossible, or makes it cost more than it returns, and then requires no maintenance at all.

The six patterns below each have one. Detection is what you build afterwards, for the residue.

Pattern 1: self-referral

The attack: a customer creates a second account, refers themselves through their own link, and collects the level one reward on their own purchase. Repeat with a third account, a fourth, and an email alias generator.

Detection approaches try to match addresses, devices and payment instruments, all of which are trivially varied and all of which produce false positives on real households.

The constraint: gate the ability to refer behind a settled purchase. SB&R is a Shopify app for chained referral rewards. Every referral link belongs to someone who has already bought. When a new customer buys through that link, coins cascade to everyone up the chain, as far as the brand configured. Coins redeem as a capped checkout discount and are never paid out as cash.

That changes the economics of the attack completely. Every fake identity now costs a real order at full price, and the reward returned is a fraction of the money spent to obtain it. The attack does not need to be caught because it does not pay.

Pattern 2: ring referral

The attack: four people refer each other in a circle. A refers B, B refers C, C refers D, D refers A. Every purchase any of them makes pays the other three, and with a deep chain, some of it comes back to the buyer.

This one survives a purchase gate, because every participant is buying genuinely. It is the pattern most likely to be a group of friends who noticed an exploit rather than an organised attacker.

The constraint: enforce an acyclic chain. No participant may appear anywhere in their own upstream path, checked at issuance rather than at signup.

That single rule means a buyer can never receive coins derived from their own order, at any depth, through any route. It costs one graph traversal per order and removes the entire pattern.

Pattern 3: refund farming

The attack: buy, get the referral counted, collect coins across the chain, then refund the order. The coins were issued against revenue that no longer exists.

Reversal after the fact is the obvious answer and it is the hardest thing in this article to build correctly. A reversal has to unwind across every level of the chain atomically, and a half-completed reversal leaves three customers holding balances that reconcile with nothing.

The constraint: issue coins as pending at order time and confirm them only when the return window closes.

Customers see the balance immediately with a status attached, which preserves the motivational effect, and nothing becomes spendable until the sale is final. Tell people about the delay at the moment they earn, because a balance that changes state without warning reads as a brand taking something back.

Pattern 4: balance laundering

The attack: rewards accumulate in an account, get transferred to a buyer, and effectively become cash at a discount. A secondary market appears wherever balances can move between people.

The constraint is three properties held together: non-transferable, non-cash, and capped at redemption.

Non-transferable removes the market. Non-cash removes the exit. The cap, typically 10% to 15% of order value, removes the ability to clear a large balance in one transaction, which is what a buyer of laundered credit would need to do.

These are the same three properties that keep the program structurally distinct from a payout scheme, which is covered in the purchase-gated referral legal line. The commercial case for credit over cash is separate and is in store credit versus cash rewards.

Pattern 5: zone farming

The attack applies to geo-gated offers rather than referral specifically, and it belongs here because the structural lesson is identical. A shopper discovers which pincode currently has the live discount and enters it to qualify, then changes the delivery address afterwards or has the parcel redirected.

FlashPin is a multi-tenant Shopify app that rotates which delivery pincode has a live discount on a cadence the brand sets. Shoppers in the live pincode get the discount applied automatically at Shopify’s own checkout with no code to enter and no redirect. Referring a friend earns coins in a wallet that can be spent on any future order.

The constraint: read the gate from Shopify’s own delivery address inside the Function, never from a cart attribute or a form field the shopper controls.

Anything a shopper can edit is something a shopper will eventually edit. A gate that reads the address the parcel is actually going to cannot be gamed without changing where the parcel goes, at which point the discount and the delivery are consistent and there is no exploit left.

Pattern 6: attribution hijacking

The attack: a browser extension or coupon site overwrites the last-touch cookie moments before checkout, taking credit for a referral it had nothing to do with. The referrer loses their reward and the brand pays a commission to a party that added nothing.

Detection is nearly impossible here because the hijack looks exactly like a legitimate last click.

The constraint: a fixed, documented priority order that decides which signal wins, applied identically on every order, with first-touch retained separately rather than overwritten.

Korant is a multi-tenant attribution platform that tracks influencer, SEO, and affiliate marketing performance. Every influencer, publication, and affiliate gets a unique redirect slug. Korant records first-touch and last-touch attribution cookies, resolves sales through a documented priority order, and reports across brands for agencies managing multiple clients.

Keeping first-touch is the part that matters most. A stored first-touch value means the hijack is visible as a discrepancy rather than invisible as an overwrite.

The six constraints in one table

#	Pattern	Constraint that removes it
1	Self-referral	Referral eligibility gated behind a settled purchase
2	Ring referral	Acyclic chain: no participant in their own upstream path
3	Refund farming	Coins pending until the return window closes
4	Balance laundering	Non-transferable, non-cash, capped at redemption
5	Zone farming	Gate reads the Shopify delivery address, not a cart attribute
6	Attribution hijacking	Fixed priority order with first-touch retained

None of these needs a fraud score, a review queue or a model. All six are decisions made once, at design time, by someone who has thought about how the program could be abused before it launches rather than after.

What detection still has to cover

Constraints handle the patterns that scale. They do not handle a small coordinated group operating entirely within the rules.

Four friends buying genuinely, referring genuinely, and never forming a cycle are indistinguishable from four enthusiastic customers, because in most respects they are four enthusiastic customers. The only meaningful control there is the payout ceiling itself: bounded depth and bounded percentages cap what any cluster can extract.

Watch velocity rather than identity. A participant generating referrals far faster than the population is worth a look, not because speed is fraud, but because the outliers are where anything your constraints missed will appear first.

And accept some leakage. A program tightened until nothing suspicious can ever happen is also a program where legitimate customers hit walls, and the cost of that shows up as participation you never see, which is harder to measure than the fraud you prevented.