RewardsWP includes built-in fraud prevention that automatically protects your referral program from self-referrals, duplicate claims, and abuse from existing customers. These protections run behind the scenes with no configuration required, so your referral program is guarded from the moment you enable it.
This guide explains each fraud prevention mechanism, what happens when fraud is detected, and how to review suspicious referrals.
How fraud prevention works
RewardsWP’s fraud prevention is automatic and always active when the referral program is enabled. There are no settings to toggle and no configuration screens to visit. 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 independently. 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] it resolves to
john@. For Gmail and Googlemail addresses specifically, it also removes dots from the local part (soyoursite.com[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 2 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, and no referral record is created for the attempt.
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.”
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 10 referrals have been recorded from the same IP address within a 7-day rolling window, any further claims from that IP are blocked.
The limit is set at 10 referrals per IP address within any 7-day period. This threshold is generous enough to accommodate shared networks (like a family or small office) while still catching organized abuse. The rolling window means the count resets naturally as older referrals age past 7 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 7-day window.
Additional protections
Beyond the three core mechanisms, RewardsWP includes two more layers of protection:
Visit-to-referral tracking
RewardsWP connects each referral to a specific visit using a visit ID stored in a browser cookie. This prevents duplicate referrals from the same browsing session. If a visitor has already been tracked through a referral link click and a referral has been created for that visit, a second referral won’t be generated for the same session. This stops scenarios where refreshing a page or navigating back and forth could create multiple referral records.
Honeypot anti-spam
RewardsWP includes a honeypot field on referral forms. This is an invisible form field that real users never interact with but automated bots typically fill in. When the honeypot field contains a value, the submission is silently rejected. This helps prevent bot-driven referral spam.
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 automatic status change. RewardsWP does not automatically set any referral to a “blocked” status. The fraud checks prevent the reward from being claimed in the first place. In many cases, no referral record is created at all for the blocked attempt.
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, you should still periodically review your referrals 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
Navigate to RewardsWP » Referrals to view all referral records. Use the status filter buttons at the top to switch between All, Pending, Blocked, Completed, and Canceled views.
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, but they communicate different intent. Use Blocked for suspected fraud and Canceled for legitimate referrals that were reversed.
Blocking or canceling a completed referral won’t automatically reverse rewards that have already been issued. If rewards were already delivered, you’ll need to handle those adjustments separately.
Frequently asked questions
Do the fraud checks apply to both 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.