Learn and Share
Learn more about RevenueCat and talk about it with the community.
Hi all, Some feedback/thoughts on offer codes. To set the scene, we’ve recently set up a b2b partnership and are using 12 month offer codes to provide their customers with access to our app. Offer code’s aren’t included in integration data, i.e. GCP exports and Facebook. Nor is there a way to filter for offer codes in customer lists. In order to track code consumption, we’ve had to set up web hooks, cloud functions and a custom dashboard. Not a massive issue, but the reason we’re paying for RC is to make these things easier. Offer codes are marked as trials. For us, this makes no sense - we’re expecting (/hoping) to have thousands of these codes used. It’s going to boost our active trials rate by 12 months each, thus rendering the dashboard ‘active trials’ rate useless. Again, there’s no way to filter so we can’t get true active trials in the customer list’s either. Lastly, I'd like a way to see on the customer profile if they’ve used an offer code. Thanks for reading, hopefully the
This is so frustrating that the customer list export is a .GZ file….If you are on a PC you are unable to view the file, you must convert it to CSV. Every time the file is converted, its gets corrupted and data goes missing (regardless of what conversion method you used)This is so annoying because the only way to review and analyze the customer list export data is by asking my friend with a Mac to download it and upload it to google sheets for me.Can there PLEASE be a way to download the data via CSV so all users (regardless of comp) can access it?
As a developer, you probably spent time looking through the REST API endpoints to keep subscription status in sync with your backend, update subscriber attributes server side, etc.We would love to hear from you:Is there something you’d like to be able to do through the API that you can’t currently do? Are there any fields you’d like to see that aren’t currently returned from an endpoint?Thank you!
I'm posting our experience to help clarify the (Apple) IAP release process for any other new developers.Our app (v1) was live on the App Store with one IAP, a yearly subscription. Yesterday we were approved to release v2, plus were approved for a new monthly subscription IAP. We released the app almost immediately after approval. After about 20 minutes, the new version was visible in the App Store.However, after downloading the app, we noticed that only the original annual subscription was showing up in the app. The new monthly IAP was not listed. After checking everything out (see below), we decided to wait it out before any real debugging. This morning, the app was listing both annual and monthly IAPs. So, apparently it takes some time, measured in hours, for Apple to 'activate' the SKProducts. NOTE: While the new IAP was unavailable in the app, the App Store listing was actually displaying both the annual and monthly options under: Information In-App Purchases (Yes)
The use case is simple. Let’s take my React Native iOS app as an example:A user who has already purchased a “Premium” subscription in my app goes to their iPhone Settings and unsubscribes Now they open my app and goes to the “Subscription” page to check the status My subscription page says that their sub is active AND will renew at date X, even if I run the getPurchaseInfo() again My user gets confused/angry and contacts my supportHow can I avoid the above? I’m new to RC and have just been playing around in the Sandbox environment. RC docs says certain attributes, like the “willRenew” could take multiple hours to sync. I have activated Platform Server Notifications but at least in Sandbox it seems like the info I get back from getPurchaseInfo()How can I avoid these delays and caches and whatnot, and always be sure that everything is updating instantly and the data is accurate and “fresh”?I asked the RC support about this, and they just copy/pasted the first two paragraphs of the “Webho
Hey RevenueCat Community! 👋I wanted to share a blog post I wrote recently about how you can use Entitlements for more than just in-app purchases. Since Entitlements can be granted manually as promotionals via the dashboard and REST API, you can actually use Entitlements as generic feature flags - all without being connected to any in-app purchase products at all.A good use case might be setting up beta features (maybe for only long-term paying customers, for example) and granting access to those beta features with an ‘empty’ entitlement. You could build this out as custom as you’d like - you could manually opt users into your beta from the RevenueCat dashboard, or even build an automated system from your own backend to let users opt-in to the beta themselves, all by tying into our promotionals API.I detail the process in the blog post, but would welcome any questions or comments!You can read the blog post here.
Hi all,I’ve got some subscriptions defined in Google PlayStore console, but they where to test subscriptions a while back. Now we don’t use them within RevenueCat. But I can’t delete them in the PlayStore console (asked Google Support, but they told me that we can’t remove active products) These old products are never sold because we are stil in develop phase. My question now is, are these products every visible by customers? I don’t use them in RevenueCat and are not showing them in our app on the PayWall. But maybe they are somehow visible somewhere else? And even switch to or able to buy by customers? So is it safe to leave them in de Console (otherwise I have to delete the app in de PlayStore and make a new packageID with all the extra work)What do you guys think? Any advise? PlayStore Console:
First of all, thank you to everyone who reached out to let us know RevenueCat was added to a popular ad block list! Because of your messages, we were able to quickly make sense of some customer support questions and start taking action. So, what’s the situation?The RevenueCat domain was added to a community-shared list of domains that are imported by popular ad blocking tools like AdAway and Pi-hole. This means anyone using these tools is unable to access RevenueCat functionality. More specifically, developers and teams using RevenueCat won’t be able to access the RevenueCat dashboard. And with regards to app end users, app purchases can’t sync with RevenueCat and thus won’t allow for entitlements to unlock or for purchases to be properly reflected in dashboard metrics.In other words, RevenueCat won’t work at all for these users. Why was RevenueCat added to this list?The short answer is “we don’t know.” It seems to be a misunderstanding of what RevenueCat does, although we’ve explained
Hi RevCat community Ok this might be bit of a strange question, but I've been inspired by what Duolingo have done with their recently announced family plan, where you can invite up to 5 others and only a single subscription is required (annual only, at higher price, which is smart). I’m assuming with Aliases that RevenueCat would support a user inviting another user and that user not having to go through payment process as they tied to the original user (invitee), and if that original user churned or lost their entitlement, that all aliases on that same ‘purchase record’ would also lose access? Has anyone else seen apps do shared subscriptions, beyond what apple offers with Family Plans. I know Spotify do duo plan.
Hey,because of how our subscriptions work in general, we have decided to not use the RevenueCat SDK to create purchases, but announce them to our own API, which will in turn make an HTTP call to RecenueCat’s /receipts route, passing the neccessary data.Arguably the most important piece of data is the fetch_token from the app store.The problem arises when we’re trying to run automated integration tests via our CI server - without doing an actual purchase on an actual hardware device, we won’t have a valid fetch token, so the API will always answer with the (reasonable) error: "The receipt is not valid.".So my question is two-fold:is there any way to simulate a purchase for testing purposes? how to others solve the testing issue?Or is our use-case really this particularly rare?Regards,Markus
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
When tracking webhook events and also using the API, there are data discrepancies how field values are presented or formatted. One such case is the Subscription#period_type. In a webhook event the value is uppercase but in the api it’s all lowercase. Another is the use of both millisecond timestamps and ISO 8601 datetime string. This makes for very awkward handling of RevenueCat’s data in our codebase. Granted, I realize this is not easy to reconcile in existing APIs but in the future I would hope the company can adopt standards for these fields that they stick to across their platform.
Hi everyone,I’m looking to figure out a way to reset or extend a users free trial. At present, we have successfully set up an In-App Subscription on both iOS and Android with a one week free trial. We then hope to send the user a notification or email when their trial is almost over prompting them to refer a friend to the app, which they will be rewarded for by extending the trial for another week.The refer all mechanisms is fairly easy to do with deep links, the question is once we have detected that a user has successfully referred a friend, what is the best way to extend their trial? Additionally, I’m still trying to work out how this plays with Apple’s terms of service - it seems to be within the rules but any thoughts would be appreciated.Thanks everyone!
I have an app working where we sell renewing subscriptions. I am trying to implement a new use case, we would be selling for some users a one time purchase that gives them access for 20 months. I was thinking about implementing it as a non consumable IAP, with an entitlement attached, so that when the user buys this product, they get access to the app. But I'd still have to remove the entitlement when the time is up. I could do that in the backend, but I don't see a method in the API to remove an entitlement. How would you implement this? Is there a best practice to link an entitlement to a non consumable IAP with an arbitrary expiration date?
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 iden
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 macOSFor 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.gzUse a third party tool like Keka to decompress the file Viewing the data in a spreadsheetOnce the file is decompressed, you can import it into spreadsheet software lik
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 transaction eve
We change our prices time to time on store and when the prices increase and customer cancel and resubscribe, they usually email us through support.Is there a way we can modify the price on revenue-cat for specifically for disappointed customers. How can we compensate these customers with some kind of offering?
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!
Hey everyone, I’m curious what folks’ approach is regarding the Epic-vs-Apple decision? Is anyone making plans already to explore linking out of the app to a web paywall? Or are you going to wait and see how things turn out?At RevenueCat, we’re currently playing around with a few options to support potential use cases (of course, pending what exactly will and won’t be allowed), and I’d love to get a feeling for the level of interest in the topic.JensHead of Product @ RevenueCat
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 the
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,
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 has