Overview

Monetization is one of the most important aspects of distributing your product to the rest of the world. It can make or break a small freelance developer or an established startup.

Android, being so widespread, provides ways for users to purchase products from within your app: this is referred to as In-app Billing. Through this set of APIs, developers can offer two types of products:

Managed in-app products

As the name suggests, these products are managed by the developer, and they branch into consumable and non-consumable. A consumable product is usually temporary and, once consumed, can be bought again, whereas a non-consumable product is a one-off benefit that the user will continue having in your app.

As the name suggests, these products are managed by the developer, and they branch into consumable and non-consumable. A consumable product is usually temporary and, once consumed, can be bought again, whereas a non-consumable product is a one-off benefit that the user will continue having in your app. Subscriptions

These products come with a validity period (days, months, weeks, years) and are automatically renewed at the end of each billing cycle. When a subscription is not renewed, the product is no longer active for the user.

The official documentation is very helpful when it comes to the first steps for adding in-app products to your application. In particular, the “Selling In-App Products” training is well structured and walks you through each required step:

Adding the Play Billing Library to your app (also check out this article by Joe Birch) Configuring the products in the Google Play Console Testing the in-app products in your app

Let’s focus on the third point.

Testing, according to the documentation

According to the documentation for testing, we have two ways of testing purchases:

Static responses from Google Play

By using a restricted set of product IDs, you can trigger static responses from Google Play, so you can test that your app correctly handles all the possible states. You should use this when integrating the Play Billing Library into our app, or for instrumentation testing.

By using a restricted set of product IDs, you can trigger static responses from Google Play, so you can test that your app correctly handles all the possible states. You should use this when integrating the Play Billing Library into our app, or for instrumentation testing. Test purchases

A Google account whitelisted as license-test in the Play Console will be able to make purchases without being actually charged. You can use this when the app goes to QA, or for general testing.

Static responses

Using static responses sounds easy enough, right? You just use one on the following product IDs during a purchase operation:

android.test.purchased

android.test.canceled

android.test.refunded

android.test.item_unavailable

and the Play Store will reply accordingly. The code looks roughly like this:

mService.getBuyIntent(3, "com.example.myapp", "android.test.purchased", PRODUCT_TYPE, developerPayload);

However, if you are testing subscriptions, you’re out of luck:

Note: If you’re testing subscription purchases, you must use the product ID of an actual subscription, not a reserved product ID. [Reference]

This means that we cannot rely on static responses to test subscriptions; instead, we need to resort to test purchases.

Test purchases

By using the so-called In-app Billing Sandbox, we can enable access to test purchases. These are the closest thing we have to actual purchases, with a few notable exceptions:

You are not being charged any amount for the product you buy

If you’re buying a subscription, the billing period recurs on a daily basis, regardless of the duration configured in the Play Console

You have manual control over the response for each purchase

The last point is particularly interesting, because we have two ways of customizing the test purchase behavior.

The first method allows for fine control over the licensing behavior for all the testers: for example, by leaving it to RESPOND_NORMALLY we have a behavior similar to the real one.

The second method, on the other hand, allows for coarse control over the response of the fake credit card: you can decide whether the card will always approve the purchase or always decline it. Intuitively enough, this second method can be customized by each tester.