Solved

Setting up a Consumable in-app Purchase Architecture

  • 1 September 2021
  • 1 reply
  • 56 views

Badge

I am new to RevenueCat and I am looking for advice on how to architect my consumable in-app purchases with ReveneCat. With the current app I am developing for macOS, I use the AWS Polly service and each usage of Polly costs money (pay as you go). I am using consumable in-app purchases to control my cost structures from users so that I will always make a profit no matter the overall customer usage. One requirement is fiscal security where the user can't spoof/hack the consumable resources on device, so I need to store their current resource count in the cloud. I read the following in the ReveneCat help pages.

Non-Subscription Purchases:

It's important to note that at the moment, logic for keeping track of consumable redemptions must be handled outside of RevenueCat. We recommend your server is set up to receive Webhook events for NON_RENEWING_PURCHASE to appropriately provide consumable content for your users.

For example: RevenueCat can track a consumable coin purchase and include it in the purchaserInfo, but cannot track if you've granted a user the appropriate number of coins for that purchase.

If I understand this correctly, it means I need an external server to process and store the current consumable count for each user. I also need to be able to process refunds (webhooks?) in order to properly reduce the user's current resource count and prevent fraudulent abuse of the in-app purchase. So what are the pitfalls I should look out for when setting this system up?

As a side note, I am leaning towards using AWS Lightsail for about $20 a month (including the database) for my backend server. It's cheap and scalable. Are there alternative suggestions for a server backend?

icon

Best answer by cody 8 September 2021, 22:58

View original

1 reply

Userlevel 3
Badge +7

Hey @Brendan Murphy! 👋

If I understand this correctly, it means I need an external server to process and store the current consumable count for each user. I also need to be able to process refunds (webhooks?) in order to properly reduce the user's current resource count and prevent fraudulent abuse of the in-app purchase. So what are the pitfalls I should look out for when setting this system up?


This is correct- you’ll need to have your own server to be the source of truth for your consumable count that responds to webhook events from RevenueCat. Webhooks are sent for NON_RENEWING_PURCHASE as well as REFUND, so that should be enough in itself to keep track of the consumables (from the financial/purchase side of things).

You’ll also then need to manage the “redemptions” on your end with some kind of custom transaction system, but this is generally out of the scope of RevenueCat.

As a side note, I am leaning towards using AWS Lightsail for about $20 a month (including the database) for my backend server. It's cheap and scalable. Are there alternative suggestions for a server backend?


I’m not sure I can personally speak to this one- there are a ton of options out there, but AWS definitely is a good one for the reasons you have here and would probably be a great choice. You could use something like Heroku or a droplet on DigitalOcean, but it will definitely come down to personal preference.

Reply