Posted in: facebook, google, paypal, social networking, web20

Apple, Facebook, and Google – When to Launch Platform Payments

I’ve been tracking the progress of Google’s In-App Purchases for awhile. It’s not just academic to me – we’re building Android games over at Bionic Panda Games and the development of that product is pretty important to us. Previously, I worked on the Facebook Platform, which went through its own process in launching Facebook Credits. In watching how Apple, Facebook, and now Google roll out payments on their own platforms, I have a few thoughts and observations to share. In watching these platforms all roll out their own solutions, there are three things I’ve noticed.

Before I jump into the three observations, I think most developers want the same thing from any payment provider. First, you want payment enabled customers – you need to have people who have the capacity and ability to pay. Apple solves that – they have nearly 200 million credit cards on file. Facebook is working to solve that by nudging customers to sign up for Facebook Credits. Mobile providers like Zong, Boku, and BillToMobile solve this by enabling anyone with a mobile phone to use that as a billable identity. PayPal has a ton of payment enabled accounts as well – you get the idea. Second, developers really want to either have a standard, low friction UI (a la iTunes) or the ability to control the payments flow and UI themselves to optimize for conversion. It’s a pretty simple formula – payment enabled customers + low friction UI generally leads to good monetization opportunities.

Now, on to the observations about what happens with platform payments:

1. If you are on a platform provider’s network and they offer a payments, you should assume you will (eventually) have to use their solution. Most payments business require scale to work – it’s generally all about taking a small portion of a large amount of money flowing through the system. And most networks or platforms can only support a small (often) one payments solution at the scale required to make it an interesting business. Whether the payment provider wants to actually be the payment solution or control the payments / wallet experience, it’s generally safe to assume that most platform providers will ultimately want to plug into the money flowing through their platforms.

2. Platforms that let alternative monetization providers on their platform early lose the opportunity to set the rules of the road early. Platforms that attract developers or court them need to have a story on monetization early. In the event that platform providers don’t have a solution, most developers will end up doing something in order to generate revenue. Those publisher / developer chosen solutions might not be in line with what the platform owner would like to see happen. But in the absence of a platform-approved solution, most developers will find some way to make money because they need to do so to stay in business. Convincing (as opposed to requiring) developers to take out things that are making them money can be hard – once those solutions are in they’re sticky.

3. Allowing other payment solutions providers on your platform creates a reference point for developers – this matters when the platform provider’s payment solution comes out. Related to the point above, one of the challenges with launching platform payments after you’ve allowed “rogue” solutions on your platform is that developers already have some sense for how well they are doing with their own solution in terms of total revenue, conversion ratio, and fees paid to their payment provider. This generally changes the nature of the conversation. The conversation inevitably comes down to a conversation about whether the platform’s payment solution will be as good, as cheap, and as effective as what developers are already doing. And that can be an awkward conversation.

At the end of the day, platform owners can do whatever they want with their platforms when it comes to payments. They can mandate or bar usage of certain payment types. They can set their own rates and terms. But I think the cases of Apple and Facebook are interesting as it relates to Google:

Apple – I give Apple a lot of credit for being pretty smart with in-app purchases on iOS. They gave developers a fair warning that they wouldn’t really tolerate alternatives, announced that in-app purchases were coming in 3.x, and then they actually delivered the solution shortly after. That seems pretty fair to me – give developers a working and workable solution on a fairly fast timeline. Having 100-200 million credit cards on file and a super simple UI / UX is a strong offering for developers. That’s part of the reason why it’s working.

Facebook – Facebook took a pretty different approach. They let a lot of other payment options onto the Facebook platform from day one. Gradually they started restricting how developers could monetize with both payments and advertising solutions, culminating in the announcement that Facebook Credits would be mandatory in June 2011. Given the 30% take for Facebook, not all of the developers on the platform are happy about moving to Credits. But for Facebook, it was okay to wait – developers were clearly making money on virtual goods and Facebook had established itself as the only major social network with the scale opportunity of interest to developers interested in building large businesses. So complain as they might, there aren’t a lot of obvious viable alternatives for developers looking to build social games on top of existing graphs. As Facebook Credits roll out and are adopted more broadly by both consumers and developers, reluctant developers might have a change of heart and really both embrace Facebook Credits and see some real benefits from making the switch.

I think it will be really interesting to see how Google progresses. On the one hand, it’s early enough in the life of the Android market that they could move more like Apple and clamp down and stamp out anyone who’s attempting to use anything other than their own in-app billing system. That would be easy to do if there is a good enough UI / UX experience and enough credit cards / payment-enabled users on the Checkout system to make it a seamless experience for the average user. But I’m not sure that’s the current state of the market. Kim-Mai Cutler at Inside Network did have an interesting piece on the current state of affairs – read it here if you haven’t already. At the same time, the risk of waiting and taking the Facebook approach is that the payments ecosystem on Android could get out of hand and it will be hard to get the genie back in the bottle. Unlike Facebook, Google does face a very strong competitor in Apple – if developers are unhappy with Android, developing for iOS is a financially viable alternative.

As always, comments are welcome.

Follow me on Twitter: @chudson

Comments (2) on "Apple, Facebook, and Google – When to Launch Platform Payments"

  1. The big unknown factor is the government response. u00a0With Android becoming the default OS for mobile phone handsets, Google will face a significant regulatory risk if they try to force developers to use their payments solution.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top