Search [Enter] to search. Click anywhere to close.

January 5th, 2022

Testing In App Purchases (IAPs) In Android Apps Locally

In this article, we’ll go over the steps required to test in app purchases in your Android application.

This article isn’t about actually implementing the billing functionality itself. It’s only about (effectively) testing the in app purchases via your own implementation.

The information with regards to testing in app purchases within your local environment (whilst attached to your development machine) is out there — but unfortunately, it doesn’t appear to be consolidated into one easy to read, clear document.

As such, testing in app purchases can be fairly frustrating for newcomers! A sandbox-like environment where it’s easy to debug and easy to apply trial and error is most definitely a must.

Hence the requirement for this article in particular.

And with that, let’s get started!

1. Add the relevant billing permission to your app

First and foremost, you’ll need to add the required billing permission to your app’s AndroidManifest.xml:

<uses-permission android:name="" />

Without this, as you may have guessed, none of the billing functionality will actually work in any regard within your application.

2. Make sure you’re using the same signing config for your debug build as you are for your release build

There are numerous StackOverflow posts that mention this point, but they don’t specifically mention what to do. It’s probably obvious to experienced Android devs, but many of us are web developers (hi 🙂) using React Native!

Here’s what you need to do:

In android/app/build.gradle, make sure debugSignings matches releaseSignings under the signingConfigs configuration.

If these two signatures match, Google will consider the app you are running locally to be the same app as the release app (because it’s been signed with the same signature).

This step catches a lot of people out. Just remember, if the app has a different signature Google effectively treats it as a separate app. And you’ll find that the purchase flow in general will not work as required.

In short, the app you upload to the developer console in the next step must match the version you are testing locally in terms of its signature.

3. Build and upload the app to a closed testing track

Next, you must build and upload your app to the Play developer console.

Build your app with whatever mechanism you are using, for instance:

./gradlew bundleRelease

Then select the resultant apk or package file and upload it to a new closed release track via the Play developer console.

You don’t need to actually fully rollout the release in order to test the in app purchases locally — the app itself simply needs to exist (be uploaded) and be approved.

A closed testing track I’ve named “Test Billing”

We won’t actually be accessing the app and downloading it from within the Play store during this initial testing phase. We want to test a version of it whilst attached to our development machine!

It just needs to have been correctly configured (step 1) and uploaded. Once we run the same app locally — everything will be in place on (Google’s side) for in app purchases to actually work and be testable.

So this step is very much about configuration with regards to the various moving parts involved within the Android purchase flow functionality in general.

4. Add yourself as a tester (optional)

When uploading your app to the developer console, you’ll notice an option to add one or more testers (by email).

Add the account you’d like to test on (most likely your own account, the one attached to your developer profile).

This is an optional step, it’s only really required if you want to download test versions of your app from the Google Play store. It’s not strictly required to do this during development at all.

As stated previously, we’re building and testing an app locally alongside our development environment, attached to our machine.

So feel free to skip this stage for now if you’d like.

5. Add yourself as a licence tester

You’ll need to be a licence tester, however.

A licence tester can test in-app purchases without actually being charged each time.

During your initial foray into in-app purchases, and when working with the flow of purchases throughout your app, you’ll find this to be extremely beneficial for obvious reasons.

Licence testers follower the regular purchase flow when attempting to make a purchase — only they’ll be able to select from one of four “fake” cards (Google test cards) instead of needing to specify a real payment method each time.

For your convenience, these test cards can be used to simulate the following outcomes:

  • The payment is approved instantly
  • The payment is declined instantly
  • The payment approves, but it’s a slow transaction (it takes a few minutes to resolve)
  • The payment declines, but it’s a slow transaction (again, it takes a few minutes to resolve)

Note: it may be the case that you want to repeatedly push through test payments to verify your application handles all of these scenarios correctly. For this reason, it’s a good idea to ensure the product you are testing can be purchased more than once!

More on that later.

So, add yourself as a licence tester via the Play console and let’s move on.

6. Create a test product and allow more than one purchase

Go to the Play developer console and create a new test product.

Ensure you can purchase more than one of this product.

A product called “Premium Mode” to be used with test transactions

This is important as you’ll likely want to repeatedly run through the purchase flow to verify the client (your app) responds and behaves as it should in each and every scenario.

If your product was a one-time purchase, after the initial transaction, you’d be blocked from any more purchases (and hence the manual testing would be brought to a standstill).

You can refund these orders and effectively restart the process, but that can take some time to go through.

You definitely don’t want this at the testing phase!

It may be the case that your actual product is literally only a one-time purchase (for instance — a “pro” or premium version of the standard app). That’s fine. But for testing purposes, I’d definitely recommend the multiple-purchase approach for the reasons outlined above.

7. Run the app locally

I typically use React Native, so that looks like something like:

npx react-native run-android

Once you’ve got this app up on your device (note: a lot of this stuff will not work on an emulator, use a real device for testing!) you should be able to start testing the in app purchases as required.

Ensure you’ve completed the necessary configuration(s) as per the previous steps!

8. Actually test the purchase flow

So now, all going well, you should be able to run through the full purchase flow within your app, from start to finish. Hooray!

You should see the Google payment prompt pop up when attempting to purchase the test product. Then you should be greeted with the 4 Google test card options.

Note, if you were not a licence tester at this stage (we configured that in step 5) you’d see real payment options here, instead. Although you’re running the app locally, you’d still get charged for these transactions! The transactions are still very much passing through Google’s infrastructure at this point.

That said, it is advisable to actually do this too (make one or two real payments). Though it’s likely better to do that at the very end of your implementation for the sake of practicality.

To test real payments, as you can probably guess, you’d just need to remove yourself from the list of licence testers (via the Play developer console).

9. Revoking the purchase

After making a purchase, it’s a good idea to refund the purchase to ensure your app responds appropriately.

Refunding or revoking the purchase is a good thing to test as it allows you to ensure that this scenario is handled correctly and consistently within your app.

You can visit the Order Management screen inside the Play developer console to refund a specific purchase.

Ensure you actually revoke the user’s entitlement to the product, too.

Once the purchase has actually been refunded (it may take some time), you should be able to open up your app and check that the user has no features related to this product any more.

10. Restoring purchases

It’s likely that you’ll also need to implement purchase restoration in your app.

The purpose of this is to “re-fetch” purchases for a specific user. If the user has switched devices (but they are using the same Google account) for instance, they’ll likely need to restore their previous purchases within your app.

A good way to test this is to run your app as described above. Make a successful purchase and then verify that you actually own the product in question.

Then, uninstall the app.

Reinstall it and verify that you no longer have the product in question.

Hit the button to restore the purchases (provided you’ve implemented this functionality).

You should now own the product again if all is working correctly. Your previous purchase (before reinstall) should have been fetched, and the features should have been restored to the app as part of this process, too.

In summary

I hope this article has been of some benefit.

This is a very basic overview of setting up a testing sandbox to handle in app purchases in your Android app. I found these steps were sufficient for my needs when building out a simple app with a singular, one-time purchasable product.

We’ll likely go over the actual implementation of in app purchases in Android apps later on, so check back for that!

Thanks for reading!

Have any questions? Ping me over at @justacodingblog
← Back to blog