# Issue with app detecting repeated promo use **URL:** \ **Category:** Discussion & Solutions\ **Tags:** solved\ **Created:** [May 30, 2026, 9:40am UTC](https://onehack.st/t/issue-with-app-detecting-repeated-promo-use/322483 "2026-05-30T09:40:24Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Fahad\_Ali](https://onehack.st/user_avatar/onehack.st/fahad_ali/32/84519_2.png) [@Fahad\_Ali](https://onehack.st/u/Fahad_Ali)\ **Post date:** [May 30, 2026, 9:40am UTC](https://onehack.st/t/issue-with-app-detecting-repeated-promo-use/322483/1 "2026-05-30T09:40:24Z")
There’s a food delivery app offering free delivery for the first four orders. After using that offer, I tried signing up with a new number and email, but the app still detected it. Is there any way to resolve this? ---
**Author:** ![Prometheus](https://onehack.st/user_avatar/onehack.st/prometheus/32/34950_2.png) [@Prometheus](https://onehack.st/u/Prometheus)\ **Post date:** [June 7, 2026, 11:40am UTC](https://onehack.st/t/issue-with-app-detecting-repeated-promo-use/322483/2 "2026-06-07T11:40:55Z")
Your “new number + new email” didn’t get detected — it got **ignored**. The app stopped giving a fuck about phone/email around 2020. It reads **4 other signals** you left wide open: device, address, payment, GPS pattern. Two-of-six, neither heavy. Match four → app shrugs and blocks. * * * > **🔍 The 6 signals — what they actually check (table)** > > | Signal | Weight | You changed? | > | --- | --- | --- | > | Phone number | Light | ✅ | > | Email | Light | ✅ | > | Device fingerprint (AAID + ~50 hardware/software signatures) | Heavy | ❌ | > | Delivery address (normalized to building, sometimes floor) | Heavy | ❌ | > | Payment instrument (UPI ID, card BIN, saved bank acc) | Heavy | ❌ | > | GPS cluster (where you sleep / work / order — day after day) | Heaviest | ❌ | > > Doorman analogy: he’s not reading the ID. He recognizes your face, your gait, which flat you walk up to. Slap a new name on your ID — he doesn’t even glance. > **📜 Swiggy's published rule — 2 accounts / 90-day cooldown** > > Swiggy support has confirmed it direct: **2 accounts per device, 90-day cooldown.** After 90 days the lock resets. > > 🔗 [https://www.desidime.com/discussions/swiggy-too-many-login-attempts-detected-on-this-device-error](https://www.desidime.com/discussions/swiggy-too-many-login-attempts-detected-on-this-device-error) > _(scroll to user `slickdeal`’s comment — he posted the support reply verbatim)_ > > If you just want your existing account working again — wait it out. Not a secret, just not advertised. Most people burn weeks trying workarounds when the timer was always going to do the work. > **💀 Shit that doesn't work (save yourself the time)** > > - **Factory reset + reinstall** → AAID survives via Android backup + Google account re-sync. Reset → sign back in → ID re-links. You “reset” a mask, not a face. > - **Parallel Space / App Cloner / Island** → Incognia & [Fingerprint.com](http://Fingerprint.com) list these **by name** as tamper signals. Flagged before you finish typing your new number. > - **VPN / proxy** → Location is GPS, not IP. VPN moves your IP. Doesn’t move your phone. [Fingerprint.com](http://Fingerprint.com)’s new “Proximity Detection” (launched Dec 2025) explicitly defeats VPN by reading raw GPS from permissions you already granted. > - **Mod APKs / patched Swiggy** → Play Integrity API flags modified apps on launch. Beating it needs root + Magisk + Zygisk + Shamiko + payment change + new physical address. Cost-benefit destroyed. > - **Emulators (LDPlayer, BlueStacks)** → Tamper SDKs sniff emulator signatures from process tree. Flagged session one. > > The fraud SDKs are **sold to the apps**. Their marketing decks brag about catching every common evasion tool by name. Read their case studies and you’re literally reading the rulebook. > **🌐 The web/Chrome trick — works for ONE specific thing only** > > I order from `swiggy.com` in Chrome when juggling between accounts I already own. Browser fingerprint is way thinner than the app — no AAID, no install ID, no SafetyNet check. The “too many login attempts” lockout doesn’t hit the same way. > > Got bit once trying to claim a fresh first-order coupon via the web → same address, same UPI, blocked in 2 seconds. > > **The browser path is for managing existing accounts, not resurrecting promos.** Don’t expect more from it. > **🧮 The math — why you should just refer instead** > > **The grind:** 4 free deliveries = ~₹30–50 × 4 = **₹120–200 total** > > **The legit play:** One Swiggy referral = **₹90 off + free delivery (new user) + ₹50 cashback (referrer)** > > Get a roommate, family member, anyone in your circle to refer YOU on **their device + their address + their UPI**. Both sides win more than the entire 4-order grind. Zero detection problem. The referral is the loophole the app _wants_ you to use. > > **Active codes — pick any, both sides get the reward:** > > | Code | Source | > | --- | --- | > | `CA7AE6I` | [https://blog.monetizedeal.com/swiggy-referral-code/](https://blog.monetizedeal.com/swiggy-referral-code/) | > | `24F35EE` | [https://referralwale.com/store/swiggy](https://referralwale.com/store/swiggy) | > | `5E24ED3` | [https://referralhype.com/swiggy-referral-code/](https://referralhype.com/swiggy-referral-code/) | > > Cap: ₹2,500 per existing user (50 successful referrals). > **🏗 Deep architecture — vendors, AAID truth, graph model** > > **The vendor stack** (same small group, every delivery app worldwide): > > | Vendor | Specialty | Customers | > | --- | --- | --- | > | Incognia | Location-first | Grubhub, Delivery Hero, iFood | > | [Fingerprint.com](http://Fingerprint.com) | Device-first + proximity | Most US-based delivery | > | Sift | Behavioral + payment | Wide adoption | > | Forter | Payment / chargeback | E-comm + delivery | > | Riskified | Payment / chargeback | E-comm + delivery | > > Their marketing decks = the rulebook your app runs on. Free intel. > > **The AAID truth** — Adobe’s own mobile SDK docs say it cold: > > > _“the advertising ID remains consistent across app upgrades, is included in the standard app backup and restore process”_ > > 🔗 [https://experienceleaguecommunities.adobe.com/adobe-experience-platform-18/aep-mobile-sdk-110646](https://experienceleaguecommunities.adobe.com/adobe-experience-platform-18/aep-mobile-sdk-110646) > > Android’s “reset advertising ID” button is real, but the ID lives in your Google backup. Reset → sign back into same Google → ID re-links to your install history. Truly breaking the chain needs: factory wipe + brand-new Google account + new SIM + new physical location + new payment. At that point you’re not a “new Swiggy user,” you’re a new human being. > > **The graph model** — it’s not one signal voting on you. It’s a relationship graph. Each new account = a node. Each signal = an edge. New phone + new email = two leaves added. Same device + address + UPI + GPS = four heavy edges back to the existing node. The algorithm clusters them and your “new” account inherits the parent’s risk score. > > **Worth reading** — Incognia’s published case study on catching factory-reset evasion: > > 🔗 [https://www.incognia.com/resources/download-food-delivery-case-study-multi-accounting-scam](https://www.incognia.com/resources/download-food-delivery-case-study-multi-accounting-scam) > > They literally built place-level location clustering specifically to defeat factory resets. So even if your device looks clean, ordering to the same flat re-links you. * * * **TL;DR** — You didn’t get detected. You got ignored on the wrong 2 signals. **Wait 90 days OR use a referral code** — referrals pay more than the grind anyway. Everything else is a tax on your time. ☕ ---
**Author:** ![Fahad\_Ali](https://onehack.st/user_avatar/onehack.st/fahad_ali/32/84519_2.png) [@Fahad\_Ali](https://onehack.st/u/Fahad_Ali)\ **Post date:** [June 9, 2026, 11:37am UTC](https://onehack.st/t/issue-with-app-detecting-repeated-promo-use/322483/3 "2026-06-09T11:37:31Z")
Thank you bro for the detailed reply. 😍