Solved

There is only one revenueCat user for app user's subscribing on the same iPhone

  • 19 July 2022
  • 5 replies
  • 340 views

Badge +5

Hi! I’m noticing weird behavior in my subscriptions (in sandbox, my paywall isn’t in production yet), where if a user subscribes on an iPhone, and then disconnects, then i create a new account for my app when I get to the paywall, if i try to make a subscription i get a native alert saying “you already have an active subscription”, and then the paywall closes and I can access the paying features: that is not a behavior I want, because I don’t want a user to be able to create several accounts only paying once.

 

Furthermore, in revenueCat, the sandbox transactions done with the old account then have the userId of the new user (the linked userId changes!)

How can I fix this?

 

For information, I use

Purchases.setup(MY_KEY, USER_ID)

 and right after

Purchases.logIn(USER_ID) 

in my app’s main navigator.

 

Best,

Jane

 

icon

Best answer by tina 20 July 2022, 02:32

View original

5 replies

Userlevel 5
Badge +10

Hey @Jane 

The reason why you’re seeing “you already have an active subscription” even though you created a new account on the app is due to the underlying receipt. In sandbox, when you purchase a product, this will create a receipt associated with the sandbox user. This differs slightly compared to production, which a receipt is generated when a customer installs the app.

To test on a completely fresh customer, you should also create a new sandbox account and be sure to log into this new account on the device. 

I don’t want a user to be able to create several accounts only paying once.

That is actually one of the reasons why we released new restore options and you can review the options in our Restoring Purchases doc. We recommend using ‘Transfer’ (this is the default). With the transfer behavior on, the following will happen:

 

1. User 1 makes a purchase and unlocks an entitlement

2. User 2 restores using the same Apple ID (or attempts to make a purchase), unlocks the entitlement and claims the receipt for that Apple ID

3. User 1 has their entitlement removed, as the receipt is no longer associated with them

 

With this behavior, there is only 1 subscription and 1 account having access at a time. 

 

Furthermore, in revenueCat, the sandbox transactions done with the old account then have the userId of the new user (the linked userId changes!)

Can you elaborate on this a bit more? Are you seeing the old account app user ID being aliased with the new app user ID? 

 

Badge +5

Hello Tina. Thank you for your answers, it’s very clear.

Concerning the latter, if I find a moment to test it again and give you screenshots I will. I’m not sure whether the old user was aliased but I think they were :)

In red though is what I could see in the recent transaction dashboard, for transactions made with different “users” on the same phone.

 

 

Userlevel 5
Badge +10

Hey @Jane 

When you click into those individual app user IDs, you should notice TRANSFER events. Since the underlying receipt should be bounced around here, a TRANSFER event will occur when attempting to purchase on different “users”, but logged into the same underlying sandbox account in your iPhone settings. 

Badge +3

Hi @tina & @Jane ,

Same question but looking to go a little further.  For details:

  • 2 different user accounts on my app
  • both have unique sandbox ids with apple
  • both have unique revCatIds that I have set and saved in

I took the next step to Block transfers as per the revCat docs.  So my scenario now is:

  • User A buys a subscription for my app
  • User A then logs off from my app on the iPhone...i have Purchases.logOut() run
    • I log and see the new anonymous revCatId post .logOut()...so app is clear of User A
  • User B logs into my app on the SAME phone
    • I log and see User B’s unique revCatId...so that has taken over from the anonymous revCatId now
  • User B goes to the purchase page i created and I ask the revCat server if User B has purchased a subscription….NO: they see a Buy button; YES: they see that they are already a buyer
  • User B sees the Buy button as they have NOT purchased my app yet...so they click it
    • they see the behaviour described above “You already have this purchased...”
    • I used the RevCat Project Settings to BLOCK a transfer (as that is not what i want here...i don’t want them to free ride on User A purchase)

All of the above works as expected and in line with the RevCat docs.  And, the behaviour when User A (a subscriber) goes to any other iphone and logs into my app...all good...user gets their premium subscription no issue.

Sorry for the detail...but my question(s) are:

  1. Is this ‘sandbox’ behaviour different than ‘real world’ and how specifically so (i read your note above but didn’t grasp why it made a difference)
  2. Ultimately, if User B was logged in, and revCat info was good (they were NOT a subscriber) i would want User B to be able to see the Buy button and complete the purchase on any ios device with their own appleID regardless of if someone had previously bought the app on the same device.  Is this possible or am I looking to do something no other apps can do?

 

Badge +3

follow up...i did see something related from @ryan saying ios won’t allow for multiple subscriptions on the SAME device.  So i read that as:

  • User A buys a subscription, logs off
  • User B goes on same device...is not a subscriber...there is NO way for this User to successfully become a subscriber on THAT device (as it will always say ‘already purchased’)

If that is true...ok.  Then two quick q:

  • is there a way to ‘sniff’ that the device already has a subscription versus showing my user a Buy button (because i do not THEY are not subscribed as per revCat feed)?
  • and i feel super stupid here...but where can i access the revCat error logs?  i have ‘Purchases.setDebugLogsEnabled(true);’ set in the right places but no idea where the output of the logs should be found (i just use VS Code and a sep terminal window(s) during development)

Reply