We have an app that requires the users to login before making a purchase.We’re observing (in our sandbox testing) that occasionally a users subscription gets transferred from one of our users id’s to an anonymous id. What's quite frustrating is this is happening very infrequently and we haven’t been able to recreate it predictably.Here is an example event (id: 0a5fc80d-ca5a-451a-8a31-cb16b95a3a92){ "event_timestamp_ms": 1643816650712, "store": "APP_STORE", "transferred_from": [ "ce3873cc-10a7-46d0-9463-43364f6b2cb8", "$RCAnonymousID:6a5e992f89a44858b2a8effa6996f257" ], "transferred_to": [ "$RCAnonymousID:a0490b63949a4b6e99a3bf372b3da781" ]} Our touch points with the React Native SDK are rather light:We have an useEffect() that calls Purchases.setup(key) with our keys in our main App.tsx as per the examples. When a user logs into our app we call Purchases.logIn(user.id) using the response to set our initial local subscription state. To keep things up to date we call Purchases.getPurchaserInfo when the user brings the app back into the foreground if they are logged in and have a requestDate that's more than 5 minutes old. We call Purchases.logOut() when the user hits the Logout action in our UI.Sometimes (rarely) when a user logs out and back into our app the above style event will occur.What I can assume (but can’t validate) is somewhere in our implementation we’re causing the SDK to transfer the purchases when the user is logged out. But I'm unclear what part of the SDK would do that? The visible effect this has on us is that the user that does log in (i.e ce3873cc-10a7-46d0-9463-43364f6b2cb8 from example event). They don't have any subscription information as its been transferred to the anonymous user. Oddly when this does happen if they log out and back in again it gets transferred back to them. Would appreciate any guidance here as theres a good chance we’re doing something wrong but since it works 90% of the time its difficult to pin point what may be wrong.

@NizzaSorry for the delayed response, and thanks so much for your patience.I believe what’s happening is:log instart subscriptionlog outsubscription renewal comes inAt step 4, when the renewal comes in, the SDK posts the receipt to our backend, but at this point, you’re an anonymous user. So the backend is transferring the receipt, to make sure that whoever’s currently using the device, even if not logged in, doesn’t get locked out.For this case, the best course of action would be to have a restore button available somewhere in your app once you’re logged in.Note that in practice in production this is fairly rare, since logging out of apps is rare in the first place, and more so when you have an active subscription. But you should still take care of this case, so providing a way for customers to restore purchases once they log back in should suffice.Hope this helps shed some light on the matter! Let me know if you have any more questions!

@Andy I am unsure ifI follow the “renewal going through on a device” part. The subsaren’t linked to a device, are they? Rather, aren’t theytied to an Apple/ Google account and their serverssendwebhooks when subs renew.Otherwise, I couldn’trenew my subscription if I subscribed on my iPad and wanted to use the app on my Pixel.If I understand correctly, basically, what is happening here is that when a renewal is sent to RC from Apple, RC findsthe “last logged-in” customer associated with that Apple account and activates their subscription.If there was another account that was associated with the same Apple account previously, RC performs a transfer?A couple of scenarios I am wondering about:user_1 is subscribed on an iPhone, and then user_2 logs in on aniPad linked tothe same Apple ID? I assume that would also transfer the subscription if the renewal followed and user_1 hadn’t logged back in?user_1 logs in on my iPhone and subscribes with the AppleID, user_1 also logs in on a second iPhone with a different Apple account i.e a husband and wife sharing a single app account, but with individual AppleIDs- I assume as long as the second account doesn’t subscribe, it will remain subscribed?What I don’t follow is how the following wouldn’t be a one-size-fix-allsolution:user_1 logs in to their accountuser_1 subscribesuser_1 logs outuser_2 logs in (the same device, doesn’t have access)user_2 can then decide to press “restore purchases” if they want to transfer the subscription from user_1 to user_2 or not press it if they want to leave the subscription active on user_1 account.step 5 relies on the device they are on being logged into the original Apple account because it would receive the same originalTransactionID (or similar), which RC would be able to use to identify as beinglinked to the current user_1 account (which must be done now for the transfer to work)This would also work for anon users as you have the currently generated ID, and you will be able to get the last one associated with the originalTransactionIDThe only difference here is that it requires the user to explicitly say they wish it to happen rather than everything happening in the background.

Solved

App IDs transferring subscriptions to anonymous users

2 years ago
2 February 2022
27 replies
1461 views

N

Userlevel 1

+2

Nizza
Member
9 replies

We have an app that requires the users to login before making a purchase.

We’re observing (in our sandbox testing) that occasionally a users subscription gets transferred from one of our users id’s to an anonymous id. What's quite frustrating is this is happening very infrequently and we haven’t been able to recreate it predictably.

Here is an example event (id: 0a5fc80d-ca5a-451a-8a31-cb16b95a3a92)

{
  "event_timestamp_ms": 1643816650712,
  "store": "APP_STORE",
  "transferred_from": [
    "ce3873cc-10a7-46d0-9463-43364f6b2cb8",
    "$RCAnonymousID:6a5e992f89a44858b2a8effa6996f257"
  ],
  "transferred_to": [
    "$RCAnonymousID:a0490b63949a4b6e99a3bf372b3da781"
  ]
}

Our touch points with the React Native SDK are rather light:

We have an useEffect() that calls Purchases.setup(key) with our keys in our main App.tsx as per the examples.
When a user logs into our app we call Purchases.logIn(user.id) using the response to set our initial local subscription state.
To keep things up to date we call Purchases.getPurchaserInfo when the user brings the app back into the foreground if they are logged in and have a requestDate that's more than 5 minutes old.
We call Purchases.logOut() when the user hits the Logout action in our UI.

Sometimes (rarely) when a user logs out and back into our app the above style event will occur.

What I can assume (but can’t validate) is somewhere in our implementation we’re causing the SDK to transfer the purchases when the user is logged out. But I'm unclear what part of the SDK would do that?

The visible effect this has on us is that the user that does log in (i.e ce3873cc-10a7-46d0-9463-43364f6b2cb8 from example event). They don't have any subscription information as its been transferred to the anonymous user. Oddly when this does happen if they log out and back in again it gets transferred back to them.

Would appreciate any guidance here as theres a good chance we’re doing something wrong but since it works 90% of the time its difficult to pin point what may be wrong.

icon

Best answer by Andy 15 February 2022, 21:50

View original

Show first post Hide first post

27 replies

1
2

Page 2 / 2

T

+1

tom-mffy
New Member
4 replies
1 year ago
1 February 2023

@Andy I am unsure if I follow the “renewal going through on a device” part. The subs aren’t linked to a device, are they? Rather, aren’t they tied to an Apple/ Google account and their servers send webhooks when subs renew. Otherwise, I couldn’t renew my subscription if I subscribed on my iPad and wanted to use the app on my Pixel.

If I understand correctly, basically, what is happening here is that when a renewal is sent to RC from Apple, RC finds the “last logged-in” customer associated with that Apple account and activates their subscription. If there was another account that was associated with the same Apple account previously, RC performs a transfer?

A couple of scenarios I am wondering about:

user_1 is subscribed on an iPhone, and then user_2 logs in on an iPad linked to the same Apple ID? I assume that would also transfer the subscription if the renewal followed and user_1 hadn’t logged back in?
user_1 logs in on my iPhone and subscribes with the AppleID, user_1 also logs in on a second iPhone with a different Apple account i.e a husband and wife sharing a single app account, but with individual AppleIDs - I assume as long as the second account doesn’t subscribe, it will remain subscribed?

What I don’t follow is how the following wouldn’t be a one-size-fix-all solution:

user_1 logs in to their account
user_1 subscribes
user_1 logs out
user_2 logs in (the same device, doesn’t have access)
user_2 can then decide to press “restore purchases” if they want to transfer the subscription from user_1 to user_2 or not press it if they want to leave the subscription active on user_1 account.

step 5 relies on the device they are on being logged into the original Apple account because it would receive the same originalTransactionID (or similar), which RC would be able to use to identify as being linked to the current user_1 account (which must be done now for the transfer to work)

This would also work for anon users as you have the currently generated ID, and you will be able to get the last one associated with the originalTransactionID

The only difference here is that it requires the user to explicitly say they wish it to happen rather than everything happening in the background.

Userlevel 5

+8

Andy
RevenueCat Staff
236 replies
1 year ago
8 February 2023

I agree with you.

To clarify what I meant with “goes through on the device”, our system gets information about renewals in 3 ways:

Through an Apple server-to-server notification, if enabled. These aren’t complete or entirely guaranteed to be timely, but they can be useful
Through our receipt refreshers, basically smart and optimized polling
Through activity on the device - the StoreKit queue notifies of purchases and renewals. It doesn’t provide any information about whether a transaction was one or the other, sadly. But in order to provide access to the user as soon as a purchase or renewal goes through when they have the device open, this is the most reliable way of getting notified.

It wasn’t possible on our side until recently to effectively distinguish between renewals and new purchases, which made the flow of “only transfer for renewals” not achievable. However we do have the infrastructure in place to make this viable now.

I’ve raised this up with the team and I’m going to try to get it updated, I think it would lead to a lot less confusion for developers.

Thanks for the valid feedback and the patience @tom-mffy!

1
2

Page 2 / 2

Reply

Sign up

‏‏‎ ‎

Log in to the Community

‏‏‎ ‎

Scanning file for viruses.

This file cannot be downloaded