Case Study: In-App Purchase Programming in iOS and Android

In-App Purchases is a simple and convenient mechanism for selling additional features directly from application. Usually apps sell content (magazines, photos, artwork, etc), app functionality (multiplayer mode in a game or remove ads, etc) or services (voice transcription, etc). This article will disclose the opportunities of implementation purchases in-app (into-application) for iOS and Android devices.

There are some limitations at app review and it can be rejected if your app:

• unblock additional functionality without IAP;
• purchase content, functionality, or services without IAP;
• purchase physical goods with IAP;
• purchase services used outside of the App with IAP;
• provide subscriptions less than 7 days;
• purchase access to built-in capabilities provided by OS (camera, gyroscope, Pencil, Keyboard, etc).
  

You can find more restrictions here.

For selling with In-App Purchases you need to create product and select its type among these three:

• consumable (used one time, after which they become depleted and need to be purchased again)
• non-Consumable (purchased once by users and do not expire or decrease in usage)
• subscription (auto-renewable, free or non-renewing)

Testing In-App Purchases is easy, but you need to be aware of specifics:

• you can test it only on device
• before testing you should sign out from iTunes on your iPhone/iPad
• you can test only with sandbox accounts
• while testing you will see [Environment: sandbox] - that means that your are in the test mode.

In-app purchases is Android

Android platform is not an exception in mobile world and provides remarkable user experience for making In-App Purchases. Users can easily buy so called digital content, subscribe for the service that would be delivered, for instance, every month. The best part of it is, that all the features can be done within few clicks.

There are the following types of the products in android - managed products and subscriptions. Managed products can be bought once and the info about the buying will be persisted in the account, which the purchase was made with. The product, that was bought, will be restored on all  devices, which the user will log in. Also the managed product can be consumed - we can apply one time product (game points or anything alike) a lot of times with the same effect. Consuming of the managed product has the same sense as consumable in-app purchase ios. Subscriptions can be considered as recurring or automated billing.

If we take a look at the purchase process from the development perspective, implementation of the in-app purchases in android os, we will face it as a good example of “consuming” Google Play Services. Google Play Services perform all complicated parts of the purchasing flow under the hood, developers only need to use the API that is exposed. Google Play Services billing API takes responsibility for payment transaction processing, makes it secure and reliable, cashes the needed info on the device. Developers only need to call the APIs in the right order:

• check if billing is supported. Check the consistency of the billing API that is intended to use with the one that is installed on the device.
• then it is good to retrieve the info about previous purchases that were done by the user. This will let us show an appropriate ui with available products and perform corresponding actions in the application.
• get the product details using the sku - a unique value that identifies the product. About how to create a product will be described below.
• get so-called buy intent and start using it. This is a start point. The application will notify the progress using onActivityResult callback method. And that is it.
  Also please take a note if your application requests the billing permission ("com.android.vending.BILLING").

Here you can find the sample project in the following repo to see the way iap can be implemented in android.

Let’s also pay attention to the developer console configuration. All the products should be created for the corresponding application in Google Play Developer’s Console. The product can be created only after the first version of the app was uploaded to alpha or beta channel. Creating a product you have to specify the unique id of the product (product sku), product’s description and price. The only thing that will be used in the application is the sku. It is a good practice to start the sku name from the package identifier and then proceed with the product specific info.

After you added skus to the application and uploaded a new version of the app to alpha or beta channel you can start testing. Remember, that sometimes it takes about 2 or 3 hours to have the app uploaded.


Testing of the in app purchases in android has lots of specifics. The easiest way for the developer to test the purchase flow in the app is to use the static responses. Google offers predefined product sku to test different scenarios in your application:

• android.test.refunded;
• android.test.refunded;
• android.test.item_unavailable;
• android.test.purchased.

It is not hard to get that result is generated by using each of the test sku. So, it might be a big help for developer, as it easy to cover these use cases in the application. The thing we’ve experienced is that it is impossible to consume android.test.purchased product. It is an issue and causes some problems when you have to test consumption flow.

On the other hand, Google offers testing via alpha or beta channel. You have to define the list of test accounts which can test the app. After that, they will have an access to the latest app’s distribution. While testing in-app purchases test accounts will not be charged for buying a product, but will have the same user experience. Sounds great!

Finally, in app purchases is a great instrument if you want to monetize your application. 30% of the products’ price goes to Google. As for me, it’s reasonable - you receive solid secure and reliable API to work with.

Read more about TechMagic researches here:

• ECase study: Augmented Reality – the next tech big thing
• ECase study: Playing video in your iOS application
• ER&D project: GPS tracking app. Experiments in Android