Referral fraud on Shopify: self-referrals, household rings, and code leaks

Every referral program rests on one assumption: the sharer and the redeemer are different people. Most of the time they are. Sometimes they are not.

The "sometimes they are not" case is bigger than most merchants expect, because the standard referral app checks one thing before it pays out: is the redeemer's email different from the sharer's email? That check passes for a Gmail alias, for a roommate, for a stranger who found the code on Slickdeals, and for a professional running twenty identities.

If your store runs referrals through Bubblehouse, ReferralCandy, Smile.io, LoyaltyLion, or a custom rail, some of the credit it pays is going to people who did not refer anyone. This guide covers the four patterns, why the apps miss them, how detection at checkout works, and the program settings that limit the damage even when detection misses.

The four referral fraud patterns

Self-referral

The clearest case. One person, two emails. The customer creates a referral link from their account, then orders through their own link with a second address, often a [email protected] alias of the same inbox. The program issues credit to a sharer who referred nobody.

Sometimes deliberate. Sometimes naive: "my friend forgot to use my code, so I'll use it myself." Either way the payout is wrong.

Where the apps fail: they compare the sharer's email to the redeemer's email. The emails are different, so the check passes. None of the major referral apps cross-reference phone, address, IP, or device by default.

Household or roommate rings

Siblings, partners, roommates, parents and adult children. Two real people, same shipping address, often the same card and the same WiFi. Each refers the other, both earn credit, both order. The program pays twice for what would have been a shared recommendation anyway.

This is the messiest pattern because the customers are real. Whether it counts as fraud depends on your program's economics. A high payout tilts toward withholding; a small one tilts toward allowing. The point is to be able to tell, which requires detection.

Where the apps fail: different emails, usually different phones, different names. From the app's point of view these are two separate referrals.

Referral farms

Less common, more organised. Operators run referral programs across many Shopify stores as a side income, using anti-detect browsers, residential VPNs, and a small inventory of phone numbers and mail-forwarding addresses. The signature is statistical: an unusual concentration of attributions inside a small group of identities.

Where the apps fail: each referral looks plausible on its own. The apps do not aggregate behaviour across identities and have no notion of "this looks like a farm."

Leaked codes claimed by strangers

A referral code is posted to a deal forum, shared in a group chat, or picked up by a coupon extension like Honey or Capital One Shopping. Strangers use it. The original sharer earns credit for every redemption from people they have never met.

Where the apps fail: attribution is technically correct. The redeemer did use the sharer's code. The problem is that nobody was referred. We cover the extension side of this in Capital One Shopping and Honey on Shopify.

Referral fraud detection at checkout: sharer equals redeemer, shared device, shared address

The check that closes patterns one and two is a multi-signal identity comparison between sharer and redeemer, run at checkout, before any credit is minted.

The signals that matter:

• Email, normalised. Gmail dots stripped, plus aliases collapsed, relay domains recognised. Catches the trivial self-referral.
• Phone, normalised to the last ten digits. Catches a shared household number.
• Shipping address, fuzzy matched. Catches roommates who ship to the same door.
• Billing address, matched separately from shipping.
• Device fingerprint and visitor cookie. Catches same-device, different-email.
• IP address. A soft signal on its own (offices, mobile carriers, VPNs), useful in combination.

A single email match is safe to block on, because two people do not share a normalised email. A single IP match is not, because coworking spaces and family WiFi share IPs. The model that holds up is composite: block when strong signals align, warn when one aligns alone, allow otherwise.

The moment matters as much as the method. Checking at redemption, while the referee is still in checkout, means the referee's order can proceed at whatever price the rule allows while the sharer's credit is withheld. No error, no accusation, no friction. The sharer simply never sees a credit event.

Referral fraud prevention by design: store credit with a 7-day hold date, clawback on refund, monthly cap per referrer

Detection will not catch everything. Anti-detect browsers randomise the device signature and residential VPNs randomise the IP. Program design limits what slips through.

Hold the credit. OfferGuard's native referral program holds the referrer's reward for seven days by default, configurable per store. A refund inside the hold costs you nothing, and the hold gives the identity engine time to observe overlap between sharer and redeemer that was not visible at checkout.

Pay in store credit, not cash. Rewards are issued as Shopify store credit. Store credit comes back to your store, and it can be debited.

Claw it back on refund. If the referee's refunds pass half of the order total, the referrer's credit is reversed with an equal debit.

Cap the payout. Each referrer can earn at most $200 of credit in a rolling 30 days by default. A farm that gets past detection still hits a ceiling.

Require a new referee. By default the referee must be a first-time customer, which is the same first-order check that protects welcome offers.

Expire the link. Share links expire after 90 days by default, so a link that leaked to a forum last year is not still paying out.

Why Bubblehouse, ReferralCandy, and Smile referrals slip through

Bubblehouse, ReferralCandy, Smile's referral feature, LoyaltyLion's referral module, and most custom rails share an architecture:

1. The sharer signs up and gets a code or link.
2. A friend clicks the link or enters the code at checkout.
3. The app checks that the redeemer's email differs from the sharer's, then credits the sharer.

The check is one identifier deep. It is bypassed by an alias, does not see a household, cannot spot a farm, and treats a leaked code as a successful referral. Some apps offer optional rules, such as ignoring referrals where the redeemer's IP matches the sharer's within a day, or holding credit for refunds. Those rules help. They do not close the category.

The reason is not negligence. These apps were built as marketing tools, and they are good at attribution, payout maths, and the share experience. Identity verification is a different product, and none of them built one.

How OfferGuard handles it

For third-party referral programs, OfferGuard gates the referee's code. It reads your discount codes from Shopify and classifies codes whose segment or title marks them as referral codes, with a pre-built template for Bubblehouse's "Referral via link" codes. When a referee applies a gated code at checkout, OfferGuard checks the buyer against the rule behind it: first order only, one redemption per email, per IP, per device, per visitor cookie, disposable email blocked. A buyer who fails keeps their order but loses the code, and because the code never applied, the referral app has nothing to attribute. The referral app keeps running your program. OfferGuard decides which redemptions count.

For OfferGuard's own referral program, available on the Enterprise plan, the self-referral guard is unconditional. At the moment a referral would attribute, the sharer's email and Shopify customer ID are compared with the redeemer's, and a match blocks the referral. The same check runs again when the order is paid. On top of that, the "Referral fraud protection" rule preset runs the multi-signal sharer-equals-redeemer check through the identity engine and withholds the incentive when it fires, with the referee's order still completing.

Every blocked or withheld referral is written to the decision log with the signals that overlapped, so you can see whether a flag looks like a self-referral (device and IP), a household (address and phone), or a cluster (many attributions sharing one device signature).

Frequently asked questions

Will customers notice when a referral credit is withheld?

No. The redeemer's order goes through, at full price or with whatever discount the rule allows. The sharer does not see an error or a rejection. They simply do not receive a credit event.

Does this work with Bubblehouse or Refersion?

The code-gating layer works with any app that issues referral codes through Shopify discounts. OfferGuard removes the code at checkout for buyers who fail the rule, so the referral never attributes. It does not connect to the referral app's own payout system.

Can I allow household referrals on purpose?

Yes. The block and warn thresholds for the identity check are configurable per store. Set them so that a shared address alone warns rather than blocks if your category is one where households genuinely share recommendations.

Does Shopify have a built-in check for this?

No. Shopify's discount engine has no concept of whether the sharer and redeemer are the same person. Attribution is whatever the referral app reports.

Will it catch referral farms using anti-detect browsers and residential VPNs?

Imperfectly. Those tools remove the device and IP signals. Shipping address and phone are harder to fake at scale because a real parcel has to arrive somewhere. The store-credit clawback on refund and the 30-day cap limit what a farm can extract even when detection misses.

What to do next

If you suspect referral fraud but have not measured it, install the free Watchdog plan and watch the decision log against your referral code redemptions. Sentinel adds the phone, address, IP, device, and visitor signals that make sharer-equals-redeemer detection work. Enterprise adds the native referral program with store credit rewards, the seven-day hold, and the clawback.

Related reading: promo abuse prevention for Shopify, why Bubblehouse self-referrals slip through, and why Shopify's "limit one per customer" isn't enough.