Search the site
What we do
Little Springs Design is a mobile product, research, design, and usability testing consultancy. We help wireless operators, associations, manufacturers, and application & website providers with product and UI design, patterns, training, research and strategy.
Downloads
Sign up to get a free copy of our Mobile Widgets Whitepaper or almost-monthly newsletter. Or buy mobile Java or web design guidelines.
Recent blog entries
Blog topics
Blog archives
Making mobile payments work
Most of us are aware of DoCoMo's mobile wallet, and there has long been keen interest in using the mobile phone as a wallet. Companies beyond DoCoMo are doing it: a Swiss bank, PostFinance, is using a SMS bar code solution, which should work as long as people want to pay directly from their PostFinance account.
There are several issues that need to be addressed to make mobile payments work in practice. In short, if the user can not rely on the phone to make a payment, there has to be a large incentive to risk having to try the transaction twice: once with phone, once with the physical wallet. Ideally, of course, the wallet is unnecessary but that will take a while.
- Point of sale - The technique for reading the payment mechanism must be common at merchants' point of sale. Good bets include bar code scanning. RFID will work fine with large retailers but not at small retailers. Very small retailers may not have an internet connection, so a connection to the existing credit card acceptance process would be nice.
- Payment instrument selection - Many people have multiple accounts, and would want to choose from them when making a purchase. Don't forget that gift cards are a method of payment; these should be included in any solution.
- Wireless network connectivity - At least in the U.S., connectivity can be somewhat unreliable in many stores. A retailer installing this solution should check for carrier connectivity before investing. This means that relying on SMS introduces potential delays in certain locations.
- Security - A stolen phone must not even seem like it might risk financial account data. Relying on PIN entry on the phone is good. Storage of account data on the device is a security risk.
- Ease of use - The wallet should be a fast-loading (or even native) application on the phone, with the initial screen showing available payment methods. If only one method is available, the bar code should be displayed immediately. The user should be able to access the wallet with at most two keypresses.
I haven't run across a proposed solution that addresses all of the above, but I certainly haven't seen all the solutions. It should be possible.
Imagine a user experience like this: Joan approaches the point of sale with her items for purchase. Rather than pull out a wallet, she pulls out her phone. She enters, at the standby screen, a four to six digit number that unlocks and launches the payment application. She selects her Visa card, types the amount of the sale, and the phone displays a two-dimensional bar code. She shows the bar code to the clerk, who scans it. Payment is authorized and Joan leaves the store. She receives an SMS receipt of the transaction.
What's going on behind the scenes: the PIN opens the payment application, allowing the "what you know" component of security to be paired with the "what you have" (i.e., the phone) component. No financial account data is stored on the phone, but a pointer to a wireless financial service, perhaps owned by a carrier. The user can manage all the credit cards and other financial instruments from a web site.
The bar code would be generated from a hash of the phone number attached to the device, the wallet service account ID, the amount of sale authorized, a pointer to which payment instrument is selected, device or SIM ID, and the current time stamp. The code would be good for only ten minutes or so, and would also be usable exactly once.
The biggest security hole that I see (of course, I'm not a security expert) is if a pre-paid phone is stolen or lost, since such phones may not be disabled upon loss. To address that issue, the application would lock if five consecutive incorrect attempts were made for the PIN. The phone would send a message to the mobile wallet organization, who would call the user and get further security information before re-enabling the application and PIN.
This solution eliminates the need for the phone to have connectivity, while preserving the security associated with the phone. The bar code can be scanned by a bar code reader or even a camera phone, enabling person-to-person payments.
No Comments
No comments yet.
RSS feed for comments on this post.
Sorry, the comment form is closed at this time.