Would you like to stop self-referrals, duplicate claims, and bots from abusing your referral program? RewardsWP checks every referral claim before it issues a reward. The referral checks run behind the scenes with no setup required and guard your referral program from the moment you enable it.
In this guide, we’ll walk you through each fraud prevention mechanism, what happens when fraud is detected, and how to review suspicious referrals.
- How Does Fraud Prevention Work?
- Self-referral detection
- Existing customer detection
- IP-based referral limiting
- Additional protections
- What happens when fraud is detected
- Reviewing and managing suspicious referrals
- Frequently asked questions
Before you get started, make sure RewardsWP is installed and activated on your WordPress site.
How Does Fraud Prevention Work?
RewardsWP’s fraud prevention is automatic and always active when the referral program is enabled.
Every time a referred visitor attempts to claim a reward, RewardsWP runs a series of checks before the reward is issued. If any check fails, the claim is blocked and the visitor sees an error message.
The three core mechanisms are:
- Self-referral detection: Prevents advocates from using their own referral link to earn rewards.
- Existing customer detection: Stops current customers from claiming friend rewards meant for new customers.
- IP-based referral limiting: Caps the number of referrals that can originate from a single IP address.
Each mechanism runs on its own. A single claim attempt is checked against all three, and any one of them can block the reward.
Self-referral detection
Self-referral detection prevents an advocate from referring themselves to earn both sides of the reward. When someone tries to claim a reward using an email that matches or closely resembles the advocate’s email, RewardsWP blocks the claim.
How it works
RewardsWP doesn’t just check for an exact email match. It uses two techniques to catch advocates who try to disguise their identity:
- Email normalization: Before comparing emails, RewardsWP normalizes both addresses to account for common tricks. For all email providers, it strips plus-addressing (so
[email protected]resolves to[email protected]). For Gmail and Googlemail addresses specifically, it also removes dots from the local part. So[email protected]is treated the same as[email protected]. These are common tactics people use to create “different” email addresses that all route to the same inbox. - Fuzzy matching: Even after normalization, RewardsWP measures how similar the advocate’s email and the friend’s email are. If the two emails are within two characters of each other, the claim is blocked. This catches cases where someone changes a single letter or swaps two characters to create a nearly identical address.
Error shown to the visitor
When a self-referral is detected, the visitor sees:
“Self-claiming a reward is not allowed.”
The reward is not issued. No referral record is created for the attempt.
Next, RewardsWP checks whether the visitor is already a customer of your store.
Existing customer detection
This check prevents your current customers from claiming the friend reward, which is intended only for new customers. Without this safeguard, existing customers could use a friend’s referral link to get a discount on a purchase they were already going to make.
How it works
When a visitor attempts to claim a friend reward, RewardsWP checks whether their email address belongs to an existing customer in your store. If a match is found, the claim is blocked.
This is a straightforward email lookup against your existing customer records. If the visitor’s email is already associated with a customer account, they’re not eligible for the friend reward.
Error shown to the visitor
When an existing customer attempts to claim a friend reward, they see:
“It looks like you are already a customer of this site, only new customers can claim rewards.”
Next, RewardsWP limits how many referrals can come from one IP address.
IP-based referral limiting
IP-based limiting prevents a single household, office, or bad actor from generating an excessive number of referrals from the same network.
How it works
RewardsWP tracks the IP address of each visitor who claims a referral reward. Once ten referrals have been recorded from the same IP address within a seven-day rolling window, any further claims from that IP are blocked.
Ten referrals is generous enough for a shared network (like a family or small office) while still catching organized abuse. The rolling window means the count resets naturally as older referrals age past seven days.
Error shown to the visitor
When the IP limit is reached, the visitor sees:
“You already claimed a reward on this site. Rewards can only be claimed once.”
The reward is not issued for the 11th (and any subsequent) attempt from that IP within the seven-day window.
The message doesn’t name the IP limit. If a customer on a shared network, such as an office, reports this message, the IP limit may be the cause.
Additional protections
Beyond the three core mechanisms, RewardsWP includes two more layers of protection.
Visit-to-referral tracking
RewardsWP ties each referral to one browsing visit. This means one session can’t create duplicate referrals.
If a referral link click already created a referral for that visit, RewardsWP won’t create a second one in the same session. This stops scenarios where refreshing a page or navigating back and forth can create multiple referral records.
Spam protection on sign-up, sign-in, and friend gift forms
RewardsWP also protects the rewards widget forms that let a visitor in or claim a gift: sign-up, sign-in, and the friend gift form. Without it, bots can join your program through the widget.
The widget signs customers up itself. A CAPTCHA plugin on your store can’t protect it. That’s why the protection is built into RewardsWP, with two choices:
- Honeypot: the default. It protects the sign-up form, and the friend gift form on Basic and up, with no setup. It’s a hidden field that real visitors never see. Bots that fill it in are stopped. Choose this if you don’t want to create a Cloudflare account.
- Cloudflare Turnstile: a check from Cloudflare that guards sign-up, sign-in, and friend gift. It runs invisibly, unless Cloudflare asks the visitor to interact. It needs a free Cloudflare account, a site key, and a secret key. Choose this if you want the check to guard sign-in too.
Sign-in never uses Honeypot, because browser autofill can trip a honeypot. The friend gift form is available on the Basic, Plus, and Pro plans.
To choose a method and add your Turnstile keys, see the spam protection settings.
What happens when fraud is detected
When any fraud check fails, two things happen:
- The reward is not issued. The visitor sees an error message (specific to the type of fraud detected) and doesn’t receive a coupon, discount, or any other reward.
- No referral record is created in many cases. The Blocked status is one you set yourself when you review referrals.
This is an important distinction: fraud prevention is proactive, not reactive. It stops bad claims before they happen rather than flagging them afterward.
Reviewing and managing suspicious referrals
While the automatic protections handle the most common fraud scenarios, review your referrals periodically for patterns that the automated checks might not catch, such as:
- Multiple referrals from the same advocate that all convert within minutes
- Referrals where the advocate and friend share a similar name or domain
- An unusually high volume of referrals in a short time period
Where to review referrals
From your WordPress admin sidebar, go to RewardsWP » Referrals. This screen lists every referral record. From here, use the status filter buttons at the top to switch between All, Completed, Canceled, Pending, and Blocked views.
Each referral has a status that shows how it was handled.
Referral statuses relevant to fraud
| Status | Meaning |
| Blocked | You manually blocked this referral. Rewards are not issued. |
| Canceled | The referral was canceled (for example, the associated order was refunded). |
Both statuses prevent reward issuance and communicate different intent. To handle suspected fraud, use Blocked. For legitimate referrals that were reversed, use Canceled.
Note: If rewards were already delivered for a completed referral, you’ll need to handle those adjustments separately after you block or cancel it.
That’s it! You know how RewardsWP protects your referral program and where to review suspicious referrals. Next, to turn on Cloudflare Turnstile for the rewards widget, see the spam protection settings.
Frequently asked questions
Below, we’ve answered some of the most common questions about preventing referral fraud.
Do the fraud checks apply to my advocate and friend rewards?
The self-referral check prevents an advocate from claiming as their own friend. The existing customer check applies to friend reward claims specifically, since friend rewards are intended for new customers. The IP limit applies to all referral claims regardless of which side of the reward is being claimed.
Does my CAPTCHA plugin protect the rewards widget?
No. The rewards widget signs customers up itself. A CAPTCHA plugin on your store can’t protect its forms. RewardsWP has its own spam protection for the widget.
For the two choices, see the Spam protection on sign-up, sign-in, and friend gift forms section above.