How to add in-app purchasing to an iPhone, Android or Windows app

Knowing how you’re going to make money from your app building labours isn’t straight forward. Simply charging for your app may meet resistance from prospective users who can’t evaluate the product before buying, so it’s better to offer it free for a limited period, or entice users into paying later for a “pro” version with extra features or no ads. These two pricing strategies are widely used, but there’s a newer one you may also want to consider – in-app purchases (IAPs).

IAPs are used most often by game publishers, who make perfectly playable games available for free, but offer the ability to unlock extra features or move up the levels more quickly by paying for the privilege. Don’t think we’re talking a few pennies here – in Candy Crush Saga, for example, purchase prices range from 69p to £1.49, while a chest of gems in the highly addictive multiplayer strategy game Clash of Clans will set you back £70. At my local Indian restaurant the other day, I chatted to another diner who had spent more than £100 to beat his friend at Clash of Clans. Clearly, IAPs can provide a healthy revenue stream.

In-game purchases have come in for some bad press, mainly because a handful of children have managed to max out their parents’ credit cards by paying for in-game bonuses without realising they were using real money. For this to occur, the mobile device has to be set to allow IAPs, and the child needs to know their parent’s app store password, since this pops up before any transaction can be completed. Now, there might be scenarios where a child is allowed to make a small purchase and their parent’s password is entered and not asked for again for the duration of the playing session. However, I find it hard to believe that the huge sums reported in tabloid stories could be spent unless the child knew the password, in which case the parents were at fault, rather than the game developer. Apps should make it very clear that in-game items are being purchased with real money – and all of those I’ve used do so.

As a developer, there are restrictions on how you’re allowed to use IAPs, and you need to familiarise yourself with these for each platform you’re targeting. For example, you must not use IAPs to sell physical items or real-world services, and if you create a virtual currency for use within your app, then this must not expire. Even so, this leaves plenty of opportunities to take advantage of IAPs. Does this mean you’ll have to give up on your HTML app and resort to rewriting it in the native code of the mobile device you’re targeting? Not at all. There are several ways to add an IAPs facility to your existing HTML5 app. The one I’ll look at here uses Intel’s excellent mobile-development tool, XDK.

This solution involves a cloud service called 1Touch, which is part of the group of services in appMobi that you access and use via XDK. When a user downloads your app via the store, a unique ID is generated and stored in a digital wallet on their mobile device. Whenever that user presses a “buy now” button inside your app, the ID is passed securely to the cloud servers; once verified, a further key is passed on to the merchant’s server for processing.

The amount of code you have to write in your app is minimal. First, add a reference to the 1Touch JavaScript library, such as:

Then, in your code for the IAP button, call a function to make the purchase:

Of course, you need code to handle any problems that cause the transaction to fail:

All being well, however, the transaction should proceed successfully, and money will appear in your account:

As you can see, the code is pretty simple, but you need to perform two major steps to make it work. The first is to add all your sale items to the 1Touch app that you’ve created in the appMobi cloud, which can be thought of as a web service your other apps can call to give them extended functionality. (Other modules give you the ability to run leaderboards for mobile games, as well as an advertising engine and a push-messaging service, but for now we’re only interested in the 1Touch module.)

Once you’ve created an account in appMobi, you can create an application by clicking the button. You can then select the service you wish to use (in our case, 1Touch). After selecting this, you can add “products” and group these together. In my test, I created a group called Gems and added two products, Ruby and Diamond. Within the screen for creating products, you have to fill in boxes for Name, ID, Price, Quantity and Expiry. You’ll need the ID that you enter for each product later, so make a note of these.

The Expiry field has only two options, “Consumable” and “NonConsumable”. Consumables are elements that are used up during a session of your app – minutes of a VoIP call, for example – while NonConsumables are items such as power-ups that move the player up a level in a game. (Other types, used for different kinds of subscription renewal, can be defined for iOS apps; these are outlined here.)

Having added to appMobi all the products your app will offer, the next (rather repetitive) step is to log in to each app store on which you’re offering your app and re-enter the products there, so the store knows how to handle payments. It’s crucial that you use the same product IDs you set up earlier.

Your app should now be able to handle IAPs, but there are a couple of other things you need to make sure of before going live. First, your app must be able to restore any IAP in the event of the user having to reinstall their device; this is now a requirement for all iOS apps. This can be easily done via the 1Touch system, and the guidelines are found here. As with any form of e-commerce, it pays to read the small print.

Each app store will take a commission for every IAP sale it makes: Apple, Google and Microsoft take 30%, although Microsoft’s cut drops to 20% if your app exceeds sales of $25,000. Also, bear in mind that your HTML5 mobile app can be submitted to the Windows Store as a Windows 8 app by many of the development tools, including XDK, which could provide you with a larger customer base.

The trickiest part of setting everything up is testing. You don’t want to test with live payments, since you’d end up paying 30% to the app store. The procedure for setting things up to test is different for each platform, but each provides clear guidelines. There isn’t room in this column to detail all of these steps, but they involve setting up and registering test user accounts, then using these accounts as dummy users to simulate purchases within your app.

It’s reasonable to guess that games will generate the greatest revenue from IAPs. Most developers would love to build the next FarmVille or Candy Crush Saga, but many assume that the HTML5 route won’t offer the performance that users expect, particularly on older devices with slower processors and JavaScript rendering engines. However, this isn’t necessarily the case. You don’t need to resort to writing native code, but you can use a game-specific build service such as Ludei’s CocoonJS system (www.ludei.com).

This is an interesting product. You write your app in HTML5 and JavaScript as normal, using whichever frameworks you like, and upload it to the CocoonJS cloud-based build service. An optimised version of your app is then built for each of the mobile platforms. CocoonJS provides an environment for accelerating the performance of the Canvas element in HTML5, and the performance of the demos is impressive. Take a look at www.ludei.com/showcase for examples of HTML5 games built using the system.

The performance of HTML5 games can be an issue, particularly on iOS and Android, so it’s important that your app employs the Canvas object rather than divs, which aren’t supported by CocoonJS. While the claim that you won’t need to rewrite your code is partly correct, you do need to start off using the correct tags to get the most from this system.

A basic HTML5 CocoonJS-compatible code might look something like:

This will merely create a 640 x 480 red box, but it shows how you might have to code your app to maximise CocoonJS’s performance benefits. CocoonJS may introduce support for acceleration of other HTML tags in future, or another product may compete in this area. In the meantime, however, the examples of accelerated HTML games I’ve seen running on mobile devices suggest that the extra programming effort required is worth it. There’s a good development guide on the Ludei website at here.