Everything You Need to Know About Google Play’s In-App Billing
Being a smartphone user yourself, you might have noticed how hard it could be sometimes to convince yourself to press the “Get” button for a paid application. Of course, from a developer’s perspective, selling an app for upfront cash may seem a fantastic idea (taking into account the amount of money and effort invested). In fact, paid apps, even those having this teeny-tiny price tag of $0.99, can be a real mental barrier for a great majority of mobile users. But how can you start to make a profit on your product without putting a price tag on it? And how to persuade your customers to spend money on your app? Think of a compelling monetization strategy with in-app purchases.
Just think, recent research carried out by Gartner found that mobile app users now spend 24% more on in-app transactions than on upfront payments. So today, we are going to find out everything about in-app purchases and In-app Billing service provided by Google Play. As you can see, the focus today is on the Android platform!
In-app billing and its capabilities
Well, it wasn’t hard to guess that In-app Billing is a special service that enables Android developers to sell digital goods from inside the application. We are laying stress on digital goods because they are the only concern of In-app Billing. In case you want to sell and deliver products like clothes, shoes, food, and other stuff related to the physical world, you’re certain to need the help of third-party payment gateway providers (think PayPal, Braintree, Stripe, and others). However, if physical goods are not in your interest, then In-app Billing may be a solution for you.
Making some of the app’s features free, you can show your users what your product is capable of. Once they are hooked, they will want more. Thus, you can try selling levels, clothes, ammunition, superpowers, and so on, and so forth, to accelerate the game flow or improve user’s experience in a game. When people are extremely involved in a fascinating game, they tend to spend huge money.
But what about non-gamers? Here, the same rule actually applies. For example, you’ve developed a photo editor, and it provides a set of basic filters and tools to retouch photos. They are usually enough to get the desired result. But you can be cunning and suggest a set of paid filters in case your user wants to go further with their editing. Thus, if your editor has proved to be really good at what it does, it’s quite possible that users will buy other, paid tools.
In-app billing from a developer’s point of view
As far as we’ve touched upon digital goods, it would be appropriate to shed some light on the types of products supported by In-app Billing. So you can sell:
- managed in-app products, which imply one-time billing
- subscriptions, which imply recurring billing
Managed in-app products
Actually, standard products are also called managed in-app products. That’s because Google Play tracks and manages their ownership information. It means that Google Play keeps count of all acquisitions made by a certain user and collects their purchase information on its server.
It’s also worth mentioning that managed in-app products can be either consumable or non-consumable. Consumable products can be bought multiple times, while non-consumable, if were purchased, stay with a user for good. In other words, these are permanently associated with the user’s Google Play account, and their owner will get a constant benefit from them. Level packs, premium updates for a game, or a set of paid filters for a photo editor, can serve as the examples of such non-consumable goods.
Since consumable products can be bought numerous times, their state can be either owned or unowned. So a user cannot buy an item again as long as it’s owned. To change its state, you need to send the consumption request to Google Play. After that, the service will discard the previous information on an item, and it becomes unowned. It means that now it’s available to be purchased again.
Consumable in-app goods are typically used in games. The examples of such items are pieces of clothing, weapons, potions, and other disposable stuff which gives its user a temporary advantage.
Of course, all the actions listed above will be performed automatically, so don’t be scared. As wealready said, the selling of digital goods is the In-app Billing’s concern. And these weren’t just empty words. The thing is, Google Play Store handles all the checkout operations without you having to take part in it. And yes, In-app Billing works for all applications distributed through Google Play Store. So you will need several things: Google Play Developer Console and Google Wallet Merchant Account. That’s it!
P.S. Google Developer Console is a place where you can publish and configure your subscriptions whereas Merchant Account is kind of store accumulating your money.
Subscriptions
Subscriptions are another product that you can sell within your app. The only difference is that digital content or functionality here is sold with automated, recurring billing.
This monetization strategy is very similar to one known as Freemium (Free to Premium). Let me refresh your memory. “Try first, then buy” — this is the key principle followed by the Freemium concept. The app is free to download and offers some basic features but locks out premium features, which need to be purchased to extend the app’s functionality.
The subscription model allows users to access certain content or use your app’s functionality to its fullest for a limited period of time. After this time runs out, they will be asked to renew via a subscription. This type of monetization has evidently gained popularity over the years. See for yourself.
Going back to mid 2014, research conducted by Branchfire, that studied mobile device owners’ app-buying habits, showed that more than a third of app users (37% to be precise) subscribe to monthly subscription-based apps. It’s no wonder that in mid-2015, subscription was the fifth most-used model to monetize mobile apps, according to 14 percent of developers. That’s enough to compete with consumable in-app purchases (16% of those surveyed) and more than non-consumable in-app purchases (12%), according to Statista. What about today?
The prosperity of subscriptions promoted by such services as Netflix, Entrepreneur Magazine, Spotify, etc. has encouraged Apple and Google to make changes to the selling of subscription apps in the Apple App and Google Play Stores. In particular, Google plans to increase the amount of money developers can make. So, to make things work, configure and publish subscriptions using a Developer Console and then sell them from within an application running on Android OS.
Which method to choose for your Android app?
Let’s see when and where in-app purchase strategy will feel appropriate.
Besides different games and photo editors, in-app purchases also can be successfully used when your future product is about selling digital content like e-books, videos, and pictures. You can either charge users for downloading one issue/item or ask them to buy a subscription which allows getting access to a premium content on a monthly or annual basis.
By the way, subscriptions can be used almost everywhere, from task managers like Trello to entertaining apps. So if you think you have some interesting and suitable stuff to share with an audience, you can launch your own official portal with free and paid content. Keep in mind that people shouldn’t feel uncomfortable when they intend to make purchase within your app. Try to present products and handle transactions in a way that feels natural in your app and doesn’t damage the UX.
As you see, in-app purchases can serve any sorts of apps. However, the question remains: How difficult is it to implement in-app purchases in your apps? To provide you with a proper answer, we turned to our experienced Android developer who has led us through the technical details and important things you should pay attention to.
The technical details
The application accesses Google Play’s server using an API exposed by the Google Play App installed on a user’s mobile device. The Google Play App processes and conveys all billing details between the app and the Google Play server, so they never communicate directly. In fact, your application sends payment requests to the Google Play App over the interprocess communication, IPC, and then gets back responses on their state from it. To carry out the in-app purchase request, the GP app needs to be connected to the GP server through the network.
You can use the server-side API in addition to the client-side API to provide you users with extended access to content, for example, buying subscriptions from your website. The server-side in-app billing API helps you define the status of a subscription when a user is signed into your another service.
Google has switched to the Version 3 of the In-App Billing recently, so now the service has much more capabilities than earlier. Version 3 is available for the devices running Android 2.2 and higher which have the latest version of Google Play app installed on them.
P.S. If you are in need of a more technical explanation of all In-app Billing inner processes, you can always visit Google’s site for developers. There you will find the fullest instruction on where and how to use the server-side and client-side APIs, and read about the newest features and advantages of the In-App Billing API Version 3 over its earlier versions. Moreover, you can grab a sample application provided by the company and check yourself how In-app Billing is performed. Hands-on experience is always a great thing!
Victor P., Android developer at Cleveroad comments: “There are things that can be missed during development, that can lead to serious consequences. One of these things is the security of transactions. There is always a chance that your money can be charged to a third-party account, because of traffic interception or substitution. To prevent this from happening, set the ‘developer payload’ string with supplemental information about the purchase (it can be a subscription payment as well). This verifies the identity of the purchase initiator, based on the user ID, before declaring the transaction executed. This security precaution may help to prevent fraud. You can read more about developer payload and Man-in-the-middle security attacks, to get the deeper insight.”
One more tip, just in case…
One can say that in-app purchases are yet another sneaky trick to clean a user out. In order to avoid this, we recommend that you do not overload your product with paid features. The IT industry has seen applications where it was impossible to make a move without having to pay for something (I hope the creators of Family Guy: The Quest for Stuff will forgive me this). This mistake can cause your users to become angry and increase your uninstall rate, which, let’s agree, won’t make you richer.
So you might have already guessed what we’re driving at. Give users some space to realize that your application is a powerful tool capable of solving any of their problems, and they will stay with you forever. As for the rest,we wish you good luck, and may your application be the next breakthrough on the market!
This article was originally published on Mobile Masters Magazine.
