Where Does Revenuecat Fit In 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.

Without it, to do in-app subscriptions correctly you need servers, databases, APIs, and frontend code — all of which need to be kept up to date with the changing payment structure of Apple and 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. Here’s a quick overview:

Option #1: Just RevenueCat	Manage the entire in-app purchases backend using just RevenueCat. Quick, easy, and fully maintained.
Option #2: RevenueCat Purchases + Your Backend Code	Use RevenueCat to power purchases but use your own backend code to respond to events that can’t be done with client-side code alone.
Option #3: Existing Purchase Code with RevenueCat Features	Use RevenueCat in “observer mode”, where you use your own purchase code but sit RevenueCat on top, giving you access to the dashboard and additional features.

Option #1: Just RevenueCat

Many developers choose to only write client code and use RevenueCat to fetch products, facilitate purchases, and keep a user’s subscription status up to date across devices and platforms.

This is an ideal approach if:

• You’re looking to replace outdated or unloved subscription infrastructure with a state-of-the-art, fully maintained platform.
• 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.

‍

With this architecture, you would use RevenueCat’s Purchases SDK to securely build subscriptions in your app. Our quickstart guide is filled with code samples to get you up and running in no time.

The beauty of this setup is you only need to worry about the client code in your app – 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.

Option #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 handles all the heavy lifting of keeping a user’s subscription status up to date.

The most common setup is to respond to subscription events via webhooks. This lets you make necessary updates only when RevenueCat detects some change to a user. (Google Cloud Functions and AWS Lambda are both scalable, affordable options for catching webhooks if you don’t want to host a server.)

Webhooks are fired for the following event types:

Event TypeDescription

INITIAL_PURCHASE	A new subscription has been purchased.
NON_RENEWING_PURCHASE	A customer has made a purchase that will not auto-renew.
RENEWAL	An existing purchase has been automatically renewed.
PRODUCT_CHANGE	A subscriber has changed the product of their subscription.
CANCELLATION	A subscription has been canceled.
BILLING_ISSUE	There was a problem trying to charge the subscriber.
SUBSCRIBER_ALIAS	A new app_user_id has been registered for an existing subscriber.

The webhook payload will contain event-specific information about the user and their subscriptions. See our webhook documentation for a complete list of fields.

If you 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.

Option #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 call this setup “Observer Mode”, since RevenueCat sits alongside the 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 best if you have fully functional purchase code you cannot rewrite, but want to supplement your existing system with RevenueCat features, like 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 events can be viewed in real-time in the RevenueCat dashboard or delivered downstream to third-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. These 3 integration patterns are great starting points for 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 app’s development stage and complexity, it may make more sense to use one of these over another.

If your app uses a different pattern than the ones discussed here, we’d love to hear about it. Request a demo here, and someone from our team will set up a time to learn about your setup and discuss options. And if you want to explore the dashboard on your own, check out our dashboard sandbox.

As always, we’re here to help you in any way we can, so don’t be shy about reaching out.