From what i’ve seen (and I may be wrong), while we have only used subscriptions, the purchase info relates directly to the provider account the user is logged in with. For example, while testing, and after publishing my app, whenever i log into the app with any user in my system, the payment always refers back to my Google account (Samsung Device), which picks up that it is my developer account too, and only shows me test cards.

On my iPhone, i haven’t tested logging in as a different user but I think there would be an issue transferring the payment to another user, or at least there should be. I don’t get an option to use a different iCloud account (or ate least i’m too scared to try )

I apologise, it doesnt really answer your question directly, but may prompt for better clarification.

Michael C.

Thank you @OzNick - yea just trying to better understand how this works. I also never tried multiple accounts on same iOS device. I am definitely ok to tie a subscription to a specific user app id but there are situations when that might not be the case and I want to at least know if there is a way to manually transfer. I think I was able to see a transfer option one clicking on user history in the rc dashboard.. maybe that is what I need not sure.

Hi @vic-a563d7 and @OzNick,

Hopefully I can clarify here - with any transfer behavior that is chosen, purchases can only be tied to one account at a time, not shared between accounts. This is because the receipt will always tie back to the underlying store account. So in the case of a user creating a new account, the SDK will still recognize that this is the same store account that made the purchases previously, and the transfer would happen either automatically or via the user restoring - purchases would be transferred away from the previous user and to the new user. If they tried to log in as the previous user, they could no longer access those purchases, unless they restored again - but this would transfer them away from the new user. They couldn’t access from both at the same time - does that make sense?

The restore behavior Keep with original App User ID  will not allow this transfer at all - if the user created a new account and attempted to restore, they would get an error. We only recommend this behavior if you require users to log in to access anything in your app, which it sounds like is the case here. It’s worth noting though that this could increase the load on your support team, as users will most likely reach out for assistance when they realize they can’t access their entitlements if they attempt to log in under a new app user id - which can happen if someone creates a new account, but could also happen if someone deletes and reinstalls the app or changes devices. 

Apologies for the long answer, but the last thing is - there is a way to manually transfer entitlements if need be, and can be done from the customer page, shown here in our docs: https://www.revenuecat.com/docs/active-entitlements#transferring-entitlements

Let me know if you have any questions on any of this!

I think I understand the fast part: the same OS (Play Store) user can log into the custom app with two different custom auth users and transfer purchases from one to the other as many times as they want as long as it’s always tied to one app user id. That makes sense since the SDK is looking at the Play Store account to see what subscriptions they have. But I do not want that - I rather have the Play Store user on their device use one single application login not multiple. I would imagine that is what most developers would want. Would be weird to let someone spend money once and reuse it across multiple application accounts.

That being said, it does sounds like I am looking for Keep with original App User ID.. But now, if the user deleted the application account or forgets how to get back while still paying for a subscription, what options do I have as the app developer to support them? Say they make a new account and log in and  of course there are no subscriptions there and restore won’t work. They have to prove to the app developer that they are the previous account and apply their purchases to this new app account?

Begs the question, when  Keep with original App User ID is enabled, what feedback will the restorePurchases() have in this case? Can it differentiate between failed restore due to no purchases vs failed restore due to app user ids mismatch? This way the application can tell them “you do have a purchase but tied to a different account pls contact support” vs “you do not have any active purchases to restore”.