One of most common standpoints on application is to see it as a source of revenue. Any sensible developer who gets down to mobile application development is looking at least at ROI (return of investment) when choosing monetization strategy.
There are different revenue generating models you can turn to. In-app purchase is one of the models that can help you make money. Although we have mixed feelings about it. The secret’s out — it’s not easy to make money with apps. Having experimented with monetization on our own mobile products, we know how hard it is to choose the right source of revenue and sustain it.
In the majority of cases properly picked sales direction inside mobile applications has a monetary potential. As you can see on the graph, freemium model is the most profitable and therefore app developers tend to use it.
In this article, we are to talk a bit about how in-app purchases can be implemented into your iOS and Android mobile applications.
What IAP in mobile apps may look like
Freemium monetization includes various forms of in-app purchases, such as purchasing virtual goods like upgrades, speed-ups, in-app currency, buying additional functionality like levels, unique extra smileys or content, buying more time to use the app, paying to remove ads, or a combination of them all.
Content generating apps usually earn from subscription by charging fees for the regular delivered content or service from inside your application with recurring weekly, monthly or annual billing.
New York Times app, for instance, allows you to view a certain number of articles, but curious readers must subscribe to access the blocked rest of them.
The most common option according to the App Annie’s survey is offering additional application functionality for a price, which turns out to be a preferred method among developers, us included. What makes total sense is to launch two versions of the product — one freemium, the other one paid. The free version offers limited functionality with an option to go pro by purchasing additional functionality or a range of them. So if your product is new and users don’t have any idea whether it meets their expectations, they can download a free version, try it out and if the app’s worth it, purchase premium.
IAP on Google Play
In-app purchases of digital content in Android are managed by Google Play In-app Billing service thorough Google Play app’s API. In-app Billing service can be implemented only in applications that you publish through Google Play. Google Play app handles the connection between your Android application and the Google Play server. However, it isn’t in charge of your content delivery.
You are responsible for delivering the digital content that you sell in your Android applications. Also, even if you have multiple apps with in-app purchase, one and the same product cannot be published for another Android app.
As for financial transactions occurring in the app, it is up to Google Play to manage. The products for sale are defined in Google Play Developer Console.
To configure the list of products handled by the appstore, please consult the guide.
NOTE: You must have a Google Wallet merchant account to use the In-app Billing service on Google Play and purchase digital products in your Android applications.
The In-app Billing Version 3 API is the latest easy to implement version. It lets you manage in-app products and subscriptions on Android more effectively and includes improved synchronous purchase flow among other useful features.
What we can draw your attention to is that the Developer Console allows to set up a free trial period that lets Android users try your subscription content before buying it. After the trial period is over, it automatically converts to a full subscription managed according to the subscription’s billing interval and price.
NOTE: Once a user has purchased an in-app product or a subscription on Android device, there is no refund window. So users will need to contact you directly to request a refund.only through the standard payment processor, Google Wallet. We would recommend to duplicate the information about purchases on your server to make it harder for advanced users to crack your app.
IAP on App Store
iOS apps have similar In-App Purchase service as that of Android. In order to implement in-app purchase in iOS app you need to design an In-App Purchase store and embed it inside your app using Store Kit framework.
Store Kit communicates with App Store for secure payment processing and notifies your app when the transaction is made and the purchased items should be provided to users. Regarding the implementation see the programming guide.
NOTE: You must make your In-App Purchase items available to all of the devices registered to a user.
Items offered via In-App Purchase fall within 5 types:
Consumables — purchased every time the user needs them. They are the simplest to implement, since there is no ‘restore’ requirement. (e.g. extra lives in a game that expire, other supplies, digital currency)
Non-Consumables — purchased once and available to all devices registered to a user (additional functionality, e.g. audio effects)
Auto-Renewable Subscription — a recurring subscription that will renew itself until the user opts out; (e.g. recurring delivery of newspaper, magazine issues, weekly subscription to a dating service, some cloud storage service)
NOTE: Beware of a tricky character of this type! It’s not that easy to disable recurring billing once a user has signed up for that. Developer cannot accomplish opt-out procedure for a user and will have to somehow explain which steps should be taken to opt-out. Otherwise, be ready for tons of complaints.
Free Subscription — permits the delivery of free subscription content to Newsstand-enabled applications without any charges to the user. It can be turned off by the user
Non-Renewing Subscription — allows the sale of services with a limited duration. (e.g. one week subscription to voice guidance feature within a navigation app).
NOTE: In case a user wants to renew the subscription, you have to initiate a new Store Kit purchase request. Then it’s your responsibility to track the expiration date of initial and renewed subscription. Also your app should include a mechanism to deliver the purchased Non-Renewing Subscriptions to all iOS devices owned by a user.
To make sure your vision of In-App Purchase coincides with Apple’s one, see their guidelines.
Before letting in-app purchase out to the iOS user environment you should test it. Apple provides the possibility to do it via iTunes Connect. For that you would need to create products to purchase and test accounts to make the purchases.
There is special testing sandbox environment provided by Apple that enables testing without any incurring charges. See Test Users in the iTunes Connect Developer Guide for more information about creating test user accounts.
NOTE: You should remember to implement the possibility of restoring purchases in case a user deletes the application and downloads it again after some time or installs it on another device. The purchases are bound to user Apple ID, not a mobile device.
About lawsuits, injustice and pop-ups
Thanks to a $32.5 million settlement Apple made with the Federal Trade Commission over children’s in-app transactions, it is now paying a refund to customers whose children made in-app purchases on their iPhones or iPads without their consent. The FTC action against Apple required the company to change its practices to ensure users weren’t charged for unauthorized purchases.
When making an in-app purchase from an iOS device, users get a warning reminding them of the 15-minute window they have to make additional purchases without re-entering their password. The thing isn’t new, but what it has been updated with under the compulsory requirement is that the alert now appears whenever an in-app purchase is made with the options «Settings» and «OK».
Users can either dismiss the warning by tapping «OK» or change their settings to disable the window. Moreover, by clicking on «Settings» users can apply in-app purchase limitations, including an option to require passwords for every buy. Alternatively, users can turn off in-app purchasing altogether.
What about Google? Why not to sue them? In fact, Google followed in Apple’s steps by hitting with a similar lawsuit over its billing practices regarding in-app purchases. The complaint alleges the company has deliberately tricked young children into making millions of dollars in purchases. In response Google offers instructions on its website that clarifies in detail how to configure a mobile device so that it requires a password for all purchases.
Both defaulters, Google and Apple charge 30% of the price for apps and all in-app products that you sell on Google Play/App Store.
Open Source IAP Alternative
What to do with in-app purchases in case you are aiming at multiple app markets? Sorry iOS apps, this alternative is going to concern only Android devices.
OpenIAB is an open-source library that provides an easy way to work with in-app purchases whatever store your app is tied with. The magic is that one APK will work in all the app stores and automatically use the already existing IAB APIs under each store, as well as an open API that app stores could implement.
OpenAPI doesn’t process any payments, it is just an API enabling the apps to communicate with app stores in order to request in-app billing. This way developers don’t have to integrate different APIs to their apps.
OpenIAB Lib is still under development. The job of this library is to wrap in-app billing APIs of several appstores. After you integrate OpenIAB Lib, and your app will support in-app billing for all these stores.
OpenIAB API is an in-app billing API for appstores to implement. OpenIAB API is integrated into OpenIAB Lib as one of the supported APIs. By implementing OpenIAB API, the appstores will automatically support any app that uses OpenIAB Lib.
There is much to talk about regarding in-app purchases in mobile apps on iOS and Android. If you have any questions, need suggestions, clarifications and surely app development, feel free to contact us.