No, I don't mean, how we are going to make money by running a mobile payment scheme. I mean, what are people going to use as money to pay with. If they complete a transaction and they hit "send" (or "pay") where will the money come from to do this payment. To put it in another way: "which account will be debited". Many different solutions have been suggested and implemented, but all have significant challenges. Below is a summary of some of the Value Stores that could be used as the money in mobile payments:
- Using an existing credit card as the source for doing a mobile payment would seem to be the most obvious approach. This has successfully been implemented, but suffers from the following challenges: A relatively small percentage of people with mobile phones have credit cards globally, the transaction can be expensive as credit card fees must be paid before any other revenue can be generated and the rigid (but sound) rules regarding fraud places a very big risk on such an approach.
- Using the mobile operator's billing engine as the source for payments have been proposed, but this approach can even be more expensive than credit card transactions. (See one of my previous blogs) . In addition, expect regulatory problems and significant challenges to extract cash out of the system. It is also unlikely that the mobile operator would be happy with sharing money earmarked for telecommunications with other retailers.
- Utilising existing bank accounts could be interesting, but integrating telecommunication systems to core banking systems can be expensive and time-consuming. Also the strain on a banking system when millions of small transactions starts hitting it, can be outside the design limits of such a system.
- A new dedicated mCommerce account may be the way to go. Remember that when credit cards (a new payment system) were launched in the 1970's, it came with its own dedicated account management system. Why should that not be the case for mobile payments?