Where does RevenueCat fit in your app?
Take a look at the different ways RevenueCat can fit into your app.
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.
#1: Just RevenueCat
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:
- You’re developing a brand new app or adding subscriptions to your app for the first time.
- Your existing purchase code lives completely client-side, and you want to take advantage of the security, scalability, insights and features provided by RevenueCat.
- You’re looking to replace outdated or un-loved subscription infrastructure with a state-of-the-art, fully-maintained RevenueCat platform.
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.
#2: RevenueCat Purchases + Your Backend Code
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:
- You need to update values in your database with information about a purchase, renewal, or cancellation.
- You want to power an out-of-app experience in response to some subscription lifecycle event (e.g. email a feedback survey via SendGrid after a cancellation).
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:
Event TypeDescriptionINITIAL_PURCHASEA new subscription has been purchased.NON_RENEWING_PURCHASEA customer has made a purchase that will not auto-renew.RENEWALAn existing purchase has been automatically renewed.PRODUCT_CHANGEA subscriber has changed the product of their subscription.CANCELLATIONA subscription has been cancelled.BILLING_ISSUEThere has been a problem trying to charge the subscriber.SUBSCRIBER_ALIASA new app_user_id has been registered for an existing 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.
#3: Existing Purchase Code with RevenueCat Features
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.
Choose the Right Integration for You
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:
- Using only the RevenueCat Purchases SDK
- Using a combination of the RevenueCat Purchases SDK with your own backend server logic
- Using RevenueCat as an integration hub to send accurate subscription events to all your existing software
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!