Skip to main content

I have a question.

I'm thinking of leaving the in-app purchase subscriptions for my iOS and Android apps to Revenuecat, storing the data received from Revenuecat's Webhooks on my own server, and using that data to control the provision and suspension of paid features in my app using my own app API. In that case, I have two questions.

1. Webhooks are asynchronous, so what should I do if I need to take delays or non-delivery into account? I'd like to know if there is a Revenuecat function that can take that into account.

2. Is this design correct in the first place? The purpose of introducing Revenuecat is to reduce the cost of implementing in-app purchase subscriptions in-house in accordance with the specifications of Apple and Google's platforms.

Yes, you can totally do that, a lot of our users do it that way. For renewals it should not be a problem, since renewals happen before expiration, so your server will be notified beforehand. Initial purchases is when it can become problematic. I would suggest, for a smoother UX, that you app calls your server when a purchase is initiated, and your server verify RevenueCat to check if that user should get access to the entitlement. That way, you can unlock the entitlement right away, potentially before the webhook from RevenueCat comes in (it would, however, add a little bit of latency to the unlocking).

Thank you for your reply.

I understand that the difference between checking subscription status in SDK and real-timeness is the feature of Webhooks.

Would this be necessary for games, video streaming, or other apps?

We are considering providing the following content for the paid plan.

◆Paid plan content

1. Provision of paid features for paid plan users

2. Campaigns for paid plan users

Providing and suspending paid plan content can be done by obtaining subscription status in SDK.

Am I correct in understanding that Webhooks are not necessarily required?

Reply


Terms & ConditionsCookie settings