A More Secure Android Referral System

The hard part of a referral system is not generating a referral link. It is proving that a genuinely new user was brought by the correct referrer, that the app and the request are legitimate, and that the reward has not already been earned or claimed.

This is the short version of the guide I wrote while building ReelBlink's own referral system. The PDF below is the same material as a three-page reference you can keep open while you build.

The mistake most referral systems make

Generate a code, friend enters it, code is valid, give reward. It is easy to build, and it is easy to abuse, because a valid referral code does not prove a genuine new user was acquired. People can refer themselves, create multiple accounts, uninstall and reinstall, switch Google accounts, replay the same request, or modify the app.

A referral code should answer one question only: who gets credit. It should not be the proof that the referral is genuine.

Google Play gives you building blocks, not a program

There is no button in Play Console that creates a referral program. You still build the reward logic, referral UI, rules, backend validation and reward storage. What Google does give you is a set of signals, and each one answers a different question:

• Play Install Referrer — where did this installation come from?
• Authentication — which user or account is this?
• Play Integrity API — does this request come from an expected Play app and device environment?
• Server validation — does this referral satisfy our rules?
• Device Recall — has this device already participated in this one-time promotion?

Define "successful referral" properly

Not a link click. Not an install on its own. A stronger definition stacks the signals:

referral attribution + eligible new user + authentication + required onboarding + integrity check + server validation

After you detect attribution, treat it as a pending referral. The app may request a reward; the server decides whether it is valid.

Rules that keep it honest

• Rewards belong to the server. Never let the app set something like premiumPackUnlocked = true.
• Never trust a client claim. Sending integrityPassed = true from the app proves nothing — verify the integrity token server-side.
• Keep a reward history, not just a counter. You get auditing, duplicate protection and answers for support cases.
• A stable internal user ID beats an email address as the main identifier.
• Temporary failure is not fraud. On an outage or a rate limit, keep the referral pending and retry. A genuine user should not lose a reward because your infrastructure had a bad minute.

Device Recall is useful, not required for v1

Play Integrity does not solve the same-phone / new-account case on its own. Device Recall can, by remembering limited abuse-related state for a device. At the time the guide was written it was available through a beta / controlled-access process.

A strong v1 works without it: install referrer, authentication, Play Integrity and server-side validation. If Device Recall is not enabled, do not claim that same-device abuse is solved — be honest about the limitation.

One thing that trips people up: linking a Google Cloud project for Play Integrity does not mean your backend has to run on Google Cloud Run. The project is for API configuration and authorization only.

What is in the PDF

The abuse-case table (ten attacks and the protection for each), the common mistakes list, and the pre-launch testing checklist — the parts worth keeping next to you while you implement.