Linked vs. validated

Every referral in Invitebase passes through two very different milestones, and keeping them apart is the core of the product:

Referral lifecycle: a user clicks a link and is linked to a referrer, then completes the required actions to become validatedScreenshot coming soon

• Linked — the referral is bound to a referrer. A referred user clicked a link, installed or signed up, and attribution tied that signup to whoever invited them. The referral enters signed_up.
• Validated — the referral is real. The referred user completed the campaign's qualification gates within the window, and the referral cleared the deterministic fraud controls on the same pass. The referral enters validated.

Why rewards and billing only fire on validated

The split is enforced as a hard invariant through the engine, reward release, and billing:

• Rewards. No code path releases a reward from signed_up or in_progress. Rewards are created automatically at validated and only there — so a fraud ring generating thousands of fake signups earns nothing, and your reward budget maps one-to-one to referred users who did the thing you actually value.
• Billing. Validated referrals are the billing unit: the first 100 per month are free, then your plan's per-referral rate, metered via Stripe. Linked-but-never-validated referrals are free, in unlimited quantity. Test-mode and fraud-rejected referrals are never billed. If a referral is rejected or clawed back after validating (during the hold window), a billing adjustment excludes or credits it on your next invoice.
• Store policy. Rewards that vest on validated in-app conversion events — never on installs — are also what keep your app compliant with App Store and Play rules on incentivized installs.

The same gate that protects your reward budget protects the meter you're billed on. Invitebase has no incentive to let junk validate: fraud that slips through erodes trust in the billing unit itself.