Skip to main content

Hello, im using the “Transfer to new app user id” method. I don't want to use a auth system in my app. Im using the Webhook to grant users 10 free credits on INITIAL_PURCHASE and tracking the original_app_user_id and aliases in my backend. There is a problem though, when I reinstall the app on Android, the original_app_user_id changes and the old one is not included in the aliases array. So basically I use the same google account on my device but revenuecat references a different user after reinstall of my app and after cancellation of the subscription. My expected behavior is that the userid is bound to one google account and I don’t want that entitlements get transferred if user logs in with another google account. The user should be able to restore purchase if logged in with the same google account the purchase was made on and it should not be bound to the device.

how to handle this without creating a auth system in my app?

thanks in advance 

Also sometimes the original_app_user_id is the first one after reinstall which I'm tracking in my DB like expected, but sometimes after reinstall it's a new one. There seems to be an inconsistency issue with Google Play Store subscriptions. On iOS everything works as expected. I would appreciate any help… Is this maybe an issue with Sandbox testing or is this expected behavior for production?


I also noticed something odd - the sandbox customer dashboard shows three different customers for the same device (and the same Google account). Can you help me understand why that is? 

react-native (android SDK 8.8.0)


Hi @cemck,

It is expected that each new install of your app could produce a new app user id - this is one of the use cases for restore behavior to handle. The `original_app_user_id` can change if a user reinstalls and restores purchases, so we definitely recommend listening to `TRANSFER` events and checking the `transferred_to` field against the aliases array and moving the purchases over in your database.

Google Play does tend to have more changes to user identity, and more transfers in general. 


Hi @cemck,

It is expected that each new install of your app could produce a new app user id - this is one of the use cases for restore behavior to handle. The `original_app_user_id` can change if a user reinstalls and restores purchases, so we definitely recommend listening to `TRANSFER` events and checking the `transferred_to` field against the aliases array and moving the purchases over in your database.

Google Play does tend to have more changes to user identity, and more transfers in general. 

Hey, thanks for the reply! My issue is though that I don’t receive any TRANSFER events in my webhook when I’m not using the .logIn() method in the SDK and purely relying on anonymous ids.
Any idea on why that is?


Is this for a user with a purchase, or without? If there are no purchases associated with the user yet, then we won’t trigger a transfer (nothing to be transferred).

If there are purchases, and you have the default Restore Purchases behavior, enabled, then we should transfer the purchase to the user app_user_id. If this transfer did not occur for some reason, the user would need to click your app’s Restore Purchase behavior.