RevenueCat currently supports web payments through Stripe. This allows you to let users subscribe on your own website using Stripe, and automatically unlock access based on the Stripe subscription through the _Purchases SDK_.

Remember that it is against Apple's App Store terms to provide a different system than in-app purchases for digital goods. Make sure you don't promote your web subscriptions from inside your app. Your app may get rejected, or banned.

Before launching your Stripe integration, be sure to read the limitations that apply to [working with web payments](πŸ”—ο»Ώ).

# 1. Connect with Stripe

Log into [RevenueCat](πŸ”—ο»Ώ) and click the _Connect with Stripe_ button in your account settings. Install the RevenueCat Stripe App either by creating a new account with Stripe or sign in with your existing one. Finalize setting up the connection between Stripe and RevenueCat in the RevenueCat Stripe App. RevenueCat only requests the permissions from Stripe found [here](πŸ”—ο»Ώ). We will not be able to issue charges on your behalf. You will still maintain full control through the Stripe dashboard.

ο»Ώ

ο»Ώ

ο»Ώ

Project owner must connect with Stripe

Only the owner of the RevenueCat project can connect a Stripe account for their apps - no [collaborators](πŸ”—ο»Ώ) will be able to add or remove a Stripe connection.

# 2. Create products and plans on Stripe

Create your Stripe product(s) using [their billing dashboard](πŸ”—ο»Ώ). In Stripe, a _product_ can have multiple _pricing plans_. These are useful if you want to offer different price points for the same product and work similar to _offerings_ and _products_ in RevenueCat.

ο»Ώ

You can read more about **products and plans** in [their official documentation](πŸ”—ο»Ώ).

Important

RevenueCat only supports **per unit** and **recurring quantity** subscription plans. Metered usage and tiers are currently not supported.

# 3. Create subscriptions on Stripe

The typical setup consists of a website that uses [Stripe checkout](πŸ”—ο»Ώ) to tokenize the customer payment information, and send this information to your server. After that, your server will be able to subscribe your customer to a product.

On the server-side, you can use [Stripe's REST API](πŸ”—ο»Ώ) or their library for your favorite programming language. An example can be found [here](πŸ”—ο»Ώ).

Alternatively, you can also use the Stripe dashboard for manually creating the subscriptions for testing.

Using Checkout Sessions?

ο»Ώ[Ensure your session creates a Stripe Customer](πŸ”—ο»Ώ) by setting `customer_creation` to `always`.

# 4. Add your Stripe products to your project's entitlements

Add your Stripe products to your project's [entitlements](πŸ”—ο»Ώ) to easily group the products for your app. RevenueCat will send Stripe subscriptions to your app the same way we do for the other app stores.

ο»Ώ

Product Identifier should be a Stripe product ID

In order for Stripe subscriptions to unlock [entitlements](πŸ”—ο»Ώ), you must set a Product Identifier in the desired Offering to match a Stripe **product ID** exactly.

# 5. Send Stripe tokens to RevenueCat

You can send your Stripe subscriptions to RevenueCat through the [POST receipt endpoint](πŸ”—ο»Ώ). If you are using Stripe Checkout, you should send the subscription after the checkout.session.completed event.

The only required fields are:

  • `fetch_token`: Your Stripe subscription ID (`sub_...`) OR your Stripe Checkout Session ID

  • `app_user_id`: The App User ID that the subscription should be applied to

**Headers**

  • `X-Platform`: Should be set to `stripe`.

  • `Authorization`: It should be `Bearer YOUR_REVENUECAT_STRIPE_APP_PUBLIC_API_KEY`

Stripe subscriptions are automatically refreshed by RevenueCat the same way as subscriptions from the app stores. This means that **it may take up to two hours for a Stripe cancellation to be reflected in the RevenueCat backend**. Alternatively, you can re-post the same subscription to RevenueCat after a user has cancelled, and it will be updated right away.

One-time Stripe purchases supported

RevenueCat supports one-time purchases as well as subscription purchases through Stripe.

One-time purchases require using Stripe Checkout, and you'll need to send us the Checkout Session ID as the fetch_token. Additionally, you'll need to use Stripe's [Prices](πŸ”—ο»Ώ) objects. RevenueCat supports both one-time purchases and subscriptions made through Stripe Checkout.

ο»Ώ

App User ID is required

In order for a Stripe subscription to be honored within an app, the _Purchases SDK_ needs to be configured with the same App User ID associated with the Stripe subscription.

# 6. Test your Stripe subscriptions

You can test your implementation for Stripe and RevenueCat by using [Stripe's test mode](πŸ”—ο»Ώ).

The subscriptions you create using this environment will be considered _sandbox transactions_ in RevenueCat.

ο»Ώ

Stripe Test Clocks not fully supported

Stripe allows using [test clocks](πŸ”—ο»Ώ) to manipulate how subscriptions move through time. Since using test clocks lead to time divergences between Stripe and RevenueCat, data may not be accurately reflected in RevenueCat when using Stripe test clocks.

# Working with web payments

Subscription payments through the web are processed with the same logic as subscriptions through the app stores. This means there are currently some limitations that must be considered for web payments to work properly.

Coupons are supported

Pricing in RevenueCat [Charts](πŸ”—ο»Ώ) and [customer events](πŸ”—ο»Ώ) will reflect any coupons applied to a Stripe purchase.

## Supported subscription plans

Only **Package Pricing** and **Standard Pricing** subscription plans with **per unit** pricing are supported. Metered usage and tiers are currently not supported. This is currently how the app stores behave.

## Upgrading and downgrading

Prorated amounts are not factored into _MRR_ or _Revenue_ calculations. If someone changes plans, the default behavior in Stripe is to give the user credit for any unused portion and bill them for the remainder of the new plan cost. You need to disable this behavior manually, or by passing the `prorate=false` flag through the Stripe API for accurate revenue calculations in RevenueCat.

## Cancellations

When a subscription is cancelled in Stripe, you have two options:

  1. Immediate cancellation: The subscription is cancelled immediately, with the option to pro-rate or not.

  2. Cancellation at the end of the period: The subscription is cancelled at the end of the current billing period (this is how the app stores behave).

Both options are supported by RevenueCat, but the _MRR_ and _Revenue_ calculations will only be accurate in the first case if you choose **not** to prorate.

Cancellations in Stripe are automatically detected by RevenueCat the same way as subscriptions from the app stores. This means there may be up to a two-hour delay between when the subscription is cancelled in Stripe and when the cancellation is reflected in the RevenueCat backend.

## Billing Issues

When a customer encounters an issue with their payment, RevenueCat will generate a billing issue event in the RevenueCat [Customer History](πŸ”—ο»Ώ). If all retries for a payment fails, you have three options:

  1. cancel the subscription: RevenueCat will **revoke access**.

  2. mark the subscription as unpaid: RevenueCat will **revoke access**.

  3. leave the subscription as-is: RevenueCat **will not revoke access**.

You can find these options, along with your Retry schedule, in your Stripe dashboard under **Settings > Billing > Subscriptions and email > Manage failed payments**.

If you are expecting a billing issue event, it may take a few hours for the RevenueCat dashboard to display the event. Note that we will only generate the billing issue event once and we do not generate new ones when subsequent retries fail.

That's it!

You can now allow users to subscribe from the web or within your app, and let them access their subscription anywhere.