The in-app purchase model takes on a few basic forms:
- a user buys virtual goods to use within an application
- a user pays a recurring subscription for content in an app
- a user pays to upgrade to access more features in an app
These forms are commonplace on the web and existing social networks, where the freemium model has proven successful in a number of different settings, such as for Facebook games from Zynga, and utilities like Dropbox, Evernote or TripIt. But, as with so many other things, some complications emerge for in-app payments when it comes to mobile.
The in-app payments environment is defined by two key questions: what is technically possible or available on a given platform or device, and what’s allowed by the app store through which an app is distributed. For instance, plenty of payment solutions exist for iOS and Android apps, but if those apps are distributed through iTunes or the Android Market, they must use those store’s payment and commerce systems.
Other independent app stores choose to set no restrictions on the in-app payments developers use, while others provide their own in-app infrastructure. Operators, too, have gotten in on the act, with many looking to support in-app payments through billing APIs, and some similarly mandating their use for apps delivered through carrier channels.
This fragmentation adds an additional layer of complexity for developers, who must match their service provider to their distribution channels, and be prepared to support different solutions for each one.
But the promise of in-app payments may make the additional overhead worthwhile. One estimate credited 1/2 of Apple’s 2010 app revenue to in-app payments, while a research firm has predicted that by 2013, revenues from in-app purchases will surpass those from upfront download charges.