Build With RevenueCat

Build a customized mobile subscription business with RevenueCat. We do the heavy lifting of normalizing subscribers from any source and maintain a single source of truth for subscription status, so you can get back to building your app.

RevenueCat is a powerful, secure, reliable, and free to use in-app purchase server with global support. All you need to get started is an API key.

Get Started    API Reference

Google Play Store

Testing purchases in Play Store Sandbox

👍

This section assumes you've followed our Quickstart section of our Getting Started guide to install and configure our SDK.

Use a real device

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.

Create a test user and configure licensing testing

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).

Create a closed track and add a tester to it

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.

You must open one of these urls while signed in with the Play account you're testing with.

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.

Upload a signed apk to the closed track

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

Make a purchase

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.

Verify transaction appears in dashboard

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.

Sandbox specific logic

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.

Working with subscriptions

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

1 week

5 minutes

1 month

5 minutes

3 months

10 minutes

6 months

15 minutes

1 year

30 minutes

Deleting test users

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.

Next Steps

For more information, take a look at the official Google documentation:
Google Play Store: Testing Google Play Billing

Updated about a month ago


Google Play Store


Testing purchases in Play Store Sandbox

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.