Skip to main content

Transfer webhook event handling


Forum|alt.badge.img+5
  • New Member
  • 4 replies

Dear RevenueCat Support,

I'm encountering an issue where RevenueCat is automatically transferring entitlements between users, and I'd like to understand how to disable this behaviour.

Preventing Entitlement Transfers In my use case, each user should retain their own subscription entitlements without automatic transfers happening when a subscription is detected on another App User ID (possibly due to device sharing or restored purchases). Is there a way to completely block entitlement transfers? I looked through the dashboard and documentation but couldn’t find a setting to control this. Is this something configurable per app or only through SDK behavior?

This post has been closed for comments

4 replies

hussain
RevenueCat Staff
Forum|alt.badge.img+2
  • RevenueCat Staff
  • 18 replies
  • April 9, 2025

Hi there,

Thanks for reaching out about this!

The behavior you're experiencing is due to the default "Transfer to new App User ID" setting in RevenueCat. To prevent automatic entitlement transfers between different users, you can enable the "Keep with original App User ID" transfer logic.

Please note that enabling this option requires that each user must sign in with their original App User ID, and that you are using Custom User ID instead of the Anonymous Customer ID provided by RevenueCat, and it is only recommended for apps that mandate user accounts before purchases.

You can find more details about these settings in our documentation here: Restore Behavior Documentation.

Let me know if you have any further questions!

Best,

Hussain


Forum|alt.badge.img+5
  • Author
  • New Member
  • 4 replies
  • April 11, 2025

Hi ​@hussain ,

My application is account based means multiple user can do login and logout. I already tried setting of "Keep with original App User ID" but it was not working for me. If user1 is taking subscription and after subscription gets expired user2 do login and take subscription then it was showing event for user1 as that was the original user of that device purchases. This behaviour is not supposed to happen and hence I can’t keep "Keep with original App User ID".

I have already been developed app by using custom app userId and login with custom app userId only but still at somewhere it is capturing Anonymous Id for some users. Due to this users are not getting access of content so its highly crucial for me.

 


hussain
RevenueCat Staff
Forum|alt.badge.img+2
  • RevenueCat Staff
  • 18 replies
  • April 14, 2025

Hi Syit,

Thanks for following up and sharing those additional details.

In your situation, you may want to explore the “Transfer if there are no active subscriptions” restore behavior. This setting ensures that entitlements will only transfer if the original App User ID has no active subscriptions, which can help prevent entitlements from being assigned to the wrong user while still allowing legitimate restorations in some cases.

You can read more about it here:
👉 Transfer if there are no active subscriptions

Best,
Hussain


Forum|alt.badge.img+5
  • Author
  • New Member
  • 4 replies
  • April 23, 2025

Hi Hussain,

I kept all listed option in transfer behaviour settings but it was not working well in some cases. If I keep “Transfer if there are no active subscriptions” then also it was causing the issue. 

 

My app has login/logout so there is possibility of different users can login with their credentials. If I go with option you suggested then if user1 purchased the subscription and logged out then another user2 who has not active subscription then original purchases get transferred to new user2 as setting is kept as Transfer if there are no active subscriptions. This behaviour should not allow in the application as it will unnecessary give entitlements to unwanted users.

 

Even there is no way to restrict transfer completely from RevenueCat so how I can handle this?


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings