Fraud prevention
The deterministic controls that decide whether a validated referral gets paid, the evidence behind every decision, and how outcomes reach your bill.
Referral fraud is cheap to commit and expensive to ignore: self-referrals from fresh emails, device farms grinding out signups, friends-and-family rings that subscribe and immediately cancel. Invitebase treats fraud defense as a core pillar, not an afterthought.
Every referral is checked the moment its qualification gate is satisfied, before any reward can be paid. The check is deterministic — rules that either fire or don't, evaluated against the referral, its referrer, and your app's recent activity.
One decision, and it's final
Every validated referral reaches one of two outcomes, on the pass that validates it:
| Decision | Reason code | What happens |
|---|---|---|
| Approved | criteria_met | No rule fired. The referral's rewards become payable, subject to any hold window. |
| Rejected | blocklist_match | A rule fired. The referral is rejected, its rewards are rejected with it, and nothing is billed. |
Reason codes are machine-readable on purpose: they double as the labels the models train on, and a chart of why your referrals were rejected can't be built out of prose.
There is deliberately no third state. Nothing sits in a queue, waits on a score, or expires on a timer — a probabilistic judgement should inform a person, not make a binary payout decision, so only rules that are conclusive on their own decide whether money moves. Because nothing waits, there is no manual review queue: the Fraud dashboard is for reading decisions and managing block lists, not for dispositioning referrals by hand.
The controls
Block lists are the conclusive rule at the fraud decision. The rest of the deterministic controls act earlier in the same pipeline — eligibility before the gates start counting, caps as rewards are created — so a referral that fails one never reaches a fraud decision at all.
| Control | Where it acts | What it catches or enforces |
|---|---|---|
| Block lists | Ingestion and the fraud decision | Known bad actors: per-app lists of email addresses and domains, device identifiers, and referrer accounts. A hit is conclusive — it does not improve with more evidence — and rejects the referral outright. Invitebase's central disposable-email and VoIP-number lists apply alongside your own. |
| Eligibility | Before the gates | Whether the referred user qualifies at all: must create an account, must start a paid subscription when the campaign requires one, must be a genuinely new account, and must have no prior paid subscription — so you reward real new customers, not returning users recycling the program. See eligibility. |
| Reward caps | Validation | Runaway earning: max rewards per referrer, per campaign, and per rolling month. A cap that bites suppresses the reward rather than the referral, and the suppression is recorded on the validation record. |
| Self-referral detection | Validation | Referrer–referee identity overlap: normalized email matching (case, dots, plus-addressing), disposable-email and VoIP-number lists, device-identifier match, and payment-fingerprint match where a billing integration makes it visible. |
| Velocity limits | Validation | Bulk abuse: too many referrals from one referrer, IP/subnet, or device in a window. On Android, Install Referrer click/install timestamps also expose click-injection (impossible click-to-install timing). |
| Payout-method dedup | Fulfillment | Farming: the same PayPal email, Venmo handle, or bank fingerprint attached to multiple referrer accounts. |
The evidence behind every decision
Every decided referral carries the evidence it was decided on, so an outcome is never a black box:
- The rule that fired — the reason code, plus the signals behind it: which list matched, on what value, and whether it was your list or Invitebase's central one.
- Referrer standing — account tenure before they referred, and how many of their past referrals validated versus were rejected.
- Velocity — referrals from this referrer over the last day and week, and referrals across your whole app sharing this one's click identifier. That last one is app-wide by design, because a device farm spreads its signups over many referrer accounts.
- The validation record — the immutable gate evaluation that validated the referral: the spec exactly as it was evaluated, not as the campaign reads today, plus any rewards a cap suppressed.
- The rewards — every reward the referral produced and where each one landed.
You read it per referral in the Fraud dashboard, or from a user's profile when someone writes in.
After the decision
The decision is final, but it isn't the last word on the money. A refund or chargeback landing inside the reward's hold window claws the reward back before it is ever paid, and connected billing integrations — RevenueCat, Adapty, Stripe Billing — feed those signals in automatically. Reversing a referral after validation reverses its billing with it.
What it means for your bill
Fraud outcomes and billing are coupled by design: a rejected referral is never billed, and one reversed after validation generates a billing adjustment on your next invoice. The fraud chart reports the approved-versus-rejected mix over time and the reward spend your controls blocked before it was paid — so the value of the pipeline is a number, not a promise.
Test-mode referrals flow through the same rules and the same decision so you can rehearse safely, but they never bill and never move money. See Environments and test mode.