Solved

Customers being charged, but purchase does not show up in RevenueCat

  • 22 July 2021
  • 2 replies
  • 616 views
S
Badge +5

A common issue in my app has been that
 

1: The customer got charged

2: The purchase does not reach RevenueCat

3: The customer reaches out to support.

4: I ask them to restore purchases and everything is synced correctly. 

I did read the article here: 

But it doesn’t contain much details on how to detect the error. I also reached out to support about this issue and got a pretty unhelpful response from support (and did not get any comment on my follow up emails).

“Restoring transactions is our recommendation here. Unfortunately Apple and Google's in-app purchase process makes this a necessity. Beyond that, we don't have any general recommendations.…... Are users are complaining about not getting an entitlement after purchasing? Maybe an action item here is to show UI recommending the user to restore purchases if no entitlements are detected after a purchase. You can get creative here but outside of restoring purchases there's not much else to do..”

Is there a way to detect if the user purchased, but no entitlements were unlocked? Is there any particular error code that might be thrown in this case, so I know when to ask the user to restore? Does anyone have code in place to handle this issue?

icon

Best answer by ryan 22 July 2021, 16:14

View original

2 replies

ryan
Rank
Userlevel 5
Badge +9

Hey Simon 👋

There isn’t one error code or a guaranteed way to detect this scenario, but if you feel like it’s happening frequently, maybe there are some things you can check.

 

First off, for background, this usually happens when for whatever reason the device receipt never makes it to RevenueCat. Examples of this could be:

  • NETWORK_ERROR - if the network drops out, it could have been after the customer was charged but before the receipt made it to RevenueCat. Another 
  • STORE_PROBLEM_ERROR - if Apple or Google return an error, we don’t know if it was before or after the customer was charged.

In both of these cases, and any other errors where the purchase resolves in an unknown state, the RevenueCat SDK will automatically retry the request the next time it’s configured. So you don’t have to handle these cases yourself, however your customers may reach out to support before the retry occurs

 

Another error that you could handle is the RECEIPT_ALREADY_IN_USE error. You may be receiving this if a customer tries to make a purchase, but the receipt already exists in RevenueCat and is associated with another customer. In this case you could show a message to the customer instructing them to restore or login with their previous account. Alternatively, you can enable the “Transfer purchases” restore behavior from the dashboard which would transfer the transactions to the customer instead of returning an error.

 

Besides error messages, if you feel like this is a more frequent issue it could indicate a problem with how you’re identifying customers in your app. Maybe customers are purchasing as one App User ID, and there’s a race condition or other behavior that’s triggering the App User ID to later change, such as calling .reset() or .logout() programmatically after a purchase.

 

I know this is a long-winded answer, and sorry you received and unhelpful response earlier, but hopefully this can help provide some more clarity and point you in the right direction. There isn’t a simple solution we can provide on our side to the problem since it can be very dependent on your specific app besides restoring purchases since that should resolve all of the above. 

S
Badge +5

Thanks!

Yeah, the extra detail definitely helps. I actually have had some weird issues related to identifying customers. RevenueCat is for some reasons overestimating the installs/active users by quite a lot, so I think this might be a another symptom of identification issues.

Working on resolving those now. I also did see the new login/logout methods and will enable transfer purchases soon. 


It is good to know that you are doing retries in this case. I guess the best option would just be to simply see if there are any identification issues, and improve error handling so the user can restore when errors happen on purchase ;)

Reply


Terms & ConditionsCookie settings