In-app purchasing provides iOS, Windows 8, and Android developers with more ways to earn revenue from apps. For Android developers, there is an additional complication when bringing apps to new app stores: the in-app purchasing (IAP) capabilities must be changed.

Why there isn’t a universal billing solution

This complication exists because most in-app purchasing capabilities can only be used for one market. For example, Google Play’s In-App Billing (IAB) library cannot be used in the Amazon Appstore (nor can the Amazon Appstore IAP library be used on Google Play). Even platform-agnostic billing systems like PayPal are problematic, because the big Android app stores all tend to have a provision in their terms of agreement that ban this practice.

Other payment solutions are still allowed for other kinds of purchases, such as ordering physical goods. The point of contention and sometimes confusion is when developers and alternate payments systems attempt to cut the app store out of the loop and their 30% share of the in-app purchase. As always, I do not suggest gambling on not getting caught; I build apps for the long haul, not a quick money grab.

Building a universal solution would be a difficult task, because the Android app store ecosystem is continually evolving, with new app markets popping up and disappearing continuously. This leaves us with a problem: deploying an app to multiple app stores requires multiple in-app purchasing solutions.

Third-party options

It may be tempting to turn to a third party to get a multi-platform billing service, and there are options for services that handle the platform billing details for you. There are also open-source options for simplifying the interface for Google Play billing, which may warrant attention when building a new IAP solution.

The trouble with using a third-party billing solution (at least as far as the ones I’ve seen) is that they take a cut of the income but don’t give me access to other markets that I need. They may handle Google and Amazon, but won’t handle Samsung or other markets I may want to investigate. Until such a service already supports the billing platforms I need when I look into it, they won’t be the right choice for me.

The lack of flexibility is the deal-breaker for me. I investigate and engage many different Android app markets, and a partial solution would be more damaging than helpful.

Maintain your own flexible solution

My current solution to this is a hybrid version of my app that can handle Google Play and Amazon billing. I control which code is activated using a flag at compile time. I haven’t included Samsung yet because the additional permissions warrant creating a separate project to keep permissions correct for other platforms.

Since I use the AndroidMarketManager library to ensure my app links to the correct app store, the mechanism is already in place to take appropriate actions based on the selected app market. A simple selector could look like this:



if(AppConstants.MARKET_SELECTOR 
      == AMMConstants.MARKET_SELECTOR_GOOGLE) {
   final long time = new Date().getTime();
   final boolean requestSuccess = getBillingService().requestPurchase(
AppConstants.GOOGLE_PURCHASE_ID,
                 BillingConstants.ITEM_TYPE_INAPP,
                 String.valueOf(time));
} else if (AppConstants.MARKET_SELECTOR 
            == AMMConstants.MARKET_SELECTOR_AMAZON) {
   final String requestId = PurchasingManager
            .initiatePurchaseRequest(AppConstants.AMZ_PURCHASE_ID);
}




The main platform-specific code resides in the PurchaseObserver classes (Amazon and Google employ a similar construct). The Observer class interacts with the notifications for successful purchases as well as refunds and cancellations.


This isn’t a one-step integration — aside from the boilerplate market code (which Amazon provides, but Google only gives you an example of), there are a few additional points of integration where I have to guard Amazon- or Google-specific code and only execute the correct one. The end result is that much of my billing-related code — such as logic to manage purchased items and supply that information to the rest of the app — is platform-agnostic; this will simplify: maintenance, adding new IAP platforms, and reusing this code for future apps.


The do-nothing option


If the other options don’t seem worth the effort to implement, you can always avoid in-app purchasing outside of Google Play. However, I think you would miss revenue if you take that route. I have seen better results with Amazon IAP than from Google Play (Figure A) so far.

Figure A


 


What’s right for your app?


You have several options to handle in-app billing for multiple app markets: build your own, use a service, or avoid in-app purchasing on other app markets. Every developer will have different needs and different levels of resources available to tackle this issue.


I suggest that you balance potential income with future maintenance costs and fees to find the right solution for your app. Implementing in-app-purchasing for additional Android app stores can increase your profit if you can keep the implementation costs reasonable.