Apple created a lot of buzz in the industry last week when it previewed the new capabilities of iPhone OS 3.0. Leading the list of new features, surprisingly, was a payments-related enhancement called “In App Purchase”.

I missed the briefing, but saw this new capability reported in the blogosphere as “subscriptions”, “micro-billing”, and a new Apple “Microtransaction System”. As a payments guy, it was time to investigate.

Here’s my one paragraph summary. In App Purchase lets an iPhone application trigger a purchase transaction against the consumer’s iTunes account. When triggered by an application, iPhone OS 3.0 throws up a purchase confirmation panel that conveys what is being purchased, its price, and asks the consumer to “Cancel” or “Buy”. If the consumer taps “Buy”, Apple OS 3.0 then throws up the iTunes credential panel that shows their familiar iTunes username and asks them to tap in their password. In App Purchases are aggregated in the consumers regular iTunes account, along with other purchases from the iTunes store, and billed on a regular basis against their card on file or their PayPal account.

From a business perspective, an In App Purchase is just another purchase transaction credited to the seller. The seller keeps 70% of each purchase and Apple keeps 30%. You might notice this is never referred to as a 30% transaction fee, as it presumedly covers a lot more than just transactions… underlying payment processing fees, chargeback handling, app hosting, distribution, etc.

As an aside, whether or not this is a good deal depends on who the seller is and what they are selling. Sellers of hard goods will never be able to pay these types of fees due to margin pressure; sellers of soft goods (like iPhone application developers!) take to this like catnip. Nobody seems to be confused about where they stand.

The 70/30 rev share is also what makes In App Purchase work as a micro-billing or micro-transaction system. The seller nets 70% of the purchase price, regardless how small the individual purchase might be.

What exactly the purchase represents is the interesting part. For a seller with a subscription model, In App Purchases provide a way to distribute an iPhone app that uses a subscription model. The app developer would bundle some subscription period (12 months, for example) along with the initial purchase of the app. An In App Purchase would be used to extend the subscription for another 12 months.

For payments professionals, this is not how we typically think of subscriptions. We might have imagined subscriptions sold through the iTunes Store as a purchase plan. Payment credentials on file would have been used on a periodic basis, perhaps monthly, to create a lights-out recurring revenue model. The iPhone consumer would have subscribed to an application once and the developer would have been paid on a recurring basis — as long as the application was installed on the iPhone and the user’s payment credential remained valid.

But that’s not how it works. With In App Purchases, the consumer is hands-on involved with each purchase decision. While most payments czars would question such a practice, Apple seems to know what consumer wants and has continually demonstrated an uncanny ability to make the hard appear simple.

In addition to subscriptions, Apple also offered examples of how an In App Purchase could be used to sell skill-level upgrades to games, additional content such as eBooks, and almost anything that can be delivered in real-time over the network to the application on the iPhone. Developers that have seen the new iPhone OS 3.0 license agreement report that In App Purchases can be used for the sale of anything except virtual currencies.

There are a bunch of other minor details. In App Purchases cannot be used inside free applications. Apple marketing wants to make sure that “free applications remain free”. Sellers get paid once per month. Settlement across multiple geographies is not yet aggregated into a single payment. Etc.

Stepping back from the details, however, In App Purchase may very well turn out to be an important milestone in the evolution of the iPhone ecosystem. It opens up additional monetization opportunities for app developers, which should drive more sophisticated applications, which should drive more users, which… well, you get the point.

Apple has provided the mechanism, and now its up to the Apple developer community to figure out the most innovative ways to exploit In App payments. Based on what this developer community has done so far, I can hardly wait!

Recent Payment Views

Payments Orchestration: What Comes Next?

Payments Orchestration: What Comes Next?

Orchestration providers have certainly come a long way, and can enable powerful capabilities and benefits for the merchants that employ them. This post explores some of the possibilities Glenbrook has been thinking about for where Orchestration (and even orchestration) can go next.

read more
Payments Post #12: Lessons from Change

Payments Post #12: Lessons from Change

In this month’s Payments Post, we want to draw your attention to several recent fraud incidents that underscore the criticality of effective risk management to your business and the safety and soundness of the payments industry.

read more

Glenbrook Payments Boot CampTM workshop

Register for the next Glenbrook Payments Boot Camp®

An intensive and comprehensive overview of the payments industry.

Train your Team

Customized, private Payments Boot CampsTM workshops tailored to meet your team’s unique needs.

OnDemand Modules

Recorded, one-hour videos covering a broad array of payments concepts.

GlenbrookTM Company Press

Comprehensive books that detail the systems and innovations shaping the payments industry.

Launch, improve & grow your payments business