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.