You should be testing your integration throughout development. To test
during the development phase, we recommend leveraging
license testers
to run through the scenarios described in this topic.
To configure license testers, see
Test in-app billing with application licensing
.
Using license testers provide the following benefits:
- Ordinarily, the Google Play Billing Library is blocked for apps that aren't
signed and uploaded to Google Play. License testers can bypass this check,
meaning you can sideload apps for testing, even for apps using debug builds
with debug signatures without the need to upload to the new version of your
app. Note that the package name must match that of the app that is
configured for Google Play, and the Google account must be a license tester
for the Google Play Console account.
- License testers have access to test payment methods that avoid
charging the testers real money for purchases. You can also use test
payment methods to simulate certain situations, such as when a payment
is declined. Figure 1 shows these test forms of payment as they appear
within the purchase flow.
- License testers can
rapidly test subscription features
.
Here are some additional details about the test purchase process:
- Test purchases use the same app purchase flow used by actual purchases.
- Taxes are not computed for test purchases.
- Google Play indicates a test purchase by displaying a notice across the
center of the purchase dialog.
You can confirm the account that is making a purchase by expanding the
purchase dialog. Note the following:
- Test accounts must be on the tester's Android device.
- If the device has more than one account, the purchase is made with
the account that downloaded the app.
- If none of the accounts have downloaded the app, the purchase is made
with the first account.
Before distributing your app, you can make use of Google Play
test tracks
to perform additional validation. For example, you can leverage test tracks
to have your QA team qualify a new release.
With test tracks, users can install your app from Google Play and test a
version of your app that is not yet publicly available. Users can make real
purchases using any of their payment methods in Google Play.
To test your Google Play Billing Library integration using test tracks, do
the following:
- Publish your app to a
test track
.
Note that after you publish an app to a testing track, it can take a few
hours for the app to be available for testers.
- Ensure each tester
opts-in to your app's test
.
On your test's opt-in URL, your testers see an explanation of what it
means to be a tester along with a link to opt-in.
You can test your integration 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
.
Test one-time products
Test consumable products
When testing consumable products, we recommend testing a variety of situations,
including the following:
- A successful purchase where the user receives an item. With a license tester,
you can use the
Test instrument, always approves
payment method.
- A purchase where the payment method failed to be charged, and the user should
not receive the item. With a license tester you can use
the
Test instrument, always declines
payment method.
- Ensure items can be purchased multiple times.
You should also verify that purchases are properly acknowledged as described in
processing purchases
. For
purchases from license testers, a purchase will be refunded after 3 minutes if
your app does not acknowledge the purchase and you will receive an email about
the cancellation. You can also check the
Orders
tab in the Google Play
Console to see if an order was refunded after 3 minutes.
Test non-consumable products
Non-consumables should be tested the same as consumables, but you should
verify an item cannot be purchased again within your app. Be sure to verify
purchase acknowledgement for both non-consumables and consumables (when
applicable) since the logic to process each the two types of purchases vary.
Test pending purchases
You should test a pending purchase where the item should be granted when
the purchase state becomes
PURCHASED
. License testers have access to two
test instruments for delayed forms of payment where the payment automatically
completes or cancels after a couple of minutes.
Make a purchase with a delayed form of payment "Slow test card,
declines after a few minutes", as shown in Figure 2. Restart the app,
validate that the purchase has not been granted.
Make a purchase with a delayed form of payment "Slow test card,
approves after a few minutes", as shown in Figure 3. Wait a few minutes,
validate that the purchase has been granted.
You can find more information at
Handling pending transactions
.
Test subscription-specific features
The purchase flows for one-time products and subscriptions are similar, but
subscriptions have additional scenarios, such as successful or declined
subscription renewals. To test renewals, you can use the
Test instrument, always approves
and
Test instrument, always declines
payment methods that are available for license testers, as shown in figure 1.
Use these payment instruments to test scenarios beyond the successful
subscription scenario.
Similar to one-time products, you should also verify that purchases are
properly acknowledged as described in
processing purchases
. For
purchases from license testers, a purchase will be refunded after 3 minutes if
your app does not acknowledge the purchase, and you will receive an email about
the cancellation. You can also check the Orders tab in Google Play Console to
see if an order was refunded after 3 minutes.
Renewal periods
Test subscriptions renew more quickly than actual subscriptions, and
test subscriptions can renew a maximum of six times, not counting free
trials and introductory periods.
The following table lists the testing renewal times for subscriptions of
various durations. These times are approximate. You may see 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 period
|
Test subscription renewal
|
1 week
|
5 minutes
|
1 month
|
5 minutes
|
3 months
|
10 minutes
|
6 months
|
15 minutes
|
1 year
|
30 minutes
|
Time-based subscription features such as free-trials are also shortened for
testing. The following table identifies the testing time periods
associated with time-based subscription features:
Feature
|
Test period
|
Purchase acknowledgement
|
5 minutes
|
Free trial
|
3 minutes
|
Introductory price period
|
Same as subscription test period
|
Grace period (both 3- and 7-day)
|
5 minutes
|
Account hold
|
10 minutes
|
Pause (1 month)
|
5 minutes
|
Pause (2 months)
|
10 minutes
|
Pause (3 months)
|
15 minutes
|
Price changes
You can also use license testers to test price changes. Keep the following
considerations in mind when planning test periods:
- Due to small renewal duration for license testers, it is possible that price
migration from console is not registered for license testers. To ensure that
price change notifications and emails can be tested, developers should defer
billing by 1 hour after triggering price change.
- Price decreases do not have a notification period. Soon after the cohort
migration, users are notified of the decrease. This is unchanged when
testing.
- For price increases, test notification times are calculated the same as with
actual increases:
- The user is first charged at the first billing anniversary following a
mandatory notification period.
- Notification times are calculated backward from the first charge date.
- The final notification is always 1 minute before the charge, regardless of
billing period.
The following table shows test billing and notification periods for several
actual billing periods:
Actual base plan billing period
|
Test billing period
|
Test notification period (opt-in and opt-out regions with 30 day
notice)
|
Test notification period (opt-out regions with 60 day
notice)
|
1 week
|
5 minutes
|
5 minutes
|
10 minutes
|
1 month
|
5 minutes
|
5 minutes
|
10 minutes
|
3 months
|
10 minutes
|
3 minutes
|
6 minutes
|
6 months
|
15 minutes
|
2 minutes
|
4 minutes
|
1 year
|
30 minutes
|
3 minutes
|
6 minutes
|
Test cases
Expand the following section by clicking
Show/Hide
to show testing
scenarios you should use to verify your subscription integration.
Monthly subscription
Time
|
User action
|
System event
|
Expected testing outcome
|
12:00 pm
|
Sign up for an in-app subscription using your licensed test account
and the payment method of "Test instrument, always approves"
|
Subscription started
|
|
12:05
| | Subscription renews
| |
12:10
| | Subscription renews
| |
12:15
| | Subscription renews
| |
12:20
| | Subscription renews
| |
12:25
| | Subscription renews
| |
12:30
| | Subscription renews
| |
12:35
|
|
Subscription ends (after 6 renewals)
|
User should lose access to in-app subscription content
|
Monthly subscription with free trial
Time
|
User action
|
System event
|
Expected testing outcome
|
12:00 pm
|
Sign up for an in-app subscription using your licensed test
account and the payment method of "Test instrument, always
approves"
|
Subscription starts with free trial
|
|
12:03
| | Subscription renews
| |
12:08
| | Subscription renews
| |
12:13
| | Subscription renews
| |
12:18
| | Subscription renews
| |
12:23
| | Subscription renews
| |
12:28
| | Subscription renews
| |
12:33
|
|
Subscription ends (after 6 renewals)
|
User should lose access to in-app subscription content
|
Yearly subscription with intro price
Time
|
User action
|
System event
|
Expected testing outcome
|
12:00 pm
|
Sign up for an in-app subscription using your licensed test
account and the payment method of "Test instrument, always
approves"
|
Subscription started at intro price
|
|
12:30
|
|
Subscription renews at regular price
|
|
1:00
| | Subscription renews
| |
1:30
| | Subscription renews
| |
2:00
| | Subscription renews
| |
2:30
| | Subscription renews
| |
3:00
| | Subscription renews
| |
3:30
|
|
Subscription ends (after 6 renewals)
|
User should lose access to in-app subscription content
|
Monthly subscription with grace period; user recovers
Time
|
User action
|
System event
|
12:00 pm
|
Sign up for an in-app subscription using your licensed test
account and the payment method of "Test instrument always
approves"
|
Subscription started
|
12:01
|
Go to the Google Play app,
Account > Subscriptions
, click
your test subscription, and change payment method to "Test
instrument, always declines"
|
|
12:05
|
Subscription payment declines and user enters grace period
|
|
12:08
|
Go to the
Account > Subscriptions
section of the Google
Play app, click your test subscription, and change payment method
to "Test instrument, always approves"
|
Subscription recovered and exit grace period
|
12:10
| | Subscription renews
|
12:15
| | Subscription renews
|
12:20
| | Subscription renews
|
12:25
| | Subscription renews
|
12:30
| | Subscription renews
|
12:35
| | Subscription renews
|
12:40
|
|
Subscription ends (after 6 renewals)
|
Monthly subscription with grace period and account hold; user involuntarily churns
Time
|
User action
|
System event
|
Expected testing outcome
|
12:00 pm
|
Sign up for an in-app subscription using your licensed test
account and the payment method of "Test instrument always
approves"
|
Subscription started
|
|
12:01
|
Go to the
Account > Subscriptions
section of the Google
Play app, click your test subscription, and change payment method
to "Test instrument, always declines"
|
|
|
12:05
|
|
Payment declined; enter grace period
|
|
12:10
|
|
Exit grace period; enter account hold
|
User should lose access to in-app subscription content
|
12:20
|
|
Subscription is canceled due to involuntary churn
|
|
Yearly subscription with grace period and account hold; user
recovers during account hold
Time
|
User action
|
System event
|
Expected testing outcome
|
12:00 pm
|
Sign up for an in-app subscription using your licensed test
account and the payment method of "Test instrument always
approves"
|
Subscription started
|
|
12:01
|
Go to the
Account > Subscriptions
section of the Google
Play app, click your test subscription, and change payment method
to "Test instrument, always declines"
|
|
|
12:30
|
|
Payment declined; enter grace period
|
|
12:35
|
|
Exit grace period; enter account hold
|
User should lose access to in-app subscription content
|
12:45
|
Go to the
Account > Subscriptions
section of the Google
Play app, click your test subscription, and change payment method
to "Test instrument, always approves"
|
Subscription is recovered, renews, and exits account hold
|
User should regain access to in-app subscription content
|
1:15
| | Subscription renews
| |
1:45
| | Subscription renews
| |
2:15
| | Subscription renews
| |
2:45
| | Subscription renews
| |
3:15
| | Subscription renews
| |
3:45
| | Subscription ends (after 6 renewals)
|
Yearly subscription with grace period and account hold; user involuntarily churns
Time
|
User action
|
System event
|
Expected testing outcome
|
12:00 pm
|
Sign up for an in-app subscription using your licensed test
account and the payment method of "Test instrument always
approves"
|
Subscription started
|
|
12:01
|
Go to the
Account > Subscriptions
section of the Google
Play app, click your test subscription, and change payment method
to "Test instrument, always declines"
|
|
|
12:30
|
|
Payment declined; enter grace period
|
|
12:35
|
|
Exit grace period; enter account hold
|
User should lose access to in-app subscription content
|
12:45
|
|
Subscription is canceled due to involuntary churn
|
|
Monthly subscription with account hold and no grace period; user
recovers
Time
|
User action
|
System event
|
Expected testing outcome
|
12:00 pm
|
Sign up for an in-app subscription using your licensed test
account and the payment method of "Test instrument always
approves"
|
Subscription started
|
|
12:01
|
Go to the
Account > Subscriptions
section of the Google
Play app, click your test subscription, and change payment method
to "Test instrument, always declines"
|
|
|
12:05
|
|
Payment declined; enter account hold
|
User should lose access to in-app subscription content
|
12:15
|
Go to the
Account > Subscriptions
section of the Google
Play app, click your test subscription, and change payment method
to "Test instrument, always approves"
|
Subscription is recovered, renews, and exits account hold
|
User should regain access to in-app subscription content
|
12:20
| | Subscription renews
| |
12:25
| | Subscription renews
| |
12:30
| | Subscription renews
| |
12:35
| | Subscription renews
| |
12:40
| | Subscription renews
| |
12:45
| | Subscription ends (after 6 renewals)
|
Monthly subscription with account hold and no grace period; user involuntarily churns
Time
|
User action
|
System event
|
Expected testing outcome
|
12:00 pm
|
Sign up for an in-app subscription using your licensed test
account and the payment method of "Test instrument always
approves"
|
Subscription started
|
|
12:01
|
Go to the
Account > Subscriptions
section of the Google
Play app, click your test subscription, and change payment method
to "Test instrument, always declines"
|
|
|
12:05
|
|
Payment declined; enter account hold
|
User should lose access to in-app subscription content
|
12:15
|
|
Subscription is canceled due to involuntary churn
|
|
You can use the Google Play Console to
create codes for your own testing
.
Keep in mind that you may only create 500 promo codes per quarter across
all managed products in an app.
You should test the following promo code redemption scenarios:
- When the promo code is entered in the purchase dialog that was launched
within your app.
- When the promo code is redeemed in the Google Play Store app.
- When the promo code is redeemed at
https://play.google.com/store
using the
Redeem
button in the left-hand navigation.
Within these scenarios, you should test redeeming codes in as many ways as
possible. We recommend perform the following tests at a minimum:
- Redemption before the app is installed.
- Redemption while the app is running in the foreground. Note that for this
test, you need another device to test using the Google Play Store app.
Be sure to test redemptions from different screens in your app.
- Redemption with
multi-window mode
, where
both your app and the Google Play Store app are being displayed at the
same time.
For each test, make sure that the item is correctly detected and that
the user is notified.
Test the purchase experience in different regions
License testers also allow you to test the purchase flow in any region without
needing a real payment method for that country. Use the following steps to test:
- Create a new Gmail account. The account can be created in any country.
- Set up the user as a license tester.
- VPN into the desired country to test.
- Launch the purchase flow.
You can clear Play Store data and cache and then repeat steps #3 and #4 with any
country you would like to test. After switching to a new country you will need
to Clear Data for the Google Play Store to remove data related to the previous
country.
This method to test purchases allows you to test offer regional eligibility and
the user experience in any region, regardless of where you are physically testing.