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

1. A very large user base of people who have given you a payment instrument.
2. Publishers, merchants, or partners who feel comfortable surfacing your payment option to their customers.

Having a large base of customers is not enough – you need a large base of users who can and will provide you with some kind of payment instrument. When Google Checkout launched, there were quite a few people who already had Google accounts – if you use Gmail, Google Calendar, Google Docs, or just about any other product, you’ve probably created a Google account. But only a fairly small number of those accounts have any payment instrument attached to them. Having a relationship with a large base of consumers is good, but you still have to activate them and get them to connect a payment instrument to that account.

The publishers or e-commerce sites you want to target have to feel comfortable having your payment offering in front of their customers. I haven’t seen a lot of good analysis on why Amazon Payments haven’t taken off more widely in both consumer and business applications. I suspect the reason is not that there aren’t enough customers with Amazon accounts with payment instruments attached to them. The payment tiers are certainly competitive. I suspect the reason why it hasn’t taken off as much is that most small to medium sized e-commerce players view Amazon with a wary eye. Do they really want Amazon building a relationship with their customers? Do they really want to show that Amazon button and encourage their customers to think about looking for the same product at Amazon? Do they ultimately want a company that could end up being a competitor to control their payments flow? The answer to most of those questions is probably “no.”

So what can Facebook do to mitigate the risks mentioned above?

Lead with games – I think targeting games on Facebook makes sense. That’s where the money is. They should be able to get plenty of people to enroll credit cards, ACH, Zong accounts, or whatever other payment instruments they support as we know that people are already spending lots of money on social games today. Leading with games will not get them the entire Facebook audience, but it will get them in front of customers who do want to pay for things and are active Facebook users.

Beware of bundling – Facebook clearly has global aims in changing the world of advertising. At some point, I am sure (very very sure) that they will roll out a product that looks and acts like AdSense. It might even be tied to Facebook Connect or Pay with Facebook. If that is the case, I suspect there will be tremendous pressure to bundle the payments piece with the advertising piece. I’m not sure this is wise.

If you’re really into Facebook and Facebook games, I encourage you to check out “Inside Virtual Goods – Future of Social Gaming” as it goes deeply into these topics.

Thoughts? Feel free to leave a comment below. Thanks for reading.

Changing the way people spend money and pay for things is hard. I’d argue that most people aren’t looking for new ways to pay unless the new payment method either a) enable a class of people who weren’t able to pay before to transact or b) it’s way less friction than competing alternatives. Otherwise, why not just use your current method of payment? I can think of a few payment innovations that succeeded (or are in the early stages of succeeding) and my guess as to why they’ve gotten traction:

• Bill Me Later – Allowed merchants to offer promotional financing and same-as-cash offers to e-commerce customers
• PayPal – Enabled relatively frictionless person-to-person transactions for auctions and other use cases
• Zong / Boku – Simple, fast, easy mobile payments using an existing billing system (the mobile phone)
• PlaySpan / Blackhawk / InComm / GMG – Pre-paid cards enabling teens and other people to pay for digital content (iTunes, free-to-play web games, etc)

I also worked on a payment product, Google Checkout, that is a good product but has not taken off. The reasons for that probably belong in another blog post. Suffice it to say that launching a new payment product, even with the imprimatur of a very strong brand like a Google or Faceboo, does not guarantee broad commercial adoption.

I’ve been reading about how the “Pay with Facebook” option that’s being rolled out to developers might actually be made available to 3rd parties in the same way that Facebook Connect is being rolled out. I’m still not getting the rationale for why off-Facebook payments are a big deal. I do think payment on Facebook could be really interesting because they have the ability to make buying things on Facebook just as simple as Amazon 1-click by storing credentials and integrating payments deeply into trusted applications. Now for my concerns…

Fraud has many faces – having a social graph (might) only address a few - Taking payments is a risky business. You’re always going to experience fraud, whether it’s friendly fraud or truly nefarious activity. Given that you can set up a fake Facebook profile, I’m not entirely convinced that the “verified” nature of Facebook identity is sufficient to reduce nefarious or friendly fraud. I need to be convinced of this argument before I’m willing to buy that merchants would view a “Paid with Facebook” transaction as being more trustworthy than a standard credit card transaction.

Merchants tend to be interested in offering payment options that convert well. Will enough Facebook users payment-enable their accounts to reach critical mass? How is Facebook going to get people to payment-enable their accounts? Sure, those who have purchased virtual goods or credits have a credit card on file with Facebook. But what about the other large percentage of users who don’t have a card or payment source on file? What will Facebook do to induce those users to register and how much will these inducements cost?

Beacon had some things right – the primary benefit of off-Facebook payments is likely to be a tight integration with the newsfeed or social graph – Say what you will about Beacon, the idea of publishing actual purchase or transaction data into a user’s social graph is a really powerful signal and a benefit that no other payment option can currently offer. For some categories that are inherently social (movie tickets, concert tickets, general entertainment and lifestyle purchases, life milestones, etc), the ability to broadcast a transaction could drive additional downstream revenue from people who see that activity and choose to transact. Is this a sufficiently powerful incentive for merchants to adopt off-Facebook payments? Depends on the complexity of integration, rate of adoption by consumers, and the number of downstream transactions they’d need to see to get a reasonable payback on the engineering effort.

My guess is that those e-commerce sites that have a positive experience with Facebook Connect will be first in line to trial a payments offer as a ride along.

What am I missing? Help me figure this out by leaving a comment.

i’m not sure people are ready to hand over financial creds to web 2.0 startups. that being said, plenty of cool work being done in money 2.0

When I first started working in venture capital after college, one of the first anecdotes I heard was the “vitamins vs. aspirin” theory of investing. In short, the basic idea is a notion of relative need – people with headaches will seek out aspirin while we all know we ought to take our vitamins and often don’t. The theory holds that the best businesses (traditionally) are more like aspirin (solving an acute need) than vitamins (good for you but not critical).

Unlike esoteric and philosophical arguments about data portability, privacy, and API integration, people have a strong and material interest in making sure that their money is safe and secure – it’s one of the few areas of web 2.0 where what’s at stake is real, concrete, and quantifiable.

I’m very interested in all of the cool start-ups I’ve seen in the personal finance space which I unimaginatively lump together as Money 2.0. Good examples include Mint, Cake Financial, Wesabe, BillShrink, and Covestor. I try to avoid writing about products I haven’t actually used that much but I’m going to do it in this case.

Given that Microsoft Money and Quicken are both getting a bit long in the tooth, it seems like now is a good time to be launching innovative personal finance products. Some thoughts about the whole Money 2.0 space below.

To succeed, I have to believe that these tools are going after people who are non-users of the desktop alternatives. Microsoft Money and Quicken both have large installed user bases and relatively flat growth in net new users. Chances are if you’re interested in a desktop personal finance solution, you’ve already got one. Given the marketing budgets and installed base those products have, I can only imagine that these money 2.0 startups are going after folks who aren’t using these desktop products. Whether or not they’ll succeed in converting these non-users to become active users of a web-based solution depends (I think) largely on the root cause of their non-use. Is it product complexity? Cost? Or is it simply that people know they should be more responsible about their money and just choose not to take action?

Are people ready to trust their financial information to new startups? I think this is going to be a really interesting situation to see play out. There are obviously early adopters in any market and people nowadays seem much more comfortable putting their personal information online in social networks and community sites. I have always thought that money is different than other types of personal information because the consequences associated with disclosure and misuse are so much higher. This will be a good test for how far the market has come in terms of people putting their financial information online.

One thing worth noting is that one of the historical advantages of desktop products is that the information on your computer feels “safe” as it’s under your control – as long as your computer is properly secured nobody can get to it (in theory, at least). Will people be as trusting in the cloud with services offered from new companies? I think there are more people willing to hand over their financial information to companies (start-up or not) who can help them better manage their money than either I or any other pundit today expect. I’m curious to see how large that audience is today, which is really what matters for all of the new entrants.

Is this going to be like Paypal or online bill payment? In terms of historical analogies, I wonder if this will play out more like Paypal or online bill payment. In the former case, Paypal was able to succeed in pioneering a brand new service that existing banks and financial institutions could have provided and in fact did try to provide. In the end, Paypal won for reasons that are too myriad to list here. However, online bill payment has been a different story. Based on data that I’ve seen, the vast majority of users who pay bills online pay them directly through their chosen bank or financial services provider. At this point, I’d be willing to say that it if there is a market for web-based personal finance solutions, start-ups are likely to win here. If any of these companies can build a large enough user base, I think they will be very difficult to knock off, even by a well-funded incumbent.

Right now to me, this market feels more like vitamins than aspirin, but that could change as people start saving money, getting their financial houses in order, and talking about the benefits of these products.

If you’re a user of any of the products mentioned in this post or have thoughts, feel free to leave them below.

Customer acquisition in the payments space is very costly – There hasn’t been a consumer-oriented payments product that hasn’t faced very steep customer acquisition costs. Credit cards, PayPal, Google Checkout, and pretty much every payment-related product has had to face this issue. The $50 million they raised is just a small drop in the bucket. It’s going to take a lot more money than that to get to meaningful adoption.

Merchants are going to love this – interchange fees are a big deal. Interchange fees are a big deal and they take a bite out of what merchants take home at the end of the day. Payment alternatives that lower interchange and don’t require costly infrastructure upgrades (I’m assuming that the Revolution card doesn’t require some proprietary terminal, communications network, or other financial non-starter for merchants). The trick, though, is whether consumers will want the card. Sure, merchants can push it and encourage their customers to use it. But will the promise of anonymity and security be enough to get consumers? One feature that does sound cool is the fact that the APR is a function of your creditworthiness to some degree. In negotiating with credit card companies in the past, I’ve always found it relatively easy to push back on high APRs – I’m curious to see what Revolution is doing differently.

All in all, I’m curious to see how this one works out.

True cost of processing for developers – Most payment processing businesses are based on some kind of wedge model. Charge the merchant x when it costs you less than x to actually process the transaction. Providing true cost of processing (or a closer approximation than PayPal is offering) is a pretty bold move. Importantly, it ought to be sustainable over the medium-to-long term.

Support for existing Amazon accounts – The other tough thing about building a payment system from scratch is getting an installed base of user accounts. Amazon has tens of millions of users who have transaction histories that can prove their (un)trustworthiness over time and an affinity for and trust relationship with Amazon. That’s a big boon to any developer looking to deploy the service.