--- title: "Referral fraud detection: check claims before rewards" description: "Connect referral fraud detection to referrers, claimants and qualified events. Review self-referrals, reward states and reversals before paying an incentive." status: published author: Michael Delgado datePublished: 2026-10-21 dateModified: 2026-10-21 --- # Referral fraud detection: check claims before rewards *By Michael Delgado · Published 2026-10-21 · Last updated October 21, 2026.* Referral fraud detection evaluates whether a claimed referral and its reward meet the program’s rules. It should connect the referrer, referred customer, qualifying event and benefit state. Related-account evidence can support an investigation, but the program must define what counts as an eligible relationship before automatically withholding a reward. ## Write down what the referral is supposed to prove A referral code can attribute a signup to a participant without proving that the signup is new, independent or qualified for a reward. Decide which of those conditions actually applies. A family member, employee or existing customer may be allowed in one program and excluded in another. Specify the qualifying event. It might be a completed paid order, verified account activation or another business outcome. A signup-only reward creates a different operating problem from a reward paid after a purchase and return window. Keep the attribution claim separate from the entitlement. The [affiliate-fraud guide](/blog/affiliate-fraud-detection/) covers publisher and channel attribution; this article focuses on participant-to-participant referral rewards. ## Build a reward state machine | State | Business meaning | Information to preserve | | --- | --- | --- | | Referred | A referral route was recorded | Referrer, claimant and campaign | | Pending | Qualification or review is incomplete | Expected event and review owner | | Qualified | The program conditions are met | Qualifying event reference | | Granted | The reward was issued | One grant reference and benefit value | | Reversed | A defined condition invalidated the grant | Reason and original event linkage | Make repeated callbacks safe. A duplicate qualifying event should not create a second reward. If a later cancellation matters, reconcile it against the existing claim rather than deleting the evidence of the original grant. ## Evaluate self-referrals through policy and evidence A self-referral can violate an offer that requires an independent new customer. The business should establish how it evaluates that relationship and what evidence is sufficient for review. Device context, shared payment details and repeated business artifacts can be relevant, but each has legitimate explanations. A team may use one approved corporate payment method. Several people can share a device. A relationship is an investigation input, not automatically proof that the same person owns both accounts. Read the [multi-accounting evaluation guide](/blog/multi-accounting-detection-tools/) before buying a product for linkage alone. Ask to see an ambiguous relationship and an authorized correction, not only an obvious repeat-claim example. ## Check the qualifying event before payout For a hypothetical referral offer that rewards a first completed order, the ledger should reference that order’s actual status. A created checkout session and a settled qualifying purchase are not equivalent events. The program may also need to consider cancellation or refund according to its terms. Assign ownership for manual rewards and exceptions. Keep the reason, scope and authorizing account in the record. A support exception for one disputed claim should not remove every future eligibility check for that participant. The [promotion-code guide](/blog/promo-code-abuse-prevention/) explains customer-facing redemption. A referral reward may depend on the same purchase while remaining a separate benefit owed to another party. ## Use layered controls without making referral unusable Introduce proportionate checks around value and uncertainty. A pending reward can create time for qualification or review without necessarily preventing the referred customer from using the product. Avoid a blanket network rule. Shared corporate and household connections can be normal sources of genuine referrals. Examine whether your policy is excluding the audience the campaign was designed to attract. If stronger verification is needed, check the actual claim it establishes. Mailbox access, account authentication and identity proofing serve different purposes. The product team should be able to explain why a particular step is relevant to the reward. ## Reconcile value and customer impact Track qualified customers, reward value granted, reversals, review effort and legitimate claims held incorrectly. Keep the conversion event definition stable during the evaluation. A large reduction in payouts does not establish success if valuable valid referrals also disappear. Review participants with many unknown outcomes rather than automatically treating them as confirmed fraud. Preserve the program and policy version so that later campaign changes do not rewrite the meaning of earlier activity. Use the [fraud dashboard guide](/blog/fraud-decisioning-dashboards/) for a view that separates referral observations, pending decisions and final reward outcomes. That separation also makes commercial reconciliation easier. ## FAQ ### Is every referral between related people invalid? No. The program’s terms define eligible relationships. Evaluate the evidence against that rule rather than treating every shared environment as a violation. ### When should a reward be paid? Choose a point consistent with the qualifying event, reversal risk and published program rules. Record which event authorized the grant. ### Can a coupon system manage the entire referral program? It may handle a discount, but the program can still need referrer attribution, qualification, reward state and reversal records. ## Sources - [Stripe: coupons and promotion codes](https://docs.stripe.com/billing/subscriptions/coupons). - [Stripe: idempotent requests](https://docs.stripe.com/api/idempotent_requests). - [OWASP: transaction authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html).