This section assumes you've followed our Quickstart section of our Getting Started guide to install and configure our SDK.
We have been testing on emulators successfully but Google recommends using a real device. If you are using an emulator, make sure it has Google Play Services installed.
In order to be able to test the app in the next steps of the development you are going to need to use a test user. This test user will be the user that you logged in first in your Android testing device. Note that the only way to changing the primary account on a device is to do a factory reset.
In the sidebar, click on Settings > License testing. Add here the account you are using in your real device (the account you are logged in with).
You are going to need to publish a signed version of the app into a closed track. If you haven’t created a closed track yet, you can create one in the Closed testing section of the Testing menu.
When creating the closed track, you are given the chance to create a list of testers. Go ahead and create a list and name it Testers.
Add again the email account you are using in your testing device to the list of tester emails, press Enter, and click Save changes
Open the Opt-in URL in your testing device (or any browser that’s logged in with that testing user) to make the user a tester. You can send the URL to your device via email, for example.
You Must Open the Opt-in URL
Opening the opt-in URL marks your Play account for testing. If you don't complete this step, products will not load.
Check Your Application ID
Often developers will use a different application ID for their test builds. This will cause you problems since Google Play Services uses the application ID to find your in-app purchases.
Add a PIN to the test device if needed
There are cases where a test user may be allowed to purchase consumables, but not subscriptions, if the test device does not have a PIN. This may manifest in a cryptic "Something went wrong" message.
Make sure that the test device has a PIN, and that the device is logged into Google Play Store.
Opening the link in the browser will show a web similar to this, with a become tester button. Press that button and your user will be able to make testing purchases on your testing device.
If you need more help setting this up, you can refer to Googles guide on creating testers here.
Make the release available in at least one country
If your app is completely new, you may need to make your app available to your country/region. To do this, go to Testing > Closed testing, click on your test track, and go to Countries / regions to add countries and regions.
Generate a signed APK or use Android App Bundle to upload a signed APK to the alpha track you just created. You don’t even need to roll out the release. Just upload the APK. You can find more information about this in this support article https://support.google.com/googleplay/android-developer/answer/7159011
Before you can make a purchase, make sure your release has been approved and available.
Build and run your app on your test device (you don't need to sign it). You should be able to complete all purchases.
After a purchase is successful, you should be able to view the transaction immediately in the RevenueCat dashboard. If the purchase does not appear in the dashboard, it's not being tracked by RevenueCat.
Make sure Sandbox Data is enabled
Make sure the the View Sandbox Data toggle is enabled in the navigation bar.
Sandbox receipts are transferred between users
If a user uploads an expired sandbox receipt (when making a purchase or restoring purchases) that had previously belonged to a different user, the receipt is transferred to the new user. This behavior is in place so you don't need to create a new test user in the Play Console for every App User Id you wish to test with.
If latest subscription has expired in sandbox and a new App User Id attempts to purchase or restore, RevenueCat will move the purchases around between users. This logic exists to simplify sandbox testing so you don’t need to create new sandbox users all the time to avoid hitting
RECEIPT_ALREADY_IN_USE errors frequently.
In the the sandbox environment, subscription renewals happen at an accelerated rate, and auto-renewable subscriptions renew a maximum of six times. This enables you to test how your app handles a subscription renewal, a subscription lapse, and a subscription history that includes gaps.
Because of the accelerated expiration and renewal rates, sometimes not all renewals are reflected in the RevenueCat customer dashboard.
Production subscription period
Sandbox subscription renewal
When testing, it may be helpful to delete a customer and all their receipts from RevenueCat to simulate a new installation. You can delete a specific user from the customer dashboard in RevenueCat. See our docs on deleting users for more information.
For more information, take a look at the official Google documentation:
Google Play Store: Testing Google Play Billing
Updated about a month ago