Developer Revenues: The Dilemma and the Opportunity of In-app Purchase and Carrier Billing

Guest Author, August 22nd, 2012

This guest post comes from David Schoenbach, consultant for Exadel, a mobile development company. He’s focused on Tiggzi, a platform for mobile app development.

How can developers make money? That’s a big question in the mobile app space, and the answer is changing. There has been a gradual recognition over the past few years that one-time payment for apps (those “paid apps” that we avoid downloading if we can) is not the happy-face solution for most developers aiming to be compensated adequately for the creative work they do.

Except for a handful of titles at the top of the list, it’s tough for paid apps to get the traction they need to become widely known. The result is that developers, more and more, look to alternative ways to make a buck: mobile advertising and in-app purchase. While mobile advertising is a fascinating topic, it’s in-app purchase that I’d like to talk about today.

Big successes are being seen in some of the apps that offer in-app purchase, notably games which offer virtual goods (e.g., additional levels, avatars, and other customization of the on-device experience). This works well for Zynga, Gameloft, Glu Mobile, and others.

A major inhibitor to user acceptance of in-app purchase is the inconvenience of many payment methods. PayPal works well in the US and is conveniently available in some other parts of the world. So too with credit card billing, but who wants to enter your credit card information yet again for the next small vendor, only to wonder what risk it may be putting you in? Amazon is easier for many, because tens of millions of users already have an account, and they’ve done a good job of making on-device purchase convenient.

But, by far the easiest payment method for the most people around the world is carrier billing. This is due to the fact that a large majority of smartphones worldwide are associated with a monthly payment plan for voice and data. The convenient ongoing billing relationship between the carrier and the end-user can then be extended to support other payments.

For the developer, this seems ideal: Build a “freemium” (free to use, pay to upgrade) app, include in-app purchase/upgrade opportunities, offer carrier billing, and voilà, revenues! Two problems, however, intrude on this ideal scenario: (1) Carriers have traditionally charged a lot for such transactions and (2) you don’t know which of the many hundreds of carriers your customers are on, and thus which carrier APIs you as a developer must support.

However, each of these problems is being addressed. There’s been progress on fees as wireless operators are tending toward a 70% share to developers (as opposed to the less-than-50% share in prior years). Also, there’s been a lot of movement on solutions for handling billing APIs from multiple carriers.

Although individual carriers, such as Verizon, AT&T, Deutsche Telekom, and others have offered carrier billing API solutions to developers for a while, this has met with limited acceptance so far. Now we’re seeing aggregation solutions emerge for cross-carrier billing APIs, enabling the easy creation of in-app billing solutions supporting multiple carriers. The Wholesale Applications Community (WAC) was a pioneer. Although they recently reorganized, they sent their in-app purchase API over to Apigee where it has a good home. Another example is Aepona, a service delivery platform (SDP) provider for dozens of carriers. Aepona now aggregates billing solutions from among their 25 carrier partners into one convenient API.

Both WAC and Aepona have worked closely with GSMA, the global trade association of wireless carriers, and, ultimately, it’s GSMA’s OneAPI project, under project director Harry Campbell,  where we should likely look for the most far-reaching solution. With almost 800 wireless operator members and with an extensive history of work in this area, GSMA’s latest effort was a recently-completed pilot in Canada. This effort brought together Canada’s three big carriers (Rogers, Bell, and Telus) to provide the first example of a region virtually blanketed by a carrier billing aggregation solution.

There’s a clear need for something like the OneAPI project, but the large number of carriers and regions presents a real obstacle. Whatever entity (GSMA, Aepona, Apigee, or other) does overcome this challenge, though, will be providing a significant service to the mobile developer community, advancing the state of the art – and commerce – of mobile app creation.


Both comments and pings are currently closed.

3 Responses to “Developer Revenues: The Dilemma and the Opportunity of In-app Purchase and Carrier Billing”

August 22nd, 2012
at 3:58 pm
Comment by: Developer Revenues: The Dilemma and the Opportunity of In-app Purchase and Carrier Billing | Tiggzi: Cloud-based Mobile App Builder

[...] Developer Revenues: The Dilemma and the Opportunity of In-app Purchase and Carrier Billing [...]

August 30th, 2012
at 1:04 pm
Comment by: Exadel and Tiggzi Showing Up in the News for July and August - The Exadel Blog

[...] Developer Revenues: The Dilemma and the Opportunity of In-​​app Purchase and Carrier Billing (August 22, 2012) David Schoenbach ex­plains in this piece how car­rier billing can be the big en­abler for using in-​​app pur­chases to make sig­nif­i­cantly more money for mo­bile de­vel­opers. The key for making this ef­fi­cient is a uni­fied API for dif­ferent carriers. [...]

September 5th, 2012
at 4:58 pm
Comment by: Understanding Carrier-based In-app Billing - The Exadel Blog

[...] 5, 2012 03:40 pm under Publications Not too long ago Exadel's David Schoenbach published a guest post on the ProgrammableWeb site about how mobile app developers could make more money. The answer was [...]

Follow the PW team on Twitter

ProgrammableWeb
APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.