Promo codes that survive the install
Deep-linked promo codes survive the install gap: carry the code in the deferred payload, apply it automatically on first open, and guard against abuse.
Promo codes are one of the highest-intent links you have. Someone shares 'use SUMMER50,' a friend taps, installs, opens — and stares at a homepage with no code, no memory, and a manual-entry field they'll never use. The most motivated install you'll get all week, fumbled at the last step.
Where redemption breaks
The code lives in the link. The install gap strips it. Unless you carry the code in a deferred payload, the user has to remember it, retype it, and not make a typo — three places to lose them.
Carry it in the payload
Put the code and its constraints in the deferred deep link so the app receives them on first open.
{
"deepLinkPath": "/checkout",
"customData": {
"code": "SUMMER50",
"expiresAt": "2026-09-01",
"referrer": "alex-rivera"
}
}Apply it automatically
On first open, validate and apply the code before the user has to think about it. The first thing they see should be the discounted price, not an empty promo field.
LinkTrail.shared?.onLink { link, source in
guard let code = link.customData["code"], promos.isValid(code) else { return }
cart.apply(code)
router.navigate(to: link.path)
}Guardrails
- Honor expiry server-side — never trust the payload's date alone.
- Bind referral codes to the referrer so you can credit them and catch self-referral abuse.
- Rate-limit redemptions per device to keep a leaked code from becoming a budget hole.
Is a deep-linked promo code safe from abuse?
It is exactly as safe as your server makes it, and no safer. The payload arriving at first open is a claim from a client, not a fact — anyone can craft a link with any code in it. That is not a weakness specific to deferred links; it is the same rule as any client-supplied input, and it only bites teams who treat the payload as pre-validated.
So the link carries the code, and the server decides whether it applies. Validate the code, its expiry, its eligibility rules, and its per-user and per-device limits at redemption time. Done that way, a leaked link is worth no more than a leaked code has ever been, and you get automatic application without opening a hole.
What about referral programmes specifically?
Referrals add one requirement that ordinary promo codes don't: you need to know who referred whom, and you need that binding to be unforgeable. Attach the referrer to the matched install server-side rather than accepting a referrer ID the client reports, and self-referral becomes hard rather than trivial.
| Decision | Weak version | What to do instead |
|---|---|---|
| Referrer identity | Client sends its own referrer ID | Bind referrer to the server-side matched install |
| Reward trigger | Pay on install | Pay on a real activation event |
| Self-referral | Trust the account | Check device and match signals before payout |
| Reward timing | Immediate | Hold briefly so obvious fraud can be caught |
Paying on activation rather than install is the single highest-leverage line in that table. It removes most of the economic incentive to farm installs, and it aligns the reward with the thing you actually wanted. There's a worked example in the fitness referral playbook.
Ahsan
LinkTrail Engineering
Ahsan is on the LinkTrail engineering team and the engineer behind its SDKs for iOS, Android, React Native, and Flutter. He started the company after the Firebase Dynamic Links shutdown left teams with links that opened the store and forgot where the user was going — and after too many vendor calls that ended without a price. He writes here about deferred deep linking, install attribution after ATT, and the parts of the mobile growth stack the category tends to leave vague.
All posts by Ahsan