Skip to main content
Solved

getPurchaserInfo() return actual data only after purchaseProduct()

  • February 21, 2022
  • 4 replies
  • 125 views

Forum|alt.badge.img+1

Hello! I’m really destroyed and don’t understand how to solve my problems.

I have one apple account and can create multiple user-accounts in my app. First case:

  • User A login (with logIn())
  • Buy purchase
  • User A logout (with logOut())
  • User B login (with logIn() another appUserId)

Now User B have subscription from User A. But i want the User B to not have a subscription in this case. What can i do?


And more one, in this case after login method getPurchaserInfo() return not active subscription (I’ve been awaiting more than 5 minutes (time for reset cache but got not active). After this i show payment card and by tap (call method purchaseProduct()) user B see system alert with “have already subscription”. And after this method getPurchaserInfo() for User B return active status of subscription. 

What can i do in this case?


Thanks for support!

Best answer by joshdholtz

Hey @Paulik!

## Question 1

The reason that “User B” is getting the subscription is because it was still purchased with the same Android/iOS users account. So “User A” and “User B” are essentially the same user because both looking at the same recipe that Android/IOS has.

If you logged in “User A” and “User B” with different sandbox accounts or on different devices, you would see the behavior that you are expecting.

## Question 2

I’m not sure if your second question still applies since the users should be tested with different sandbox accounts or devices. But calling either `syncPurchases` or `restoreTransactions` is something to look into  linking purchases on the device to the logged in user.

 

Hopefully this helps! But let me know if not and I can try to clarifier better 😊 

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

4 replies

Forum|alt.badge.img+1
  • Author
  • New Member
  • 2 replies
  • February 22, 2022

@joshdholtz @ryan I really appreciate your time but help me please to find a solution :) It should be said that i use flutter sdk


joshdholtz
RevenueCat Staff
Forum|alt.badge.img+5
  • RevenueCat Staff
  • 93 replies
  • Answer
  • February 22, 2022

Hey @Paulik!

## Question 1

The reason that “User B” is getting the subscription is because it was still purchased with the same Android/iOS users account. So “User A” and “User B” are essentially the same user because both looking at the same recipe that Android/IOS has.

If you logged in “User A” and “User B” with different sandbox accounts or on different devices, you would see the behavior that you are expecting.

## Question 2

I’m not sure if your second question still applies since the users should be tested with different sandbox accounts or devices. But calling either `syncPurchases` or `restoreTransactions` is something to look into  linking purchases on the device to the logged in user.

 

Hopefully this helps! But let me know if not and I can try to clarifier better 😊 


Forum|alt.badge.img+1
  • Author
  • New Member
  • 2 replies
  • February 22, 2022

Thank you very much @joshdholtz!
So i can’t buy the same product for different user-accounts from the same apple account?   
Am i right there are no way to achieve this? Or maybe it’s possible in production because you said about sandbox? Yeah, i try not to lose hope :)


joshdholtz
RevenueCat Staff
Forum|alt.badge.img+5
  • RevenueCat Staff
  • 93 replies
  • February 23, 2022

Hey @Paulik

That is correct. You cannot purchase the same subscription or non-consumable item from the same Apple account. That is how Apple designed the in-app payment system. All in-app payments are tied to the Apple ID that is logged into the App Store on the phone. 

You can have a user subscribe to multiple different subscriptions but only one user per subscription.

Thanks!


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