Skip to main content
Solved

Block Restores question on iOS

A
Forum|alt.badge.img+1

Hello,

 

In my app I have Block Restores enabled and the following situation:

2 auto renewable subscription options set up - monthly and annual

  1. User A subscribes to an annual subscription 
  2. User B logs in on the same device and tries to subscribe to annual - gets the `receiptAlreadyInUseError` and I show an error
  3. But if User B tries to subscribe to a monthly subscription - the subscription goes through, switching User A’s subscription to a monthly subscription instead of annual (user B still doesn’t have a subscription, as expected)

How can I tell that the currently logged in Apple ID is already subscribed with a different user and show an error when another user tries to subscribe and inadvertently changes the original user’s subscription?

`CustomerInfo` doesn’t seem to have that info, User B has no active subscriptions.

Best answer by sundeep

Hi @Andrey,

Unfortunately, there isn’t a good way to detect that scenario - with Block Restore, we typically caution that you add some way for the user to contact you if their entitlements are not working as they expected (because restore functionality is limited with this option), and then you would resolve this on your support side to recover the original account that had the subscription.

If you foresee many users in your app making multiple IDs and running into this case, I recommend our Transfer on Restore behavior instead, as that means the receipt will always transfer to the last App User ID that made or restored purchases: https://docs.revenuecat.com/docs/restoring-purchases#transfer-purchases 

View original
Did this post help you find an answer to your question?
This post has been closed for comments

3 replies

sundeep
RevenueCat Staff
Forum|alt.badge.img+8
  • sundeep
  • RevenueCat Staff
  • 138 replies
  • Answer
  • March 22, 2022

Hi @Andrey,

Unfortunately, there isn’t a good way to detect that scenario - with Block Restore, we typically caution that you add some way for the user to contact you if their entitlements are not working as they expected (because restore functionality is limited with this option), and then you would resolve this on your support side to recover the original account that had the subscription.

If you foresee many users in your app making multiple IDs and running into this case, I recommend our Transfer on Restore behavior instead, as that means the receipt will always transfer to the last App User ID that made or restored purchases: https://docs.revenuecat.com/docs/restoring-purchases#transfer-purchases 

ryan
RevenueCat Staff
Forum|alt.badge.img+9
  • ryan
  • RevenueCat Staff
  • 391 replies
  • March 28, 2022

@Andrey also remember that in that scenario you outlined, “User B” would need to confirm the subscription with the same TouchID/FaceID that “User A” used, so you know they are actually the same person just using two different accounts in your app. 

J
Forum|alt.badge.img+2

I am facing a similar situation, but I’m seeing even more worrying behavior.

  1. App store userA logs into our app as user1
  2. user1 purhcases a monthly subscription
  3. user1 eventually cancels monthly subscription and it expires
  4. user2 logs in on the same device (i.e. still app store userA)
  5. user2 purchases monthly subscription, gets the ‘receiptAlreadyInUse’ error, HOWEVER, the purchase still went through successfully and user1’s purchase was restored.

This feels like a bug that the purchase made it through even though the SDK returned an error.

Also, the link to the documentation on restores is currently pointed to here which gives a 404.

@sundeep sorry to tag you, but I wasn’t sure if anyone would look at this since the thread was marked as “solved”

I’d happy to move this to a new thread if you like.

K
1 person likes this
  • K
    Keith McSpurren

Most helpful members this week

Terms & ConditionsCookie settings

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