RevenueCat Announcements

With the new StoreKit 2 changes from Apple, we are excited to soon provide more precise price, currency, and country detection. We first launched this for Apple Offer Codes and Promotional Offers, and we will soon support this for standard transactions as well!We will gradually be releasing this change for all customers by the end of March of 2024! To be ready for these changes, please upload your in-app purchase keys in your app settings page. For more detailed instructions, please visit our documentation here.As the transactions in our system gradually get refreshed, you may notice the following: Increased number of updated transactions being reported in your scheduled data exports. Particularly if you have selected the ‘Receive new and updated transactions only’ option in your export settings. The changes you may see are: Price Purchased currency Country Historical chart data may also gradually update. You may notice a decrease or increase for charts that

We have added a new event to our webhooks and customer profiles: SUBSCRIPTION_EXTENDED. This event fires when the expiration date of a subscription has moved back without a renewal. This can happen if a subscription was extended through the App Store or Play Store APIs. On Google Play, we also occasionally see that subscriptions that are due to renew aren’t immediately renewed but extended by 24 hours while Google attempts to complete the payment. In these cases, we will also fire a SUBSCRIPTION_EXTENDED event, followed by either a RENEWAL or BILLING_ISSUE event within 24 hours depending on whether or not the renewal charge was successful.This new event type isn’t automatically dispatched to existing webhooks integrations, you will need to update your webhook integration to select the event.For more details, check our docs.

As of today, RevenueCat is supporting a new event type that is surfaced via the customer view on the RevenueCat dashboard, webhooks, and integrations: The EXPIRATION event. This event is fired after the subscription of a customer expires (not necessarily at the exact second the subscription expires, but shortly thereafter). This should make it even easier for you to understand the subscription status of your customers, both by looking at the dashboard or in your own backend systems. The webhook documentation has more details about the event and its fields. A few points to note:For subscriptions that expired before we shipped this new event, we will backfill and show these events on the customer page in the dashboard as you visit the page for a given customer for the first time; however, we will not send these backfilled events to webhooks and integrations (so you don’t have to handle the case where you suddenly get expiration events from long churned customers). In order to send this n

Today, we are launching two big improvements. Continue reading for all the nitty gritty details, but let’s start with the big advantages you have with the new features: You can now share subscriptions not only between versions of the same app on different platforms (e.g., between iOS and Google Play Store), but also between different apps on the same platform. We now support the Amazon Appstore for your Android apps. For more information, see our documentation on installing the SDK and configuring Amazon Appstore products. To enable these changes, we’ve completely overhauled our model for how apps are created and set up. Logging into your RevenueCat dashboard, you will notice that the “Apps” dropdown menu has been replaced with “Projects”:A Project is a set of Apps. Each App is specific to one platform. For example, a typical Project might contain one iOS App and one Google Play Store App. All Apps within one project share the same basic setup, including entitlements, offerings, inte

We’re happy to announce that RevenueCat now supports Apple’s AdServices attribution framework for Apple Search Ads (ASA).You can now view AdServices ASA attribution data within RevenueCat Charts. You can unlock insights to drive more profitable growth for your app by: Filtering and segmenting RevenueCat charts by Apple Search Ads campaigns or ad groups Following your campaign's install base over time to understand the long-tail revenue generated from subscriptions We previously only supported Apple’s deprecated iAd attribution framework. While iAd gave in-depth attribution information you can only receive this data if users opted in through Ad-Tracking Transparency (ATT). The current AdServices framework is more focused on privacy and while it gives less individual depth on attribution data, you no longer require an ATT opt-in from the user, increasing the breadth of data you’ll collect.This integration is available starting in these SDK versions: iOS: purchases-ios 4.10.0 React Na

Today, we are launching two new charts showing realized (historic) Lifetime Value (LTV): one for LTV per Customer and another for LTV per Paying Customer. These two realized LTV metrics are also sometimes called ARPU (Average Revenue Per User) / ARPPU (Average Revenue Per Paying User). They shows the actual (gross) revenue that was generated by a (paying) customer cohort, divided by the number of customers in that cohort. Customers are cohorted by the date they were first seen, i.e. the date they first opened your app.Using the “Customer Lifetime” selector, you can define the time period after the customer was first seen that should be considered in terms of revenue. For example, by setting the “Customer Lifetime” selector to 30 days, all revenue generated by customers in their first 30 days will be added up, and any revenue generated after that will be discarded for the purpose of this chart.These charts give you an overall view how the monetization of customer cohorts has developed o

New SDK ReleasesIn the new SDK version, we’ve redesigned the way that user identification works. We introduced two new methods, logIn and logOut, for handling user identification. These replace createAlias, identify and reset.To take advantage of the new Identity features, you just need to replace identify and createAlias with logIn, and reset with logOut. These new methods hopefully make usage more clear, and there’s some under-the-hood performance improvements you’ll get for free. New Dashboard OptionsRegardless of whether you have started using the new SDK, we’re also introducing a new option in the dashboard so you can configure the desired behavior when two different App User IDs restore the same Apple or Google receipt. Available options are: Transfer to the new user (default) Block the transferThis behavior can be changed at any time through the RevenueCat dashboard, and it replaces the deprecated SDK property allowAppStoreAccountSharing.(Note: Some developers may see the legacy

We’ve been working on a brand new version of our REST APIs, and we’d love your participation in our closed beta for the new version.The new REST API allows:Managing your products, offerings, and entitlements Getting customer information without creating a new one in the same request Retrieving a list of a customer’s active entitlements and aliases Obtaining overview metrics  and many more to come Our new endpoints also introduce list and pagination for ease of access for entities of the same type, improved error responses to properly handle failed requests, and rate limiting headers. For more details, you can check out the preliminary documentation for our new API.How can you help?We are looking for developers who are interested in the above use cases and willing to participate in a beta program for this feature. Some key benefits of participating:Being the first to gain access to our new APIs Being able to give feedback before launchIf you’re interested, please fill out this Typeform

Over the past few months, we’ve been busy at work improving our new charts. Starting today, we have migrated everyone to the new charts experience. The new charts do not just have a refreshed look & feel, they also provide improved functionality over the old charts: We have launched a number of new charts: Annual Recurring Revenue (ARR) provides an industry-standard way of looking at your recurring revenue, normalized by subscription duration. Movement charts (Active Subscriptions Movement, MRR Movement, Active Trials Movement) provide full transparency on what causes important indicators of your business to increase or decrease. Refund Rate offers a view of what proportion of your transactions end up getting refunded. Initial Conversion allows analyzing what proportion of newly acquired customers take an action on your paywall (starting a free trial, starting a paid subscription, or making a one-time purchase). Conversion to Paid allows analyzing what proport

As of today, RevenueCat is supporting Apple order ID lookup. Customers can retrieve this order ID from their purchase history on the App Store and it is also sent in the email receipt each time they make in-app purchases. This will aid your support cases when your customers claim they purchased a product and never had their features unlocked.  To enable lookup via Order ID for iOS apps, follow our guide on setting up In-App Purchase Keys.

  Hey all, as some of you might know we’ve been hard at work upgrading our platform to support all the of Google's new subscription model. As we are preparing for our new Android major release we would like to get your help as a beta tester with the new product setup and the basic purchase flow.Here is a new blog for you to refresh your memory / familiarize yourself on what are the main changes between Billing Client 4 to 5.Here are our requirements for you to become a beta tester: 📱 Have a native Android App (No Hybrids or Amazon for now) 🔍 You are not using Observer Mode 🎞 For now we will not restore purchases that happened outside of RC 🔆 You have maximum of 20 products (soft requirement)  🌲 Availability and willingness to test with us  🕺🏾 Not using dev-determined offers (yet)  How can you help?😻If you fit the above requirements and have capacity to beta test with us please respond to the thread or drop me an email at anna@revenuecat.com. I will then confirm your a

We have just launched a new webhook event type: TEMPORARY_ENTITLEMENT_GRANT. This event gets sent if we were temporarily unable to validate a purchase with the respective store and have granted a short-term entitlement to the customer. It is sent in exceptional situations (for example, a partial app store outage) and is used to avoid customers making a purchase but not getting access to their entitlement. The expiration date of the entitlement is always at most 24 hours in the future. Once the exceptional situation has been resolved and RevenueCat can validate the purchases, a regular INITIAL_PURCHASE event will be sent.Reacting this event is completely optional. If you are using the RevenueCat SDK or API to check customers’ entitlements, this temporary entitlement grant is already taken into account. Only if you are maintaining entitlement status separately in your backend should you consider reacting to this event. The event is launched as opt-in: If you wish to receive it in your we

Hi everyone, today we launched our RevenueCat Billing and our Web SDK, our native solution for web subscriptions, in beta. For more details, please check out our documentation. If you have any feedback about the beta, please feel free to share it in the community – we will keep working on adding functionality.

In approximately one week, on April 9, 2025, we will make a small change to the RevenueCat-calculated IDs for any new non-subscription purchases happening after that date. We will increase the length of the IDs to 25 characters to avoid collisions between different purchases. This ID is exposed via our SDK, Web API, and webhooks. Subscriptions and purchases that happened before the change will not be affected.This will likely not have any impact on the vast majority of developers – the ID was a string and remains a string, only longer (25 characters) and with more potential characters (A-Z, a-z, 0-9, -, =, and _). If you are ingesting this string in a database on your side, please make sure that the database schema accepts strings of that length.If you have any questions about this change, please feel free to ask them below. 

We are at an exciting moment with our platforms team: looking at our roadmap for future integrations. Many of you have asked us about Braintree before, so we are now identifying and evaluating some of our assumptions and looking at ways to integrate this. What would help us is to better understand how you are using Braintree and what are the most important features for you. In addition to that, if you can, it would be very helpful for us to better understand your current monthly tracked revenue (MTR) via Braintree. Of course we understand that this not something to share in a community post, feel free to send me an email to help our estimation for the demand of Braintree anna@revenuecat.com

SummaryWe fixed a bug in Customer List data where a purchase transfer on restore would not result in the original customer (App User ID) being removed from the relevant list.  ImpactThis bug only impacted Customer Lists; and therefore had no impact on entitlement access, event data, or data from other features like Overview, Charts, and ETL Exports.Though the purchase associated with that original customer would no longer be updated, and therefore would “expire” at their next renewal (removing the original customer from the Active list), this bug would result in slightly elevated counts of Active Subscribers or Active Trials from recently transferred purchases that have not yet expired if you use the Transfer Purchases Restore Behavior. Learn MoreTo learn more about Restoring Purchases, click here; or to learn more about Customer Lists, click here. Thanks very much,- DanPM @ RevenueCat

SummaryWe’ve made an improvement to how we handle churn (subscription expirations) in data features to ensure the subscription metrics we offer in places like Charts are consistent with the subscription behavior in apps using RevenueCat. Store(s) Old Behavior New Behavior App Store Churn date in some data features was reported as the original subscription expiration date, regardless of whether a grace period was offered Churn date in these data features is now reported as the expiration of a subscription’s grace period if offered Google Play Store, Stripe, and Amazon Appstore Churn date in all data features was reported as the expiration of a subscription’s grace period (if offered) No change  Subscription expirations in the SDK always take the grace period into account for reporting a subscriber’s status and revoking entitlements. Some data features like webhooks & integrations, already take the grace period into

Our launch of Amazon Appstore support is around the corner. If you are interested in joining the beta before official launch, let us know via this post or by dropping me an email: jens@revenuecat.com. JensHead of Product @ RevenueCat

RevenueCat can now optionally report revenue after store commissions, or after taxes and commissions through features such as charts, integrations, and webhooks:The Revenue chart now includes new measures to distinguish between revenue deducted for taxes vs. commissions & fees (learn more) Webhooks include tax_percentage and commission_percentage fields for calculating these values yourself (learn more) All revenue-reporting integrations can be toggled to report revenue on a gross, net of commission, or net of commission & taxes basis (learn more)Especially in regions where a VAT is applied, this should result in a much more accurate estimation of the proceeds (net revenue) you’ll generate from your gross revenue.Tax estimation is complicated though, and each store handles the application of VAT and other taxes like digital service tax (DST) quite differently. To learn more about how RevenueCat estimates taxes on each transaction – including all historical transactions – and ho

Today, we are launching two new charts to better understand your funnel from newly acquired customer to paying subscriber.The Initial Conversion Rate chart shows what proportion of each cohort of new subscribers either started a trial or made a purchase without a trial. You can think of it as the proportion of subscribers who took an action on your paywall, or paywall conversion.The Conversion to Paying chart shows what proportion of each cohort of new subscribers ends up paying (either because they converted from a free trial to paying subscriber, or because they made a purchase without a trial). This can be thought of as the end-to-end view of the conversion funnel within your app.With these new charts, we now offer three views of conversion rates (the Trial Conversion chart remains, of course). Which of these are most useful and valuable to you will depend on your product setup—whether you offer subscriptions with trials, without trials, or a mix of both.Let us know if you have any

In a few days, we will add a new field to our webhook event payloads: renewal_number. The renewal number describes how many times this subscription has already recurred. It always starts at 1 (ie., the first event sent for a new subscription has the renewal_number 1). Trial conversions are counted as renewals.If you are using RevenueCat webhooks, please make sure that your webhook processing can handle this new field.

You might have received an email from Google about a change to Cloud Pub/Sub message retention pricing, effective June 30, 2024. If you’re wondering what this is and whether it affects you, I’ll add some clarifying thoughts here:  Are RevenueCat apps affected?No. RevenueCat acknowledges all Pub/Sub messages right away, so using RevenueCat will not incur any extra charges on your account from this message retention policy.  Am I affected outside of RevenueCat’s usage?Probably not, but you could be affected if you have:“idle subscriptions” (meaning things that subscribe to the Pub/Sub messages but don’t actually do anything).  use the pub/sub queue as a form of a backup, and return a non-200 status code to pub/sub messages so they don’t get deleted from there have listeners that are very slow to respond (over 24 hrs).  Is there a way to check if I’m affected? Yes! Just log into Google Cloud (not Play Console): https://console.cloud.google.com/cloudpubsub/subscription/Then select your pro

Today, we are shipping changes to our new charts that provide improved transparency about refunded transactions. Especially given that on iOS, developers have no control and little transparency on refund decisions, it is important to keep an eye on refunds because they are an indicator of whether your customers are getting the value they expected when they started their subscription.The biggest improvement is our new refund rate chart. It shows you how many transactions happened in a given time period, and how many of them were refunded. Of course you can see how your refund rate develops over time, as well as filter or segment by various different dimensions, for example to understand refund rates of different products or between iOS App Store and Google Play Store.In addition to the new chart, we are also changing how refunds are handled in the remaining charts. Previously,  when a refund occurred, we retroactively removed the affected subscription from all charts in which it was sho

Hey RevenueCat Community -- sharing a quick update to let you know that today we’re updating the Customer Support role to no longer have access to the Customer Lists feature. This is to ensure developers have control over which team members have access to aggregate business data.Customer Support collaborators will continue to have access to look up customers, review transaction history, grant promotionals, issue refunds, and delete customers as described here.Additionally, Admin and Read Only collaborator roles will continue to have access to Customer Lists. If you have any questions regarding this change, please reach out to our support team and we’ll be happy to assist you. Thanks!

Our webhooks have for a while supported events for billing issues, now these are also being sent to analytics and CRM integrations. These events will be sent to integrations whenever a subscriber was charged unsuccessfully (e.g., expired credit card or lack of funds). In order to properly receive these events, you will need to set the event name in your configured integrations:There are several use cases for these events: in analytics tools, you may want to analyze how often billing issues occur for which cohorts or segments of users. In CRM tools, you may want to set up push notification or email campaigns to prompt subscribers with billing issues to update their means of payment.We hope this new event type is useful. Let us know about any concerns or issues with the new events!JensHead of Product @ RevenueCat