How to detect referral fraud with the Fraud center
Every reward you pay is only worth it if a real new customer is on the other end. The most common abuse is self-referral — one person playing both referrer and referee. The Fraud center watches for the patterns abuse leaves behind and surfaces only the referrers worth a second look, so you don’t audit every referral to catch the few that matter.
When a referred purchase trips a signal, Bloop holds the reward for 14 days, tags the order in Shopify as BLOOP suspicious referral, and opens a case. Genuine referrals flow through untouched. If the hold runs out with nobody acting, the reward is approved, unless the referrer is banned, the order was cancelled or refunded, the campaign has been turned off, or the order can no longer be found in Shopify (in the last two cases the referral stays Pending).
The signals Bloop looks for
Section titled “The signals Bloop looks for”| Signal | Shown as | What it catches |
|---|---|---|
| Self-referral (email) | Self Referral | Referrer and purchaser use the same email on the same provider apart from dots, +tag aliases or trailing digits, or a similar one |
| Self-referral (email alias, different domain) | Self Referral | The same name before the @, on two different providers |
| Self-referral (matching last name) | Self Referral | Referrer and purchaser share a last name, ignoring case and accents. Short surnames must match exactly to be flagged; longer ones are flagged when nearly identical |
| Self-referral (matching address) | Self Referral | The referrer’s default Shopify address matches the order’s shipping address |
| Self-referral (same IP address) | Self Referral | The order came from the referrer’s own IP address. Only checked while the IP address prevention check is on |
| Self-referral (same browser) | Self Referral | The order came from the referrer’s own browser. Only checked while the Browser prevention check is on |
| Same IP as referrer | Shared IP | By default, the referrer already has five earlier referred purchases from the same client IP within 30 days |
| High referral volume (7 days) | High volume | By default, the referrer already has seven earlier referred purchases in the past 7 days |
The self-referral signals are the strong ones: an alias address or a matching shipping address is a deliberate disguise a normal referral never produces. Shared IP and high volume are weaker: a household, an office network, or a genuinely viral advocate produce those symptoms honestly.
The shared-IP and high-volume reasons list the related order numbers, so you can open them and see whether the pattern looks organized or coincidental.
An exact email match is rejected, not held
Section titled “An exact email match is rejected, not held”When the purchaser’s email is the referrer’s own address (ignoring capital letters and +tag aliases, and dots in Gmail addresses), Bloop rejects the referral straight away instead of holding it for 14 days. No reward is issued, and the decision appears in fraud history. This only happens while Self-referral (email) detection is on for your store and for that referrer.
Choose which signals to use
Section titled “Choose which signals to use”Open Detection rules in the Fraud center to decide which signals flag a referral. Each detection signal is on by default and can be switched off for your whole store (the same-IP-address and same-browser signals follow the Fraud Prevention checks below instead). The two volume signals also let you set the number of referred purchases and the period to look back, in days.
Switch a signal off only when it keeps flagging referrals you always approve. For a single customer who keeps tripping a signal, excluding them from detection is usually the better fix.
Block abuse before it reaches the queue
Section titled “Block abuse before it reaches the queue”Two preventive checks sit under Fraud Prevention in the same Detection rules window, and they work differently from the signals: instead of flagging a purchase for review, they stop the discount being claimed at all. Both are off by default.
| Check | What it does |
|---|---|
| IP address | If the referrer and the referee share an IP address, the referee doesn’t get the discount |
| Browser | Stops a referrer following their own link and claiming the discount in the same browser |
While a check is on, Bloop also flags an order placed from the referrer’s own IP address or browser, which catches a purchase that got through anyway, for example with a shared code.
These are blunt by design, and that’s the trade-off: the browser check catches the laziest self-referral with almost no collateral damage, while the IP check will also block a genuine referral between two people on the same home or office network. Turn on the browser check as a matter of course; weigh the IP check against how much of your audience shares a connection.
They’re the front door, not a replacement for the Fraud center: an abuser using a second browser and a phone’s data connection walks past both, which is what the signals above are for.
Work the queue
Section titled “Work the queue”The Fraud center lists suspicious referrers with the activity that flagged them and days left to review. Sort your attention by that last column: a case at 1 day left is about to become a paid reward whether you look at it or not.
Open a referrer to see their flagged purchases — purchase ID, purchaser, signal type, days left — each with a link straight to the order in Shopify. The panel on the right shows their contact details, whether they’re Active or Banned, and whether detection is Enabled or Excluded for them.
You approve or reject the referrals themselves in Referral orders. Either decision closes the case here: approving records it as legitimate, rejecting confirms it as fraud.
Reading the evidence
Section titled “Reading the evidence”
| What you see | What to do |
|---|---|
| Same address apart from dots or trailing digits | Reject. Consider a ban if it repeats |
| Similar but different address, same domain | Look closer. Different people can have similar addresses |
| Email alias on a different domain | Reject — this takes effort to set up |
| Matching address | Reject. It’s the hardest signal to produce by accident |
| Matching last name only | Look closer. Family referrals are usually real |
| Shared IP only, unrelated real emails | Approve. It’s a household or an office |
| Shared IP and a self-referral signal | Reject — two weak signals reinforcing each other |
| High volume, varied IPs and emails, real names | Approve. This is what success looks like |
| High volume with repeated IPs or alias emails | Reject the batch and ban the referrer |
When the evidence is ambiguous, approving is the gentler default. A rejected genuine advocate usually stops sharing entirely — that costs more than one undeserved reward.
Ban a referrer
Section titled “Ban a referrer”Ban ends a referrer’s participation. It’s irreversible, and the modal makes you acknowledge that, because it does all of this at once:
- Their referral link and referral code stop working.
- Their unused reward codes, and the unused friend codes issued through them, are deactivated. Codes already used are not affected.
- No new referrals can be attributed to them.
- Pending referred purchases are disqualified.
- Purchases still inside the review period stop counting as referred.
- Rewards that were waiting are never sent.
Reserve it for a confirmed pattern: an exact email match, an alias address, or a repeat offender you’ve already rejected once.
Exclude a referrer from detection
Section titled “Exclude a referrer from detection”The opposite case: a genuine customer who keeps tripping the shared-IP signal because their whole family orders from one router. Exclude suspicious referral detection on their profile turns the checks off for that person only — their future referrals stop being flagged, and everyone else’s detection is unaffected. Enable detection puts them back.
Use it for the customer you’ve already cleared twice. It’s a tuning dial, not a reward — and a banned referrer can’t be excluded, since there’s nothing left to detect.
Fraud history
Section titled “Fraud history”Every decision is logged: the date, the referrer’s email, the signal type, the action taken, and whether the system or an admin took it. Search it by email.
Read it when you want to know whether your team is rejecting too aggressively, or when a customer disputes a decision and you need the record.
Common mistakes to avoid
Section titled “Common mistakes to avoid”- Rejecting on a single weak signal. A shared IP alone is a household. Wait for something to corroborate it.
- Banning a good customer instead of excluding them from detection. Ban is irreversible; exclusion is the right tool for a false positive.
- Letting the 14-day window lapse. The hold expires into an approval — a flag nobody reads protects nothing.
- Treating a family referral as fraud. A matching last name on its own is usually a real referral.
Next steps
Section titled “Next steps”- Approve or reject the individual orders in Referral orders.
- See the broader stance in preventing referral fraud without blocking real customers.