The Future Was Then: Micropayments Again
As Facebook begins to rollout a PayPal-driven micropayment system, and various other vendors attempt yet another land-grab on the “future of money”, I thought it’d be helpful to review some of the issues surrounding micropayments.
On the one hand, there are the very significant usability issues that must be addressed, but there are various approaches to that.
And while there is some speculation that increasing regulation of the credit card industry, or economizing by consumers hit hard in this recession, will drive people to adopt more micropayment schemes, I think the issues are somewhat more subtle than that.
And I don’t think credit card companies need to worry.
Until Facebook buys a bank.
Micropayments have a long history of falling flat (the earliest I remember was “Virtual Coin”, and I think that was back in 1995.) If you do a Google search for “Wired future of money”, there are maybe a dozen articles stretching back close to 20 years. So there have been a lot of attempts, and they run into all the same issues.
Essentially, the problem is this: it takes money to move money.
Granted, that’s not because the technology is expensive, or that costs scale up with volume: moving $1 between two banks costs about the same as moving $1 billion. The “problem” is that there are so many intermediaries who want a cut, albeit small ones.
Any micropayment scheme needs to deal effectively with three challenges:
- It needs to be low friction (friction defined as the difficulty of moving money from one place to another)
- It needs to be ubiquitous (everyone needs to accept it)
- It needs to handle fraud effectively
Friction
There are basically two types of friction in payment systems: ease of use, and transfer costs. Rendering payment (me giving you money) needs to be as simple as possible. That’s a usability problem, and not very difficult to solve (you need to follow some standard conventions for handling sign-in/authentication, communicating the value of what you are purchasing, and communicating the end of the transaction (the receipt.)
Transfer costs are more difficult: Visa/Mastercard want 3% of every transaction, plus a base fee – and it’s this base fee that kills every micropayment platform. If V/MC wants $0.25 per transaction, you’re not going to do any transactions valued at less than a few dollars. And true micropayments would be dealing in transactions of less than a penny (i.e., 1/10th of a cent to read an article on the WSJ. 1 cent to print it, etc.)
Bank interchange fees come into play there too (that’s the fee one bank charges another to send money electronically.) Again, these fees are small, but significant to a sub-$1 transaction.
As soon as you try to move lots of small transactions between two banking institutions, you’re dead in the water. The embedded costs are too high (and the players have no incentive to make them lower. Remember: the cost is not a function of the transaction size, but transaction volume, and the banks prefer it that way.) So if moving small amounts money between banks is too expensive, what do you do? You try to create your own ecosystem.
Ubiquity
What do PayPal, EZPass and SecondLife all have in common?
They are all semi-closed payment ecosystems.
Each one works basically the same way: you deposit “real” money from a “real” bank into a payment account with the vendor, and you’re given credits. Sometimes these credits are called “dollars”, and sometimes they are called “Lindens.” But they all have the same basic characteristic: they can be exchanged readily, and at a near-zero transaction cost, between any two members of the ecosystem.
Moving money from one account to another at any of these “banks” is simply a matter of making a ledger entry. It’s instantaneous, and involves no other outside intermediary. The intermediary only comes back into play when you try to move money out of the ecosystem, back into the banking system. Notice that PayPal doesn’t charge the payer to fund a transaction from a credit card or bank account, but *does* charge the recipient. PayPal bakes these “external” costs into their internal system transactions, because this opens up their ecosystem to be used by non-members. I don’t need to have a PayPal account to pay someone with PayPal. Sadly, however, baking in this external cost makes micropayments impossible. PayPal’s micropayments fee is 1.9% +$0.05. If I sell a digital good for $0.10, my profit margin (assuming 0 production costs) is only 30%. In the world of digital goods, that’s shameful.
However, once an ecosystem is ubiquitous enough (oh, say, 500 million to 1 billion users), the ratio of internal-only transactions way outstrips I/O transations (with users outside the ecosystem), and the ecosystem manager can afford to remove the external processing charges from these internal transactions.
Why does this matter? Because no one buys eggs from their bank. Eventually you want your money *out* of the ecosystem, so that you can go use it somewhere that the ecosystem doesn’t reach. (And forget the argument about “just putting it on a PayPal debit card”, and going grocery shopping. That debit card lives in Visa/Mastercard’s ecosystem, not PayPal’s.)
So, let’s assume that you’ve got a billion users in your system, and they’re all charging up spending accounts with external funds (for which the funding institutions – the banks – charge a small fee, which you decide to eat), and exchanging Credits with each other in 1/10th of a penny increments. And you take 1.5% of each transaction as your fee (that’s 1/2 what any other merchant card processor charges, and you don’t even charge a per-transaction flat fee, so hardly anyone notices), and so on every transaction you’re making of a penny. Chump change, right?
1 Billion Users * 100 transactions/day * $0.001/transaction * 1.5% = $548 million/year in fees.
Yeah, I think that might be worth exploring. And that’s assuming that these users spend an average of $0.10/day online within this ecosystem.
OK, you’ve got $100,000,000/day sloshing around in your ecosystem, which your users have deposited with you, what’s the problem? They are not going to let you hold on to their “real” money for free, so you have to pay interest on those deposits.
And now you are a bank. And that brings with it a host of complications, but it also gets you direct access to the global banking system, which is important if you want to do things like enable cross-border transactions, EFT transfers to other banks, etc. And there’s lower costs to doing those things, which you pass on to your users.
Fraud
I won’t go into it here in too much detail, except to state this: Visa/Mastercard exist for a host of reasons, and one of the big ones is fraud detection and reduction. Recently I read that about 7 cents of every $100 in credit card transactions is fraudulent, which in the above example means that about $25MM/year is fraudulent. And consider, Visa/Mastercard’s stats are from an ecosystem where many transactions are done face-to-face, with signature verification, mailing addresses, etc. In the above example ecosystem, there’s much less in the way of identity verification, so the risk for fraud is higher.
It’s far from clear whether or not there exist any emerging micropayment ecosystems which will meet these challenges. But I think Facebook at least stands a chance of getting there, because it has three things:
- Low friction: paying another user in Facebook can be a single button click, or even a wall post: “Ben pays 1 credit to Patrick”
- High ubiquity: 300MM users and growing, many internationally.
- Good leg up on fraud detection: Facebook knows an awful lot more about your identity than even Visa/Mastercard, and given good pattern matching can probably figure out quickly if you’re setting up a profile as a front.
