logIn() not aliasing anonymous ID when account already has a prior alias — is this expected?

Question

Hi RevenueCat community,I'm working on a React Native app and running into a persistent issue with anonymous-to-identified user merging. Would love some help figuring out if this is expected behavior or something I'm doing wrong.Background & Initial SetupMy app originally required registration before any in-app purchase could be made. After an App Store rejection (purchases shouldn't require registration), I updated the flow to allow anonymous purchases first, with registration happening later.Restore Behavior: Transfer to new App User IDThe Flow I Want1. User launches app → anonymous purchase made (no account yet)2. User registers/signs in → anonymous ID merges with their account ✅ (this works fine)3. Subscription expires → user signs out4. User relaunches app → makes a new anonymous purchase5. User signs back into their existing account → new purchase should merge/transfer to their accountWhat's Actually HappeningStep 5 fails. After signing back in, the subscription shows as inactive and the user is prompted to upgrade again. The new anonymous purchase made in step 4 is not being linked to their existing account.I understand this is likely because the existing account already has a previous anonymous ID aliased to it (from step 2), so RevenueCat refuses to merge a second anonymous ID — which matches the documented Case 3 behavior.What I've Already TriedAfter reading the docs, I identified that calling `Purchases.logOut()` on user sign-out was the problem — it creates a new anonymous ID each time, which then can't be merged. I removed the `Purchases.logOut()` call entirely (only logging out of my own auth, not RevenueCat), as recommended in the docs.However, the issue still persists even after:- Deleting the account in my app- Uninstalling and reinstalling the app on Simulator- Making a fresh anonymous purchase- Signing back into the same accountThe merge still doesn't happen and the subscription is not recognized.Questions1. Does deleting a customer record in the RevenueCat dashboard fully remove all aliases, so that the next `logIn()` with that user ID starts completely fresh?2. Is there any server-side state that persists even after app reinstall + account deletion on the client side that would continue to block the merge?3. With "Transfer to new App User ID" as the restore behavior, should a new anonymous purchase transfer to the existing account on `logIn()`, even if that account already has a prior anonymous alias?4. Is this flow (anonymous purchase → sign in → merge, repeatedly across sessions) even supported, or is the merge intentionally a one-time thing per identified user?Thanks in advance!

guilherme · Answer

Hey ​@harshaxel-thanks for the detailed writeupand for digging into the docs already.The key thing is that logIn() resolves identity, it doesn't pull a purchase across. When you sign in, we look up that account and return what it already owns, butdon't push the device's receipt up at that stage. So a purchase made under a different (anonymous) ID won't appear just from logging in.That's why your "Case 3" read lands on the right symptom, when the current user is anonymous and the account you log into already has an anonymous alias, logIn() does this:Current User ID is logged out, Provided User ID is logged in. No merge or purchase transfer occurs.more context on the “logIn()method alias behavior”table hereGetting a purchase onto an account happens on:restorea new purchaseor sync *governed by your restore behavior, not on login).With "Transfer to new App User ID", a restore after sign-in will land that subscription on the signed-in account (restore behavior docs).Note too that a restore on the SDK is meant to be user-initiated:The restorePurchases method should not be triggered programmatically, since it may cause OS level sign-in prompts to appear, and should only be called from some user interaction (e.g. tapping a "Restore" button.)If you are trying to restore a purchase programmatically, use syncPurchases instead.more context hereSo either surface a "Restore Purchases" button in your Settingspageor, if you want to do this in the background, call syncPurchases() right after the first login when the user has no active entitlement (just not on every app launch). More context here on that here:https://www.revenuecat.com/docs/getting-started/restoring-purchases#syncing-purchases-without-user-interactionAs to go over your questions:deleting the dashboard customer isn't needed and won't fix this. The purchase isn't blocked, it's just sitting on the anonymous ID.reinstalling only clears the device (new anonymous ID). The earlier purchase still lives on its anonymous ID on our side, so there's no lingering "block".no, a new anonymous purchase won't transfer onlogIn()even with "Transfer to new App User ID", login never moves a purchase. That only happens on restore, purchase, or sync.the login-time aliasing is effectively one-time per account, but the flow itself is fully supported. You bring the purchase across with a restore each time rather than expecting login to do it.Also worth noting, logOut() is optional, it just spins up a new anonymous ID. You don't need it to switch accounts and we recommend not using it unless needed on your flow (and given the behavior of that method)I hope this helps, but let me know! Feel free to share a customer ID if you’d like me to have a look at a specific case too, happy to dig into it.

Sign up

‏‏‎ ‎

Log in to the Community

‏‏‎ ‎

Scanning file for viruses.

This file cannot be downloaded