RevenueCat

Build With RevenueCat

Build a customized mobile subscription business with RevenueCat. We do the heavy lifting of normalizing subscribers from any source and maintain a single source of truth for subscription status, so you can get back to building your app.

RevenueCat is a powerful, secure, reliable, and free to use in-app purchase server with global support. All you need to get started is an API key.

Ask A Question

Questions

1

Are receipts enough to recover all price related data?

I am integrating our backend with RevenueCat, but kind of in observer mode. I am more interested in using RevenueCat as analysis tool, rather than anything else. So far it looks like everything works. I'll just mention that the examples in REST-API are not working out of box due to header names being case sensitive (examples have them lower-case, but API expects them to be in Content-Type style, rather content-type) My question is, what kind of information do I have to store in my database so that nothing is lost if I want to export data to RevenueCat at some point later and see correct revenue / historical price data. My fear is that if I don't store enough data, RevenueCat will be no longer able to understand what exactly has been going on historically. right now I store the following in my database (and update): - transactionId (this is originalTransactionId on Apple, and transactionId on Android) - productId - receipt - platform (iOS/Android) the way I update these records in the table; If transactionId does not exist, I create new record If transactionId already exists, I update existing fields (this could update productId and receipt) Every time I get receipt from server-hook (iOS/play store), I just process the "latest_receipt" or "latest_expired_receipt, verify that receipt and query apple/play store, and update the table with latest information. Is that going to be enough for RevenueCat to understand the data if I decide to re-play these "transactions" against v1/receipts and generate statistics that are 99% up with real world? I've noticed some weird situations happening such as if I cancel a subscription (and get refunded), and then subscribe again, the originalTransactionId stays the same, and it also stays the same if I upgrade/downgrade my plan (but productId changes). I've also noticed that there is "linkedPurchaseToken" on Android, does this require any special attention? Theoretically speaking, correct me if I am wrong, the receipts act as authentication tokens, and if I have managed to get receipt from the user, and store it somewhere, that is going to be enough for RevenueCat to figure out everything that ever has happened to that specific user, including cancellations, refunds, plan upgrades/downgrades (and how the user has been charged for it)

Posted by Chris 3 months ago