What to do if you have every intention of releasing an extremely cool application for free but don't want to be left without nothing? 'Nothing' is this case means being completely skint. To avoid this unpleasant situation, there are some tricks invented to help you not to discourage consumers from using your app and earn a bit of money at the same time. So meet in-app purchases and an exhaustive instruction on how to integrate them with your mobile application. Today the Android platform is in focus!
Why You Need In-App Purchases in Your Android App
What are in-app purchases?
The in-app purchase or in-app billing, as it's known in the Android development circles, is one of monetization strategies employed in free or partially free applications. But what's the purpose of it?! In-app billing is for selling digital goods from within your mobile application and getting rewarded for the work done in a purer (perhaps, less obvious) way. These goods are usually called in-app products, and there is a number of them. Roughly speaking, there are four categories in-app products can fall into:
Example #1: Imagine you're building a mobile game in this case, you may redeem in-app currency, ammunition, levels, potions, and other gaming stuff, for money to accelerate the game flow or to improve user's in-app abilities.
Example #2: If you're ideating your first photo or video editor, you can then charge consumers to unlock some extra functionality, such as photo filters, fonts, and other tools.
Example #3: Or you can sell subscriptions to people to get more of digital content as it happens in the case of magazines or newspapers. Actually, subscriptions are suitable for all kinds of applications, from primitive planners to complex health and fitness applications.
All these tricks can make you not to lose your shirt when releasing the app free to download. However, you should be careful not to overload your product with in-app purchases. Otherwise, it will resemble a leech :) Doing so you can incite discontent among users, which can lead to your product's removing from their devices. Sounds terrible... But we are here to find the wisest of all possible solutions, right? So now let's not waste our time and find out more of the wiles of In-App Billing.
In-app billing in details
As we've already said, In-app Billing supports different types of products to give a developer plenty of opportunities in how to monetize his or her app. All you need to do is specify your in-app good type in the Google Play Developer Console. For you to know, they could be either managed in-app products (such as the first two examples above) or subscriptions. Let's see what it means.
Managed in-app products
So, managed in-app products are called 'managed' because their ownership information is:
- tracked by Google Play
- managed by Google Play
When a user buys a managed in-app item, Google Play stores the purchase info for it on a per-user basis. Thus, you can call Google Play anytime you need to update the state of the items bought by a certain user. This information stays on Google Play's server even if the user uninstalls the application or changes devices.
You can also consume items within an app. This is typically made for items which can be bought multiple times (think in-app currency, pieces of clothing, spells, potions, etc.). A user cannot purchase an item again as long as it is consumed. So once a user buys some item, it's considered to be 'owned'. In order to change the item's state to 'unowned', you need to send the so-called consumption request to Google Play. In this case, the service discards all previous data on a purchase and tags it as available to buy again.
See also: How to Monetize Your App, Vol. 1
Remember! One application cannot purchase in-app goods published for another app, even though these apps are distributed by one vendor. In-app products are always associated with one application. And the ONLY ONE!
What can we say about in-app item formats? Well, as you might have assumed from the abovementioned, in-app products can be consumable. But you can also opt for non-consumable goods. Everything depends on the product design and your intention. You might want to get any examples? Here they are :)
The best examples of non-consumable in-app products are level packs, premium upgrades, and different tools, like filters, fonts, brushes, etc.. Once you buy them, they stay with you till the end of times (or application, who knows). After being purchased, these items will be permanently associated with a user's Google Play account providing a permanent benefit to it's owner. On the other hand, in-app items like magic spells, coins, potions, and other disposable stuff associated with games and nerding, can be bought not only once. Note that, as a developer, you should control and track how your in-app products are provisioned to users. You already familiar with the rest of the story where the consumption request to Google Play is engaged, so let's continue with the following part.
Examples: Angry Birds, Candy Crush Saga, Crossy Road, Zombie vs. Zombies, Contest of Champions by Marvel, etc.
Whew, at this point, we are coming up to subscriptions. Finally!
The only difference about subscriptions is that content or functionality here is sold with automated, recurring annual or monthly billing. Actually, there is a variety of intervals, so you decide. It means that the subscription bought by a user can be renewed later after it's expiration due date.
We have already mentioned that you can sell subscriptions to any kind of digital content, from any type of application including games.
Remember! Subscriptions can be sold only within the application, not from Google Play Store directly.
Oh, and one more thing subscriptions cannot be consumable!
Handle users' subscriptions
You can configure and publish subscriptions using the Developer Console and then sell them from within an application running on Android OS. That's easy, what you need to do is:
- create subscription products
- add these products to the product list
- set a price and trial period for each of them
- choose a billing interval
Examples: Trello, LinkedIn, Evernote, Strava Running and Cycling, Eat This Much, etc.
No matter which of the listed above you want to sell on your application using the in-app billing service, Google Play Store will manage all checkout details thoroughly. It means that your app doesn't have to process any financial transaction on it's own. The checkout processing looks and feels exactly like the one used for app purchases, so your users will be familiar with this flow.
Remember! In-app billing only works for the applications distributed through Google Play Store. In this case, no special account and registration are needed but the Google Play Developer Console account and Google Wallet merchant account.
Mind you, the selling of digital products shouldn't be confused with the selling of physical goods and services, because the latter is not the Google Play Store's responsibility. Here come third-party services and payment gateway integration, so be careful!
Congrats on getting to the final part of this read. Now we will try to explain how the in-app purchases feature can be embedded into your app. Don't panic! It won't take long -- we are not going deep into techie details.
The application accesses Google Play 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.
And, as always, Google makes a developer's life much easier by providing him or her with the Sample Application which demonstrates how the In-App Billing works within the app. The sample shows how to send in-app billing requests and manage synchronous responses from Google Play, how to record item consumption via API, and so on and so forth. So check this out here.
Now it's time for a tiny revision. Are you ready? Then let's do it!
First, In-App Billing is a monetization strategy used by Android applications adopted the freemium model. The idea is to sell digital goods from within the application to satisfy different needs of a consumer, such as the enhanced user experience or faster game flow, and get rewarded in a less obvious and purer way than selling an app for upfront money.
The important thing is not to overload an application with paid features because it can lead to the mass application's removal from devices and awful feedback. You need to remember that the application should be a source of joy, first of all. Users should have a nicely working application with an opportunity to improve it in the future, but you don't need to force them to purchase something on every corner.
Google takes care of your brainchild from the very beginning, so you can use Google Play's APIs and SDKs to integrate the in-app billing feature with your application, which, in turn, gives a natural user experience and lets you relax a little bit.
We hope it was very informative and fun. If you think so, please subscribe to our daily posts and youtube channel we won't let our audience down and provide you with the hottest info and hottest news in the field of IT. In case we've piqued your curiosity about something, don't be shy to contact our managers. It was nice to see you. Adieu!