Featured Articles

What are Transfer Events? Transfer events are when a transfer of transactions and entitlements was initiated between one App User ID(s) to another. This event is from RevenueCat to inform you of purchases being transferred between users of your app. Why do Transfers Happen? Transfer events occur if a user claims the purchases of another user, which will happen if both users are logged into the same underlying store account, and if the user attempts to restore purchases. This is because RevenueCat will detect that the purchases belong to that app store account and will then transfer the purchases to the new user so they can access their purchases. RevenueCat is able to detect this because transactions are associated to the underlying store account. FAQs Can I have multiple RevenueCat users for the same Apple/Android account? You cannot have multiple users with the same underlying store account as they will always share purchases. How do I prevent transfers? To prevent all transfers, you

Does RevenueCat Support Purchases in (X) Country? RevenueCat supports subscriptions and in-app purchases for any country that is supported by the app stores (Apple, Google, Amazon) and Stripe. What if my country is only partially supported? If you want to support in-app purchases in Bermuda, for example, RevenueCat will work for all users in Bermuda, and they can make purchases in the Apple App Store and Amazon Appstore, but not in the Google Play Store. If a Bermudian user purchases a subscription on an Apple device, they can still access their subscription on an Android device if you properly support cross-platform usage of RevenueCat. Stripe purchases Stripe works differently from the app stores. If you as a developer have a bank account in a supported country, then you can collect payments globally. So, in the table below, if a country does not have a √ for Stripe, that does not mean you cannot collect Stripe payments from users in that country. It simply means your bank account/bu

When making purchases, you might run into unexpected errors. A common one we see our developers face is the `PURCHASE_NOT_ALLOWED` error. We have this error documented in our error handling docs . This error comes from Apple or Google and is not an indication that something is wrong on RevenueCat's side. This Error on Android When working with Android, your error might look similar to this: `ERROR: The device or user is not allowed to make the purchase. | Billing is not available in this device. DebugMessage: Google Play In-app Billing API version is less than 3. ErrorCode: BILLING_UNAVAILABLE` This error is generic; there could be several reasons this pops up. The most common is that your Android OS is out of date. We recommend updating through the Play Store and seeing if that helps. Other things to check when you get this error: Are you logged in to the correct Google Account on the device/emulator? Try logging out and logging back in. If you're testing on an emulator, can you confi

Here at RevenueCat, we've seen scenarios where individuals need to transfer their apps to another account or another owner. Although this isn't a feature that we support, we do have some workarounds to achieve this. Here are a couple of scenarios when you might need to transfer an app: You Need to Change Ownership of an App in RevenueCat When you need to change the app owner, there are two options available: To transfer the entire RevenueCat account, including all of its apps, log into the account that owns the app and change the email to the email that is supposed to own the account on the account settings page . If needed, you can create a new email address to make handing off the account easier. To transfer specific projects from one account to another, contact RevenueCat support for assistance. You Are Selling an App in Production When you have an app you are selling, it might not be the best scenario to change the account owner's email. Instead, we recommend creating a new app ide

Restoring purchases is a mechanism by which your user can restore their in-app purchases, re-activating any content that had previously been purchased from the same store account (Apple’s App Store or Google Play). By not including a method to restore purchases, users could lose access to existing purchases to which they are entitled. This isn’t ideal, so it is strongly recommended that you include some way for users to trigger the restoreTransactions method, even if you require all customers to create accounts. What happens when a user restores purchases? When a user restores purchases, the Purchases SDK syncs the user’s device receipt with the RevenueCat backend. The device receipt contains unique information about the user’s transactions so that RevenueCat is able to pair the transactions to an app user ID and then subsequently unlock the appropriate entitlements. RevenueCat offers a configurable option in an app’s settings to change the restore behavior in the event that a receipt

RevenueCat calculates monthly billing based on the sum of all tracked purchases within your app, excluding transactions prior to RevenueCat integration and ensuring charges only apply when revenue exceeds the free tier.. Q: How is billing calculated based on monthly revenue tracked by RevenueCat? A: Our revenue calculation is based on the sum of all purchases tracked by RevenueCat within a given month. Should this total not exceed $2,500, there are no charges applied. Once this threshold is reached, a fee of 1% of the full monthly tracked revenue will be incurred. It's also worth noting that any month where your revenue falls below the $2,500 mark will result in no charges. If you’re on a legacy plan, your pricing will be different. Please reach out to RevenueCat support if you have questions about billing related matters. Q: Will migrating old purchases into RevenueCat affect my monthly revenue tracking? A: Only purchases and renewals made after your integration with RevenueCat are co

Each store has its own list of available countries. You can use RevenueCat to offer in-app purchases to all countries in the following lists: App Store country availability Google Play Store country availability Amazon App Store available countries Stripe available countries

Hi! We put together a video on the RevenueCat Youtube channel that walks through how to setup auto-renewing subscription products through App Store Connect. This may be helpful if you’re getting started with iOS subscriptions, or having trouble fetching products from Apple due to some configuration issue. Let me know if this is useful and if there’s other content you’d like to see!

RevenueCat can send webhook notifications to your backend any time an event happens in your app. Events include initial purchases, cancellations, renewals and more. Sandbox purchases also generate webhooks. This post is a deep dive into how to handle webhook events for sandbox purchases. What are sandbox webhook events? Sandbox webhook events are generated from sandbox transactions . Sandbox events have environment=sandbox and they contain data about sandbox transactions, like expiration date, trial period, etc. We send them when you make sandbox purchases so that you can test your backend code to make sure it handles webhook events properly. To learn more about what’s included in a webhook event, see our webhooks guide . Note that some events, like transfers, aren't production or sandbox, and so don't have an environment property. The following user webhook events don't have an environment property: TRANSFER SUBSCRIBER_ALIAS This is because these events are user events, not transactio

💫 Overview It’s common for developers to offer subscriptions that unlock entitlements for more than one user at a time. This is usually seen in B2B business models where one person (an administrator) can purchase multiple licenses for a product and then distribute those licenses to workers within their company. While the app stores don’t support this behavior out of the box, this article explores how developers can implement such a subscription model with RevenueCat. 📖 Definitions One-to-Many Subscription: A subscription purchased by one user that unlocks entitlements for one or more distinct users. Managing User: The user who purchases and manages a one-to-many subscription. Receiving User: A user who receives an entitlement from a one-to-many subscription. 🔐 Prerequisites You have non-anonymous user IDs for all users involved in a one-to-many subscription (i.e., the managing and receiving users). You are using RevenueCat as the source of truth for entitlements in your apps. You ha

TLDR; Only configure with a known ID, and never call logout to prevent anonymous IDs. Why does the SDK use Anonymous App User IDs? Anonymous App User IDs are generated when the SDK is configured without a provided known ID. App User IDs are used to make sure the subscription that RevenueCat is tracking gets associated with the correct user. Anonymous App User IDs are always prefixed with $RCAnonymousID: which can be useful for working with anonymous users on your server. Many apps use a combination of anonymous App User IDs and their own known App User IDs which provides flexibility in their user purchase flows. However, some applications are intended only to be used while using a known App User ID, without anonymous users at all. In that case, unintentionally creating Anonymous App User IDs can cause unwanted issues for developers and end users. To never see anonymous IDs, you need to make sure to do the following. Only Configure the SDK with a known user ID The most frequent place th

While using RevenueCat you may come across an error that has an HTTP status of 429 and a response body that looks like this: { "code": 7638, "message": "There is another request in flight trying to perform the same action."} While a 429 Too Many Requests HTTP status code is frequently associated with rate limits, RevenueCat usually returns this error if multiple API requests were made simultaneously that are trying to update a single resource in the system. For example, if you make a POST /receipts request and a GET /subscribers request for the same user at the same time, the GET /subscribers request will try to update the receipt with Apple/Google but it’s already being updated by the POST /receipt, so RevenueCat will block one of the requests to prevent data race conditions. The solution to this is to simply retry the failed request a few seconds later, which will give RevenueCat a chance to complete any in-progress operation.

If you get a 403 error status, “Secret API keys should not be used in your app.” error message, or “7243” error code when making HTTP requests to the RevenueCat API, you are probably using the wrong API key, or using a private API key when you should be using a public API key. Double-check for any typos and make sure the API key matches the one in your dashboard. The following RevenueCat REST API endpoints require using a public API key: GET /subscribers POST /attributes POST /attribution GET /offerings POST /receipts You can find your public API key by following this guide: https://docs.revenuecat.com/docs/authentication#obtaining-api-keys Make sure to use the correct public API key - for example, if you're sending an iOS receipt to RevenueCat using POST /receipts, use the public API key for your iOS app (which will look like appl_xxxxxx).

There are a variety of things you may want to test about your iOS products: different pricing, free trial durations, introductory offers, and more. The RevenueCat Experiments feature will automatically divide your new customers evenly into two groups, where each group will have a separate “current” Offering. For more information about this feature: https://docs.revenuecat.com/docs/experiments Bear in mind that this feature is currently in Beta and A/B testing is available on iOS only. When deciding to make an Offering current, double check that it works on all platforms supported by your app. This means while the experiment Offering will be available for customers on other platforms, the data is only calculated for iOS purchases. How often do Experiment results get computed? The LTV model is ran daily, typically every 24 hours after you first initiated the experiment. What to do when seeing the 'Data will show in 24 hours' message after 24 hours? If it has been well over 24 hours since

We’ve had a few reports about the offerings:completion: method on iOS not calling its corresponding completion block, specifically on iOS 15. In Flutter, React-Native, Cordova/Ionic and Unity, this method is called getOfferings. If you’re using async / await syntax, this will manifest as the await call not completing. This seems to be a bug in iOS 15, where the underlying SKProductsRequest made by the SDK doesn’t call its completion handlers (in the form of delegates). Once the bug manifests, it might prevent you from making purchases of other, regular items in Production, like downloading a new app from the App Store, even if you uninstall your app, until you reboot the device. The biggest telltale sign of this bug happening is finding the following line in the debug logs on iOS 15, but having everything work correctly on iOS 14: [BackgroundTask] Background Task 12 ("SKProductsRequest"), was created over 30 seconds ago. In applications running in the background, this creates a risk of

Customer Lists are a powerful way to organize and export your customers based on certain app interactions or important characteristics such as their current subscription status. When you export customers, RevenueCat creates a compressed CSV (CSV stands for comma-separated values) with the filtered customers as well as their attributes. The compressed CSV uses the gzip compression algorithm with a .gz extension. Decompressing on macOS For most exports, using the default macOS Archive Utility will be enough to decompress the exported file. Occasionally, due to a bug in Archive Utility, the file may fail to decompress with the error message ‘Error 79 - Inappropriate file type or format’. When this happens, you have a few options: Use the built-in Terminal to decompress the file with the following command: gzip -d /path/to/file.gz Use a third party tool like Keka to decompress the file Viewing the data in a spreadsheet Once the file is decompressed, you can import it into spreadsheet softw

Also known in RevenueCat as the STORE_PROBLEM error, this error can occur when purchasing a product and indicates there was an issue verifying the purchase with the App Store or Google Play Store. The error can either come directly from Apple or Google’s libraries, or from RevenueCat’s backend when attempting to verify the receipt. Why does this error occur? The STORE_PROBLEM error occurs more commonly in sandbox than production, and can result from different causes depending on the store. Usually, it means there was a problem connecting to the store at the time of purchase—such as the store’s servers were down, or the user’s network connection failed, so the purchase could not be verified and completed. RevenueCat will forward the underlying error , or the exact cause for the error, along with the STORE_PROBLEM error. Here is a list of possible causes from each store: Apple SKErrorUnknown . An unknown or unexpected error occurred. A “catch-all” error that may point to a problem with t

What to do when a customer says they purchased the product but didn't gain access? If utilizing RevenueCat’s Entitlement system , you should first confirm that the product is attached to the correct Entitlement. If Entitlements are set up correctly, your end customer’s purchases may have to be re-synced with RevenueCat servers. This can be done either with a user-facing button in the app triggering the restore method or through the REST API with the `is_restore` field set to `true`. Note that restoring through the REST API requires your team to collect the customer’s fetch token at the time of purchase. For iOS, this is the base64 encoded receipt file and for Android this is the purchase token . You can read more about restoring either in RevenueCat’s documentation or in the following community post: https://community.revenuecat.com/featured-articles-55/do-i-need-a-restore-purchases-button-391 If you notice that your customer’s purchase is not populating in the RevenueCat dashboard, se

RevenueCat proudly helps create an easy way to keep track of all your in- app transactions . However, although we manage your purchases, we don't process the payments for your subscriptions and non-renewing products. The differences are best explained by understanding how RevenueCat interacts during the purchasing phase of a customer buying a subscription or non-renewing product. When a user goes to your paywall, the SDK uses the product IDs from your current offering and retrieves the product information from the respective stores ( Apple/Google/Stripe). When the user selects a product to purchase, the SDK gets the product ID to send it to the store to purchase The store then processes the payment (charges the user via their payment option) and adds this product to the customer's receipt. When the customer's receipt changes, RevenueCat has listeners that update the `PurchaserInfo` object (allowing customers to get access to the product/feature they purchased) and updates our backend w

Hi! We put together a walkthrough of the dashboard on the RevenueCat Youtube channel. This may be helpful if you’re already up-and-running and want to learn more about the dashboard, or if you’re evaluating RevenueCat and want to get an idea of what you can expect. Let me know if this is useful and if there’s other content you’d like to see!

If you don't have or don't want a full website, it can be unclear on how to proceed with integrating Stripe payments alongside your existing mobile in-app purchases. This sample project demonstrates how to use Stripe Checkout and webhooks to send purchase data to RevenueCat. Once published, you’ll be able to share individual links with users that will automatically redirect to Stripe, then send the receipt back to RevenueCat once the purchase is completed. It’s recommended that you know the basics about RevenueCat and Stripe before continuing with this project. Example Use-Cases Win-back email campaigns Send individual links to expired users to re-subscribe using Stripe checkout. In this case, you’ll need to have app user IDs and email addresses paired (typically from your own auth system). Setup The easiest way to use this sample is by deploying to Heroku instantly with the button below. Or you can deploy by clicking this link. The following environment variables should be set before

App Tracking Transparency (ATT) is Apple's framework for requesting access to a user's IDFA. If you use any of our attribution integrations, this article will explain what you need to do to make your app compliant. What is App Tracking Transparency (ATT)? Starting in iOS 14.5, collecting the IDFA will require permission from the user. This is done by integrating Apple's AppTrackingTransparency framework in your app. How Does ATT Affect RevenueCat? RevenueCat will continue working as expected because RevenueCat doesn't depend on IDFA or collectDeviceIdentifiers to work. However, depending on the integrations or workflows you have, you may need to update your app to ask the user permission to collect the IDFA via collectDeviceIdentifiers. This section will help you figure out whether you need to integrate ATT. If any of the following apply to you, you don't need to integrate ATT: You only use integrations that don't require or rely on IDFA to work, such as Amplitude or Mixpanel. You don'

It’s a common issue that comes up on every single analytics platform - in one system you have 3105 active trials, on another, 5046. What’s the deal? These discrepancies are common, and can happen for a variety of reasons. This article covers why you can expect certain discrepancies between RevenueCat's analytics and other platforms, and what you can do if things don't seem right. Common Discrepancies Having a better understanding of how RevenueCat collects data and generates analytics can help a lot when comparing against other platforms. The following are the most common things to consider the vast majority of discrepancies can be attributed to. What is the source? The first thing to ask yourself when comparing analytics systems is to ask yourself, "What is the source of this data?". If the sources are different, then you should expect differences in the data as well. RevenueCat only collects data that is sent through our in-app SDKs or REST API - there's no connection to any other so

App rejections are an unfortunate and dreaded aspect of launching a new app. It’s bound to happen at some point, and in the case of subscriptions and in-app purchases, it’s usually not something that you or RevenueCat can resolve. RevenueCat can’t contact Apple on your behalf and we can’t expedite the review process, but we can help you troubleshoot the rejection and work toward a resolution. If you’ve read through our docs on rejections and are still having issues, read on. Background / Review Environment Unfortunately, Apple’s sandbox environment is notoriously flaky - there are regular outages and sometimes purchases can get hung up in their system. Most of the time this error is due to sandbox downtime, but you can read about all the causes for this error in our guide on error handling. Even worse is that Apple’s reviewers use this unstable environment for App Review, which can cause issues when the reviewer tests in-app purchases like subscriptions. The App Review team typically d