Skip to main content

Hi everyone, We have a flutter app that requires user to make a purchase first and then create an account. Users can’t access the app unless they signup and create an account. First time a purchase is made with Rc anonymous id and after signup we call logIn() method with user id. 
We are trying to implement restore purchases as apple doesn’t approve apps without having any restore method. When user clicks on restore purchase revenue cat restores the purchases but transfers the purchase to an anonymous id. We are using the webhooks to save user subscription status on basis of webhooks. But after restoring purchases revenue cat send the webhooks with anonymous id and our backend is unable to connect it with user. 

After clicking on restore purchases logIn() method doesn’t work. In debug mode it says that user has been logged in but on revenue cat it doesn’t change the app user id and webhooks are being sent from anonymous id. 
How to implement the restore purchases in flutter when we have an auth system to check the user subscriptions from backend

Hi @Saad!!

Could you provide a bit more clarity for the flow of events? 

If you’ve called logIn with a user ID, then restore purchases, they shouldn’t be sent to an anonymous ID. Instead, they should get associated with the user ID. 

 

In a typical scenario, you’d have users log into their account, then provide a restore purchases button once they’re logged in. 

If you provide the restore purchases button before they get a chance to log in, and log them in after they’ve restored the purchase, then yes, the anonymous ID will get the purchase. 

Meaning what happens is: 

  • configure the SDK with anonymous ID
  • restore purchases with anonymous ID (purchase goes to anonymous user)
  • log in actual user, they no longer have the purchase. You’d need to *at this point* call restorePurchases again. Not ideal. 

If an account is required for your app, then you can have them log in first, then provide the restore button as an optional thing, useful as a backup. 

So that’s my recommendation: have the restore button available after the user logs in / creates an app. For most cases, they won’t even need to press it - as soon as you call logIn, if that user had already made a purchase, they’ll get access to it. But the restore button is always a good idea as a backup. 

 

Hope this makes sense! Let me know if you have any other questions. 


Can Purchases.Restore() be called after the user logs in (as part of the authentication flow, i.e. after the user is authenticated and the uid is retrieved)?

Michael C.


Reply