Join us for ⁠#Android11: The Beta Launch Show on June 3!

Test Google Play Billing

After you have implemented Google Play Billing, you can test purchases of your in-app products. This document contains the following sections:

Prepare for testing

To prepare to test your Google Play Billing implementation, perform the following tasks:

  1. Publish your app to a closed or open testing track in Google Play. After you publish an app to a testing track it can take a few hours for the app to be available for testers.
  2. Ensure each tester opts-in to your app’s test. On your test’s opt-in URL, your testers will get an explanation of what it means to be a tester and a link to opt-in.

You can test on any Android-powered hardware device running Android 1.6 or higher. The most current version of the Google Play application must be installed on the device. For general information about how to set up a device for use in developing Android applications, see Using Hardware Devices.

Solo-test a Google Play Billing app

Test with static responses

Google Play Billing provides a combination of reserved product IDs and associated static responses that you can use to test your Google Play Billing implementation. These responses enable you to verify that your application is handling the primary Google Play responses correctly. You can test your Google Play Billing implementation using these static responses before involving testers, and even if the app hasn't been published yet.

To test your implementation with static responses, you make a Google Play Billing request using a special item that has a reserved product ID. Each reserved product ID returns a specific static response from Google Play. No money is transferred when you make Google Play Billing requests with the reserved product IDs. Also, you cannot specify the form of payment when you make a billing request with a reserved product ID.

Note: Static responses cannot be used to test subscriptions.

You do not need to list the reserved products in your application's product list. Google Play already knows about the reserved product IDs. Also, you do not need to upload your application to the Google Play Console to perform static response tests with the reserved product IDs. You can simply install your application on a device, log into the device, and make billing requests using the reserved product IDs.

Note: Previously you could test an app by uploading an unpublished "draft" version. This functionality is no longer supported. However, you can test your app with static responses even before you upload it to the Google Play Store. For more information, see Test with static responses.

There are three reserved product IDs for testing static Google Play Billing responses:

  • android.test.purchased

    When you make an Google Play Billing request with this product ID, Google Play responds as though you successfully purchased an item. The response includes a JSON string, which contains fake purchase information (for example, a fake order ID).

  • android.test.canceled

    When you make an Google Play Billing request with this product ID Google Play responds as though the purchase was canceled. This can occur when an error is encountered in the order process, such as an invalid credit card, or when you cancel a user's order before it is charged.

  • android.test.item_unavailable

    When you make an Google Play Billing request with this product ID, Google Play responds as though the item being purchased was not listed in your application's product list.

To make an Google Play Billing request with a reserved product ID, construct a normal REQUEST_PURCHASE request, but instead of using a real product ID from your application's product list use one of the reserved product IDs.

To test your application using the reserved product IDs, follow these steps:

  1. Modify your app so it uses one of the three reserved product IDs during the purchase flow. For information on using a product ID to make a purchase, refer to Enable the purchase of an in-app product.
  2. Install your application on an Android-powered device.

    You cannot use the emulator to test Google Play Billing; you must install your application on a device to test Google Play Billing.

    To learn how to install an application on a device, see Running on a device.

  3. Sign in to your device with your developer account.

    You do not need to use a test account if you are only testing with reserved product IDs.

  4. Verify that your device is running a supported version of the Google Play app or the MyApps app.

    If your device is running Android 3.0, Google Play Billing requires version 5.0.12 (or higher) of the MyApps app. If your device is running any other version of Android, Google Play Billing requires version 2.3.4 (or higher) of the Google Play app. To check the version of the Google Play app, launch the app, then open the Settings menu and scroll down to view the version information.

  5. Run your application and make a purchase using a reserved product ID. The code in your onPurchasesUpdated() shoud properly handle the static response. For information implementing onPurchasesUpdated(), refer to Enable the purchase of an in-app product.
  6. Re-test with the other reserved product ids.

Note: Making Google Play Billing requests with the reserved product IDs overrides the usual Google Play production system. When you send an Google Play Billing request for a reserved product ID, the quality of service will not be comparable to the production environment.

Test the complete purchase flow

After you finish your static response testing, and you verify that signature verification is working in your application, you can test your Google Play Billing implementation by making actual in-app purchases. Testing real in-app purchases enables you to test the end-to-end Google Play Billing experience, including the actual purchases from Google Play and the actual checkout flow that users will experience in your application.

Note: You can do end-to-end testing of your app by publishing it to a closed testing track. This allows you to publish the app to the Google Play Store, but limit its availability to just the testers you designate.

To test your Google Play Billing implementation with actual in-app purchases, you must use a test account. By default, the only test account registered is the one that's associated with your developer account. You can register additional test accounts by using the Google Play Console. If you haven't set up test accounts before, see Set up test accounts.

A test account can purchase an item in your product list only if the item is published.

To test your Google Play Billing implementation with actual purchases, follow these steps:

  1. Upload your application to a closed testing track in the Google Play Console.

    Note: After your initial app upload, license testers can make purchases from development versions of your app without needing to upload to the Google Play Console. This allows you to use debug signed builds and make changes without having to upload a new version each time.

    Note: Previously you could test an app by uploading an unpublished "draft" version. This functionality is no longer supported. Instead, you must publish your app to the closed or open testing track.

  2. Create your in-app products in the Google Play Console. For further details, refer to Create a one-time product and Create a subscription
  3. Install your application on an Android-powered device. You cannot use an emulator to test Google Play Billing. To learn how to install an application on a device, see Run your app on a device.
  4. Verify that your device is running a supported version of the Google Play application or the MyApps application. If your device is running Android 3.0, Google Play Billing requires version 5.0.12 (or higher) of the MyApps application. If your device is running any other version of Android, Google Play Billing requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the version of the Google Play application, see Updating Google Play.
  5. Make in-app purchases in your application.

Note: The only way to change the primary account on a device is to do a factory reset, making sure you log on with your primary account first.

User-test a Google Play Billing app

Set up test accounts

To set up a tester account:

  1. Use the Google Play Console to upload and publish in-app products that you want testers to be able to purchase. Note that you can upload and publish your in-app items before you publish the APK itself.
  2. Use the Developer Console to create license tester accounts:
    1. Navigate to Settings > Account details.
    2. In the License Testing section, add your tester's email addresses to Gmail accounts with testing access field.
    3. Save your changes. Testers can begin making purchases of your in-app products within 15 minutes.

Note: Test accounts must be on the tester’s Android device. If the device has more than one account, the purchase will be made with the account that downloaded the app. If none of the accounts has downloaded the app, the purchase is made with the first account. Users can confirm the account that is making a purchase by expanding the purchase dialog.

Instruct testers to make test purchases

After test accounts are set up, you can instruct users to make test purchases. Following are some details about the test purchases process:

  • Users will use the same app purchase flow used by regular users.
  • Uses should make at least two purchases, one with the "always approve" form of payment and one with the "always declined" form of payment. These test forms of payment allow you to ensure your app reacts properly when payments are approved or declined. Figure 1 shows these test forms of payment as they appear within the purchase flow:
    Figure 1. Payment method test instrument options for a license-test user.
    These forms of payment are the only two forms of payment available to licensed testers. When using these forms of payment, the purchase flow will return the result immediately.
  • Taxes are not computed for test purchases.
  • Licensed testers will not be charged for their purchase.
  • Google Play indicates a test purchase by displaying a notice across the center of the purchase dialog.

Note: If you want to be able to perform multiple test purchases for the same in-app product, mark the item as consumed after each purchase. To do so, call consumeAsync().

Test with actual accounts

As you prepare to launch an app that uses Google Play Billing, you can make use of Google Play closed or open release options to do validation and load testing on your implementation before distributing the app to all of your users.

With closed or open test groups, users can install your app from Google Play and test your in-app products. Users can make real purchases that result in actual charges to their accounts, using any of their normal payment methods in Google Play.

Note: If you include test license accounts in your closed and open test distribution groups, those users will only be able to make test purchases.

Test one-time product-specific features

Testing in-app promotions

If your app supports in-app promotions, test the following use cases.

User redeems promo code in the app

If the user redeems a promo code within the app's purchase flow, as described in Making Google Play Billing requests, the system invokes your activity's onActivityResult() method to handle the purchase. Verify that onActivityResult() handles the purchase properly, whether the user pays with money or a promo code.

User redeems promo code in the Google Play Store

If the user redeems a promo code in the Play Store, there are several possible workflows. Verify each one of these workflows.

App is not installed

If the user redeems a promo code for an app that is not installed on the device, the Play Store prompts the user to install the app. (If the app is installed but not up-to-date, the Play Store prompts the user to update the app.) Test the following sequence on a device that doesn't have your app installed.

  1. The user redeems a promo code for the app in the Play Store. The Play Store prompts the user to install your app.
  2. The user installs and launches your app. Verify that on startup, the app calls getPurchases() and correctly detects the purchase the user made with the promo code.
App is installed, but not running

If the user redeems a promo code for an app that is installed on the device, the Play Store prompts the user to switch to the app. Test the following sequence on a device that has your app installed but not running:

  1. The user redeems a promo code for the app in the Play Store. The Play Store prompts the user to switch to your app.
  2. The user launches your app. Verify that on startup the app calls getPurchases() and correctly detects the purchase the user made with the promo code.
App is installed and running

If the user redeems a promo code for an app that is currently running on the device, the Play Store notifies the app via a PURCHASES_UPDATED intent. Test the following sequence:

  1. The user launches the app. Verify that the app has properly registered itself to receive the PURCHASES_UPDATED intent.
  2. The user launches the Play Store app, either manually or using a generated URL that includes a promo code, and redeems the promo code for the app. The Play Store fires a PURCHASES_UPDATED intent. Verify that your app's BroadcastReceiver.onReceive() callback fires to handle the intent.
  3. Your onReceive() method should respond to the intent by calling getPurchases(). Verify that your app calls this method and that it correctly detects the purchase the user made with the promo code.
  4. The user switches back to your app. Verify that the user has the purchased item.

Test subscriptions-specific features

The purchase flow for one-time products and subscriptions are similar, but subscriptions have additional scenarios, such as successful or declined subscription renewals. To help you test your application for both situations, you can use the "Test instrument, always approves" and "Test instrument, always declines" payment methods. Use these payment instruments to test scenarios beyond the successful subscription scenario.

Test subscription renewals

Test subscriptions renew more quickly than normal to aid in testing. The following table identifies the testing renewal times for subscriptions of various durations.

Note: These times are approximate; you may see some small variations in the precise time of an event. To compensate for variation, call the API to view the current status after every subscription expiration date.

Production subscription periodTest subscription renewal
1 week5 minutes
1 month5 minutes
3 months10 minutes
6 months15 minutes
1 year30 minutes

Note: Test subscriptions will renew a maximum of 6 times.

The time-based features available for subscriptions, such as free-trials, are also shortened for testing. The following table identifies the testing time periods associated with time-based subscription features:

FeatureTest period
Free trial3 minutes
Introductory price periodSame as subscription test period
Grace period (both 3- and 7-day) 5 minutes
Account hold10 minutes
Pause (1 month)5 minutes
Pause (2 months)10 minutes
Pause (3 months)15 minutes

Renewal rate testing scenarios

Click Show/Hide to display several testing scenarios demonstrating the interval of testing renewal rates.

Cancel a completed test purchase

Google Play accumulates completed test purchases for each user but does not pass them on to financial processing.

Test purchases are not automatically canceled, so you might want to manually cancel a test purchase to continue testing. To do so, open the app page in the Play Store. If the test purchase that you want to cancel is a subscription, you can also use the cancel() method of the Purchases.subscriptions API.

Important: The refund() and revoke() methods of the Purchases.subscriptions API don't support test purchases.

Next Steps

When you are finished testing your Google Play Billing implementation, you are ready to publish your application on Google Play. You can follow the normal steps for preparing, signing, and publishing on Google Play.