Testing Android in-app billing v3.0

Hey guys,

As you know Google’s using the In-app Billing API version 3.0 (which was released in February 2013) as the current API for In-app billing integration for the Play Store. Google has stopped support for version 2.0 of the In-app Billing API on 27January 2015.

Here a quick look at the major changes between these two version and how you can perform developer and QA testing for in-app billing for your Android apps using the new API.

Testing Android In-app Billing using API version 3.0

Perhaps the biggest change in version 3.0 of the Android In-app Billing API is that there are no more unmanaged products (in-app items available for purchase). All in-app items (products) are now managed, so that all transactional data is available via Google. Even those in-app items that were previously unmanaged in version 2.0 of the Android In-app Billing API,are now being treated as managed.

There were basically two differences between unmanaged and managed in-app items:

• In managed products (in-app items), the Google Play Store maintains all the transactional data, while for unmanaged in-app items, the Play Store is only responsible for the financial transactions only, that take place on these in-app items.
• Managed products (in-app items) cannot be purchased more than once.

In order to overcome the limitation of purchasing a managed product (in-app item) more than once, the Android In-app Billing API version 3.0 provides a mechanism for consuming an in-app purchase. So that once consumed, a managed product (in-app item) can be purchased again and again

Although there are many help resources and detailed guides available for the implementation of the latest android In-app Billing API, there’s not much info available on the key changes that have taken place in the testing flow for in-app billing (purchasing). Let’s take look at these below.

As you know, In-app purchasing (billing) cannot be tested using an emulator and must be tested manually, via developer testing and QA testing. Here’s how you can test in-app billing (purchasing) at these two levels.

Testing Android in-app billing – Developer Testing

For developer testing of in-app billing in Android In-app Billing API version 3.0 you will need:

1. The tester’s Google Wallet account associated with their Gmail and Google Play Developer account. This Google Play Wallet account must contain a valid credit card

2. In addition to a valid Google Play Wallet account, you will also need to perform the following steps on your app’s Play Store publishing page:

• Upload a signed APK on the Alpha or Beta testing tab on your app’s APK screen.

• Add the Gmail account of the developer who will be performing the testing of in-app billing on your app (this Gmail account must be different from your publisher account, under Settings > Account Details (as shown below)

3. Next, on your testing Android device, you will need do the following:

• Add the tester’s Gmail account under setting > Accounts > Add Account > Google
• Sign the APK you wish to test, as a release and install it on the device, since you cannot test in-app billing using a debug builds.

Don’t worry about getting charged for in-pp purchases on your credit card during testing though, since the credit card you added to your Google Wallet account will not be charged at all.

Although the APK uploaded on the Google Play Store and the one installed on your testing device need not be the same (you can use different builds), the singing key-store as well as both the version name and version code on both these builds must be the same.

Testing Android in-app billing – QA Testing

For QA testing of in-app billing in the Android In-app Billing API version 3.0 you will need the following:

1. The QA tester’s Google Wallet account associated with their Gmail account. The Wallet account must contain a valid credit card

2. Create a Google Group

3. Add the QA tester’s Gmail account to the newly created Google group (from step 2 above).

4. In addition to the above, you will also need to perform the following steps on your app’s Play Store publishing page:

• Upload signed APK on Alpha or Beta testing tab on your app’s APK screen (as shown below)

• Publish your app
• Add the Google Group you just created in list of alpha testers (as shown below)

• Add your Google Group and get Alpha test subscription link (as shown in the screenshot below)

• Share the Alpha or Beta test subscription link on your Google Group
• When you do that, the QA tester will be redirected to the Alpha testing subscription page when he/she clicks on the link
• The QA engineer can then download Alpha or Beta build directly from Google Play Store, by clicking on the download link (as shown below)

And that’s it!

The only catch in this whole developer-testing scenario is that you cannot debug your app directly from IDE, as you need a build signed as a release version. However you can debug a build that’s running on your testing device, by following these instructions for both Eclipse and Android Studio users

Lastly, if you have enabled proguard, you will need to disable it prior to conducting testing, as it will obfuscate your code and make it incomprehensible in logcat logs.

Explore our blog

About Folio3

As a leading mobile app development company (iPhone, Android, Windows Phone, HTML5 app development), Folio3 specializes in native app development services and cross platform mobile app development services for the iPhone and iPad. We also offer extensive mobile app testing and QA services. If you have a mobile app idea that you’d like to discuss please or would like to know more about our iPhone app development services, please Contact Us. Learn more about our iPhone, Android and Windows Phone app development services

Blog Post