RevenueCat is a scalable backend for in-app subscriptions and purchases. With RevenueCat, you can build a mobile business without having to set up or maintain any purchase infrastructure.
Right now, to do in-app subscriptions correctly you need servers, databases, APIs, and frontend code that all needs to be kept up-to-date with the changing payment structure of Apple, Google, plus any other payment processors you’re using, such as Stripe.
RevenueCat takes care of all this. We provide the tools you need to quickly set up any in-app subscription model from a simple to-do list application to a complex cross-platform business like Netflix, Spotify or Tinder.
In this blog post, we’ll take a look at the different ways RevenueCat can fit into your app. There are a few common patterns we’ve seen across apps using RevenueCat that we’ll discuss.
Many developers choose to only write client-code, and don’t need anything other than RevenueCat to fetch products, make purchases, and keep a users subscription status up-to-date across devices and platforms.
This is an ideal approach if:
The beauty of this setup is you only need to worry about the client code in your app and RevenueCat handles the rest. After testing and running through our launch checklist, you can have your app shipped with subscriptions in a matter of hours.
In some cases, even with RevenueCat powering your purchases, you may need to respond to subscription related events with custom logic that can’t be done with client-side code alone. A few examples may be:
With this architecture, you’ll still use our Purchases SDK to make purchases and handle everything on the client, but you can have your server sit alongside the RevenueCat backend to keep data synced with a users subscription status. In this configuration, even though you’re still running a server, RevenueCat is handling all of the heavy lifting of keeping a users subscription status up-to-date.
The most common setup is to respond to subscription events via webhooks. This lets you make any necessary updates only when we detect some change to a user. (Google Cloud Functions or AWS Lambda are both scalable, affordable options to “catch” webhooks if you don’t want to host a server)
Webhooks are fired for the following event types:
||A new subscription has been purchased.|
||A customer has made a purchase that will not auto-renew.|
||An existing purchase has been automatically renewed.|
||A subscriber has changed the product of their subscription.|
||A subscription has been cancelled.|
||There has been a problem trying to charge the subscriber.|
The webhook payload will contain event specific information about the user and subscriptions. See our webhook documentation for a complete list of fields.
If you instead need to “pull” information about a subscriber, you can use our REST API as a source of truth for the most up-to-date subscriber info.
This is a common pattern for larger apps that want to use some RevenueCat features without touching any existing purchase code. We like to call this setup “Observer Mode”, since RevenueCat sits along side any existing purchase code in your app and listens for transactions, sending them to RevenueCat in the background. Once the transactions are securely stored in the RevenueCat backend, you can take advantage of features like webhooks, integrations, data exports, and more. This architecture is usually only selected if you have fully-functional purchase code you cannot rewrite, but want to supplement your existing system with features from RevenueCat, typically integrations.
With only a few lines of client-side code, “Observer Mode” allows you to accurately track subscription events and revenue in RevenueCat regardless of what is happening in your app. These can be viewed in real-time in the RevenueCat dashboard or delivered downstream to 3rd-party platforms and internal B.I. tools.
RevenueCat provides you with simple tools to handle the complex development of mobile subscriptions. The patterns we discussed are great starting points to begin thinking about how RevenueCat can fit into your app:
Depending on your apps stage and payment complexity it may make more sense to use one of these over another, or some other combination entirely!
If your app uses a different pattern than the ones discussed here, we’d love to hear about it in our discussion boards or email. As always, we are available to help you in any way we can, so don’t be shy about reaching out.
For more updates, tip, and tricks follow us on Twitter!