Guides / How to build

How to Build a Referral Program: Links, Tracking, Rewards and Fraud Rules

How to build a referral program: unique links, attribution, when a referral counts, two-sided rewards, fraud checks, payouts, and when to use a referral tool.

Mythex Team · 2026-09-29 · 6 min read

A referral program rewards existing customers for bringing in new ones. To build one you need a unique code or link for each customer, a way to remember that code when a new visitor arrives, a record linking the new account to the referrer, a clear rule for when a referral qualifies, a reward (credit, discount or cash), and checks that stop people from referring themselves. The code is not the hard part. The hard parts are choosing a qualifying event that reflects real value and designing rewards that do not cost more than the customers they bring in.

Decide the rules before you build

Write these down first. Each one changes the build:

• Who can refer? Every customer, only paying customers, or only after they have been with you a while?
• What counts as a successful referral? Sign-up, first payment, first order over a certain amount, or staying past a refund or trial window?
• What is the reward, and for whom? Referrer only, or both sides (a "give $10, get $10" double-sided offer)?
• What form does the reward take? Account credit, a discount code, a free month, a physical gift, or cash.
• Are there limits? A cap per person per month, an expiry date on credit, one reward per new customer.
• How long does a referral link stay valid? If someone clicks today and signs up in three weeks, does it still count?

A simple, common setup: both sides get account credit, and the referral qualifies when the new customer's first payment clears and the refund window has passed.

What the program needs

Data

Keep referrals and rewards separate. A referral can exist without a reward (pending or rejected), and a reward can be reversed if the referred customer asks for a refund.

Pages and pieces

• "Refer a friend" page in the customer's account: their link, share buttons, and a list of their referrals with statuses and rewards earned.
• Landing experience for the referred visitor: "Alex gave you $10 off your first order", with the offer applied at checkout or sign-up.
• Attribution logic that stores the code when someone arrives via a link and attaches it to the account at sign-up.
• Qualification logic that runs when the qualifying event happens, often triggered by a payment webhook.
• Admin view: all referrals, pending approvals, flagged ones, total rewards issued.
• Terms page stating the rules plainly.

How attribution works

1. Alex shares yourapp.com/?ref=ALEX42.
2. Sam clicks. The app saves ALEX42 in a cookie or local storage, with a date.
3. Sam browses, leaves, comes back days later, and signs up. At sign-up, the app reads the saved code and creates a pending referral from Alex to Sam.
4. Sam pays for a first order. The payment provider notifies your app; after the refund window, the referral becomes qualified.
5. The app issues both rewards and tells Alex.

Also let people type a code at sign-up or checkout, for referrals that happen by word of mouth. Decide what happens if someone arrives through two different links; "last link clicked wins" is the usual rule.

Fraud and abuse

Any reward worth having will be tested. Basic protections:

• No self-referrals: reject when the referred account shares an email, payment card, phone number or delivery address with the referrer.
• Qualify on value, not sign-up: a paid, non-refunded order is much harder to fake than an email address.
• Waiting period before a reward is usable.
• Caps per referrer per month.
• Manual review for anyone whose referrals spike suddenly.
• Reverse rewards if the qualifying payment is refunded.

Rewards and payments

Account credit is the easiest reward to run: it is a number on the customer's account that checkout subtracts. Discount codes work well for stores. Cash payouts are the hardest: you collect payout details, handle failed transfers, and may have tax reporting duties depending on where you and your customers are, so check local rules or ask an adviser. If you take payments with Stripe or similar, let the payment webhooks drive qualification. Our guide to adding payments covers the setup.

A first prompt that works

Add a referral program to our meal-kit subscription app. Every signed-in customer gets a unique referral code and a share link like /?ref=CODE. When a visitor arrives with ?ref=, store the code in a cookie for 30 days and attach it to their account when they sign up. The referred customer gets $15 off their first box automatically. Create a pending referral at sign-up; when the referred customer's first payment succeeds (from the existing Stripe webhook) and 14 days pass without a refund, mark it qualified and add $15 account credit to the referrer. Reject self-referrals where the email, card fingerprint or delivery address matches the referrer. Cap rewards at 10 per referrer per month. Add a Refer a Friend page showing the customer's link, share buttons and their referrals with status. Add an admin page listing all referrals with filters for pending, qualified, rejected and flagged. Store everything in the database.

Build steps

1. Codes and the refer-a-friend page. Generate a code per customer, show the link.
2. Attribution. Store the code on arrival, attach at sign-up, allow manual entry.
3. Referred-customer offer applied at checkout or sign-up.
4. Qualification on the payment event, with the waiting period.
5. Rewards issued as credit, and credit applied at checkout.
6. Fraud checks and caps.
7. Admin view and notifications ("Sam just joined with your link").
8. Test end to end with test payments: refer, sign up in a private window, pay, refund, and check the reward is reversed.

Common mistakes

• Rewarding sign-ups. Invites fake accounts.
• Rewards larger than a customer is worth. Work out what a new customer typically brings in before setting the amount.
• Codes lost between click and sign-up. Test the case where someone clicks, leaves and returns later.
• No reversal on refunds.
• Hiding the program. Put the link in the account menu, the order confirmation and a post-purchase email.
• Vague terms. Unclear rules lead to support tickets and disputes.

When a referral tool is the better choice

Referral and affiliate platforms handle attribution across devices, fraud detection, payouts and tax forms, and they integrate with common store and billing systems. If you run an online store on a hosted platform, check its app marketplace first; a referral app may take minutes to install. If you plan to pay cash commissions to many partners, an affiliate platform is usually safer than building payouts yourself.

Build your own when your product already has accounts and payments you control, when rewards are account credit rather than cash, or when the rules are specific to your business. For pre-launch "invite friends to move up the list" mechanics, see how to build a waitlist page. For repeat-purchase rewards rather than referrals, see how to build a loyalty program app.

Building it with Mythex

On Mythex you can ask the agent to add a referral program to an app you are building, and test the whole flow in the live preview. The agent adds a dedicated Postgres database when referrals need saving (or type /database). Mythex does not include built-in sign-in or payments for the apps you build: you connect your own auth and your own Stripe account, with keys stored as project secrets (Stripe recipe). Payment webhooks need a public URL, so publish before testing them end to end (webhooks recipe).