GetJar

GetJar ( http://developer.getjar.com ) is the largest independent cross-platform app store. It is also well known for operating the largest virtual currency on Google Play (Getjar Gold, available to more than 100 million users). If you want to get information on developing in-app purchases using the GetJar app store, you can find it here: https://developer.getjar.com/android/getjar-app-commerce-solutions/

SlideME

SlideME ( http://www.slideme.org ) powers more than 140 Original Equipment Manufacturers (OEMs) preloaded with the slideME market. Conveniently for developers, the SlideME app store supports all in-app billing solutions other than Google Play and Amazon. Its developer site is here: http://slideme.org/developers

Samsung Market

As the number one smartphone brand, Samsung ( http://apps.samsung.com/ ) offers a large market for Android applications, with support in more than 60 countries. Its in-app purchase library is called Plasma. Developers can learn more here: http://developer.samsung.com/android/tools-sdks/In-App-Purchase-Library

Blackberry Market

Android apps can be repackaged for the Blackberry 10 and Blackberry Tablet operating systems. Use of the Blackberry market ( http://appworld.blackberry.com ) assumes that you have ported your app to the Blackberry platform using the BlackBerry Runtime for Android. After you do that, you get access to in-app payments through Blackberry World. You can find more information here: http://developer.blackberry.com/android/apisupport/apisupport_inapp_payments_support.html

Nook/Fortumo

The Nook e-reader by Barnes and Nobles has an app store ( http://fortumo.com/nook ); and in partnership with Fortumo (a payment processing company), Nook has very recently begun offering in-app billing. You can learn more here: http://fortumo.com/countries

SK T Store

The SK T store ( http://www.skplanet.com/Eng/services/Tstore.aspx ) bills itself as Korea’s number one mobile contests open store. It has more than 18 million users and supports in-app billing. Its developer web site is here: http://dev.tstore.co.kr/devpoc/main/main.omp

Google Play Store versus Amazon Appstore

The Google Play Store supports both in-app purchases and subscriptions, so you can generate a recurring revenue stream. The Amazon Appstore also supports in-app purchasing and subscriptions.

Neither Google nor Amazon allow you to use in-app billing to sell real physical products, personal services, or anything else that requires physical delivery. To do that, you need to host your own store. For example, you could link your app to an online store you created with http://www.shopify.com or an equivalent provider. This isn’t all that difficult; just link to your store from within your app. Alternatively, you could integrate the PayPal SDK into your app. You can read more about doing so here: http://androiddevelopement.blogspot.co.il/2011/04/adding-paypal-payment-in-android.html

If you use Amazon, you benefit from the ubiquity of Amazon’s one-click payment system. Furthermore, Amazon’s Kindle e-books are all Android-enabled devices. If your app is a particularly good fit as an app on the Kindle, you should give the Amazon market extra consideration. Amazon’s solution may also be a bit easier to implement than the Google Play solution.

Realize, however, that Amazon in-app billing can’t be used within apps that have been downloaded from the Google Play Store. Likewise, Google Play in-app billing can’t be used within apps that have been downloaded from the Amazon Appstore. The Google Play Store is much more commonly used than the Amazon Appstore, so you’re likely to get many more downloads if you place your app there. On the other hand, there is some evidence that the Amazon Appstore generates higher revenue totals for in-app purchases.

Some developers have refused to settle for one or the other, and have implemented apps that use both in-app billing solutions, depending on where the app has been downloaded from. At the moment, that is the best (although also the most complicated) solution available. If you go that route, there are some open source helper functions that make it easier to write software that concurrently supports multiple app stores. This link details their use: http://www.techrepublic.com/blog/app-builder/juggling-in-app-purchasing-from-multiple-markets/1824

When to Use In-App Purchasing

• When your app offers something really valuable, but you need to give your users a chance to realize that it’s worth the price. Like the freemium business model, you can let users try your app for free, but now you can get a continuous revenue stream each time they purchase something in your app. But remember that this works only if your users see the value in what you’re selling.
• When you have lots of related ideas for your app, but you want to start with just the first one. You can keep adding content to your existing app and charging for each piece of new content. Compare this with building lots of separate apps—they would each need to develop a user base on their own.
• When you’re offering a service that makes sense to subscribe to. Maybe you’re hosting content for your users, and it’s easy to justify an ongoing cost to them because you incur an ongoing cost to host their content.

When Not to Use In-App Purchasing

• In-app purchasing can be complicated to implement well. You need to do a lot of testing to be sure everything works right. Users will complain, loudly and rightfully, if they hand over money and things don’t work as expected. You will definitely want to consider targeting your app to Android version 2.2 and higher, which supports the simplified version 3.0 of Google’s in-app purchasing application programming interface (API). Fortunately, this includes nearly 98 percent of the Android user base.
• More user support is needed as compared with other business plans. Users might not be familiar with the in-app purchase process, so expect to spend more time answering their questions.
• Some users may be upset that your “free app” requires payments for additional features. This could result in bad reviews. You must be careful to fully explain this before they even download the app.

Requirements for In-App Purchasing

If you choose to implement in-app billing, there are a number of requirements. For Google Play in-app billing:

• You must have a Google Wallet Merchant account. This is where the revenue from user purchases will be placed.
• Android 1.6 or higher is required for version 2.0 of the in-app purchasing API. The easier-to-use and more-powerful version 3.0 of the API requires Android 2.2.
• You can sell only digital content. This means you can’t sell physical goods, personal services, or anything that requires physical delivery to your end user.
• Your users must have an active network connection in order to purchase in-app goods.
• You must deliver the content; Google does not provide integrated content delivery services. In many cases, you can simply build the extra content into your app to begin with and just expose the extra features after the user has purchased the right to access them.

For the Amazon in-app purchasing API:

• Android version 2.3.3 is required.
• You can sell only digital content. This means you can’t sell physical goods, personal services, or anything that requires physical delivery to your end user.
• Your users must have an active network connection in order to purchase in-app goods.
• You must deliver the content; Amazon does not provide integrated content delivery services. In many cases, you can simply build the extra content into your app to begin with and just expose the extra features after the user has purchased the right to access them.

Product Types

As already mentioned, both Google and Amazon support purchases and subscription-based models. Purchases can also be consumed in Google’s version 3.0 API and in the Amazon API. For example, perhaps you want users of your first-person shooter to buy extra lives, and those lives can be consumed during game play. Subscriptions can be renewed monthly or annually when using the Google API. Amazon allows renewals to occur weekly, biweekly, monthly, bimonthly, quarterly, semiannually, or annually.

Managed in-app products are products that have their ownership tracked by Google’s servers. Google stores the ownership status of these items so that your app can access them each time it is run. If the product is something that can be consumed, your app must alert the Google servers that the product has been used. This same capability is available through the Amazon service, although storing product state is the developer’s responsibility. If you purchase what is known as “entitled content,” the Amazon servers perpetually reflect your users’ right to use the content. This is the case for access to new levels of a game, for example. On the other hand, if your content can be consumed, your app still initiates the purchase, but Amazon does not record it as entitled content. You need to track usage of the product internally and simply request another purchase when it has run out. Of course, if your app does not correctly record the state of the consumable purchase, a user could lose access to it.

Delivering Your Own Content

You may have noticed that both Amazon and Play in-app billing require you to deliver your own content. When your customers’ in-app billing purchase goes through, they expect some new feature or content to appear. If you have already built that content into the app, you can simply enable it and you’re done. If you can do things this way, it’s certainly easier.

There are reasons why you may not be able to do things in this manner. Perhaps your content will be generated after the app is released. For example, maybe you’re planning to write more levels for your game and add them as in-app purchases later on. If so, you need to worry about delivering your content. This is typically done using a private remote server. As you can imagine, this requirement adds significantly to the complexity of your code base and cost of your app. A remote server requires some back-end development, and you also need to pay any costs associated with running a server.

One option to simplify content delivery is to use mobile back-end services. They are hosted solutions that provide developers with a mobile API that they can use to take advantage of back-end servers without actually having to deploy and maintain one.

Parse is one such service. Its basic plan is free and scales to up to one million requests per month. Parse was recently acquired by Facebook, but all signs are that it will continue offering its service to the public. You can learn more here: https://www.parse.com/products/data

Other mobile backend services include the following:

• Kinvey ( http://www.kinvey.com ).
• AWS SDK for Android ( http://aws.amazon.com/sdkforandroid/ ).
• StackMob: ( https://www.stackmob.com/ ).

Enabling Your App to Use In-App Billing

To download the in-app billing library, open the Android SDK Manager. Expand the Extras section, select Google Play Billing Library, and install the Library.

Before you can use in-app billing, you must include a IinAppBillingService.aidl file in your project. This file is an Android Interface Definition Language file that defines the interface to Google’s billing service.

First, right-click the src directory of your project and select New ➤ Package. Name your new package com.android.vending.billing. Move the IinAppBillingService.aidl class (found in <sdk>/extras/google/play_billing/ as well as the previous sample app provided with the billing library) into this package.

Add your product to the Google Play Developer Console. To do this, select your application in the Developer Console and then select the In-app Products tab on the left side. You can then add a new product. The In-app Product ID must be unique in your application’s namespace. Your product type can be a Managed per user account, Unmanaged, or Subscription. You also need to add a description and price.

Initial Setup For In-App Billing In Your App

You can follow the detailed instructions here for the setup process: http://developer.android.com/training/in-app-billing/preparing-iab-app.html#GetSample

To summarize, you need to give your app permission to interact with the billing service via your manifest file. You also need to create an Iabhelper, which is the in-app billing helper class. This class enables a simplified synchronous style of communication that is one of the benefits of version 3.0 of the in-app billing API. The Iabhelper class uses callbacks to communicate with your code. In fact, the setup process uses an onIabSetupFinished callback function to return success or failure.

Using In-App Billing: Requesting a List of Items For Purchase

Again, the process is described here in great detail: https://developer.android.com/google/play/billing/billing_integrate.html

At a high level, you need to build a list of purchasable items that you are querying. The previous link uses this example:

List additionalSkuList = new List();
additionalSkuList.add(SKU_APPLE);
additionalSkuList.add(SKU_BANANA);
inAppBillingHelper.queryInventoryAsync(true, additionalSkuList,
   mQueryFinishedListener);
  

As you might expect, the mQueryFinishedListener is a callback function that is called with a list of available inventory, including their prices.

Using In-App Billing: Making the Purchase

Similarly, making a purchase involves a call the in-app billing helper, and the response is handled with a callback listener function:

inAppBillingHelper.launchPurchaseFlow(this, SKU_APPLE, REQUEST_CODE_VALUE,
   mPurchaseFinishedListener, "developerPayloadString");
  

SKU_APPLE is the item to be purchased. The REQUEST_CODE_VALUE is a positive integer that will be returned back to the caller. The developer payload string is a convenience string for use by developers to send supplemental information. It may be empty.

Using In-App Billing: Determining Which Items Have Already Been Purchased

Continuing the paradigm, you may determine which items have already been purchased with a query to the in-app billing helper that is captured by a callback listener:

inAppBillingHelper .queryInventoryAsync(mGotInventoryListener);
  

You need to determine which items have been purchased each time your app restarts so your users have access to capabilities that they have already purchased.

Using In-App Billing: Consumable Purchases

To consume an item that your user has purchased, you call the in-app billing helper as follows:

inAppBillingHelper .consumeAsync(inventory.getPurchase(SKU_APPLE),
   mConsumeFinishedListener);
  

Enabling Your App to Use In-App Billing

Download the Amazon Mobile App SDK package from here: https://developer.amazon.com/sdk.html

Extract the ZIP file into a directory on your computer. Within this directory, you find an /In-App-Purchasing/lib folder. This folder contains a JAR file called in-app-purchasing, which is the in-app purchasing library and must be added to your eclipse project’s library path. You can do this by accessing the Project Properties menu and going to the Java Build Path. There you can select the Libraries tab and add the JAR file.

Before you can purchase a product from within an app, you must add your product to Amazon’s distribution portal by signing into the Distribution Portal and selecting the My Apps tab. Choose the Manage In-App Items option from the app drop-down menu. Now you must choose whether you will be creating a Consumable, Entitlement, or Subscription product. You also need to add a price, description, and thumbnail image.

Initial Setup For In-App Billing In Your App

As you might expect, your application must be given access to the Amazon in-app purchasing library. The purchasing library is implemented as a broadcast receiver, and you declare it in your manifest by adding the following to the <application> section:

<receiver android:name = "com.amazon.inapp.purchasing.ResponseReceiver" >
    <intent-filter>
        <action android:name = "com.amazon.inapp.purchasing.NOTIFY"
                android:permission = "com.amazon.inapp.purchasing.Permission.NOTIFY" />
    </intent-filter>
</receiver>
  

Within your Java code, you access the broadcast receiver by registering with com.amazon.inapp.purchasing.PurchasingManager

This class initiates all in-app billing requests. To capture callbacks from the PurchasingManager, you must create a PurchasingObserver class and register it with the PurchasingManager. To do this, you subclass BasePurchasingObserver. (We will discuss each of the methods that need to be subclassed later in the chapter.) The registration with PurchaseManager occurs in your onStart and looks like this: PurchasingManager.registerObserver(new MyPurchasingObserver());

You also need to register the user using your app with the Amazon service. This also occurs in your onStart: PurchasingManager.initiateGetUserIdRequest()

You must implement a callback for this request in your PurchasingObserver class: PurchasingObserver.onGetUserIdResponse(GetUserIdResponse)

Using In-App Billing: Requesting a List of Items for Purchase

Similarly, a call using the PurchasingManager requests the list of items for purchase: PurchasingManager.initiateItemDataRequest(java.util.Set skus)

You need to implement the following callback in the PurchasingObserver: PurchasingObserver.onItemDataResponse(ItemDataResponse itemDataResponse)

Using In-App Billing: Making the Purchase

To make a purchase, call the following: PurchasingManager.initiatePurchaseRequest(java.lang.String sku)

The callback function you need to implement is the following: PurchasingObserver.onPurchaseResponse(PurchaseResponse purchaseResponse)

Using In-App Billing: Determining Which Items Have Already Been Purchased

The PurchaseResponse field in the callback to the following is set to ALREADY_ENTITLED when an item has already been purchased (of course, the item in question must be an ENTITLEMENT product as set in the distribution portal):

Using In-App Billing: Consumable Purchases

Consumable purchases are simply non-entitled purchases. Once they are bought, the app must track their use. They can be repurchased at any time.

Checklist: In-App Purchasing

• Does your app benefit from product or subscription in-app purchases? Ideally, your app should be one that builds a relationship with the user, delivers significant value, and creates an opportunity for multiple purchasing events.
• Does your app meet the requirements for in-app purchasing? Network access? Digital content?
• Have you thought about which app store is best suited to your app? Will you need to support multiple app stores?
• Will you need to host purchasable content for your app?