Skip to main content
Solved

restorePurchases links multiple users correctly, syncPurchases does not

  • 15 August 2024
  • 3 replies
  • 35 views

Hey folks,

We have a good amount of users who sign up multiple years in a row with different email addresses and then our purchase history for them shows them incorrect offers because they don’t get linked up in the RevenueCat backend. I don’t know this for sure, but I suspect many people are also removing our app in the interim (which may be part of what makes this trickier)

We’re trying to call `syncPurchases` whenever we have a successful login (so they aren’t anonymous IDs). But we still don’t get it right.

If I call `restorePurchases` where we’ve called `syncPurchases`, everything works. Of course, the caveat is that the OS-level login prompt sometimes shows up.

 

Is this a RevenueCat bug? My understanding is that `syncPurchases` should basically be a drop in replacement for `restorePurchases` with no prompts. Using React Native and code push, I’ve been able to verify the only thing I need to make my logic work is to switch `syncPurchases` with `restorePurchases`, but I’m reluctant to do that due to the login prompt and everything.

Let me know if I’ve misunderstood what to expect, or if there’s some extra step I need to take in order to make `syncPurchases` actually work like `restorePurchases` and get called programmatically.

Typically we recommend using restorePurchases for these types of actions (which should be taken by a user and not done programmatically), because there are situations (e.g., user is logged out of the App Store, or their session is expired) in which a login prompt is appropriate.

That said, if you open a support ticket here we can take a look at some of the appUserIds and determine what’s going on in greater detail.

Thanks, Ryan! I will put in a support request.

But just for clarity, is `syncPurchases` expected to work exactly like `restorePurchases`, or is there some set of different behavior to expect? And if they are different, what are those differences? The documentation makes it seem like these are entirely analogous methods.

RevenueCat support got back to me with a very helpful answer. Thanks for the suggestion, Ryan.

I’m going to post this here because I think it clarifies the difference between those two methods, and provides a couple of good options:

 
Your app seems to fall into a very specific situation where syncPurchases actually is not what you need. syncPurchases does just that - it syncs purchases with RevenueCat again, but it respects your login system. So it syncs purchases for the specific logged in user ID. In this case the new user ID doesn't have any purchases, and so nothing is synced for this user. Instead, the purchases are synced with the original user ID that the customer used in the last season.
 
If this is a common flow in your app (and it sounds like it is) then you can build this assumption in. For example, after they create a new account, you can ask if they've used the app in the past and if so, offer to restore purchases. It puts the customer in the driver's seat to determine what they want to do. You can also add a restore purchases button in your app somewhere so that customers can do so at any time. We find it cuts down on customer support quite a lot.
 
Alternatively, you could automatically call restorePurchases instead of syncPurchases but that has some considerable downsides, one of which is that the device may ask the customer to log in to their App Store/Play Store account, and the other is that it's a rather heavy operation in terms of network bandwidth and time, which may not be desirable in an automatic action. I'd recommend against doing this without a little extra care put into it, for example if you can be sure that this is a returning customer with existing purchases but created a new account, then call restorePurchases automatically. This might be doable, we can discuss this option if you want.
 
Please let us know if you have any other questions, we'd be happy to help! 

Terms & ConditionsCookie settings