Wallets, mobile wallets and hyper wallets

[Dave Birch] Well, I think we’re moving beyond the opening shots of the “wallet wars”. There seems to be coalescing opinion that mobile payments by themselves are unlikely to generate the kind of revenues that get big organisations excited and that payments are merely table stakes in a much bigger game. This bigger game is about access to, and indeed control of, transactional data. So the payments have to be wrapped up in a bundle that will be attractive to the stakeholders, and attractive enough to manage lots of different kinds of transactions.

Indeed, businesses of all kinds, including big companies like Google, Microsoft and Sprint and small start-ups like GoPago and Scvngr, are hoping to profit from mobile payments — if only they can figure out what kind of system appeals to consumers and merchants.

[From The Campaign to Digitize Your Wallet Is Intensifying – NYTimes.com]

I was listening in on a webinar about this recently. Forum friend Roy Vella, Rabobank’s Michael Dooijes and Mike McDonnell from Affinion gave short talks and then took part in a discussion around the subject. Something that I thought about several times during this discussion were the comments I’ve been hearing about the lack of demand for mobile wallet services. Customers are not demanding that all of their coupons and loyalty cards are stored in their phones (although they might change with the launch of Apple’s Passbook).

This is the crux of the argument against mobile payments: The transformation taking place is not necessary. For NFC in particular, it has been called a solution without a problem. The same goes for other benefits provided by mobile wallets. Coupons can be found in the Sunday paper, loyalty programs are as simple as a paper hole puncher at a register.

[From Revolutionary Technology & The Transformative Effect On Currency]

And, of course, pay phones are at convenient locations throughout the city, so there’s no real need to carry a mobile phone at all. This is a silly line of thinking, but you can see where it comes from: using a smartphone to make a virtual work-a-like of a bulging leather wallet is of marginal benefit and at great expense. If all the loyalty card in your Passbook is doing is simulating punching a hole in a piece of paper then, indeed, the cost benefit analysis looks awry. I have just such “loyalty” cards for each of the three coffee kiosks that I use (entirely randomly) at Woking station. Each of them gives you the tenth coffee free, none of them has the slightest idea who I am or where I go. They have no mechanism for sending me information or tempting me with special offers. What would be the point of implementing these cards in my mobile wallet?

The other big question at the moment is who will provide the wallets. Are we resigned to it being Apple or Google? Do banks need to provide mobile wallets? I’ve been preparing some material on this for a client and I don’t want to share their strategy, but suffice to say that banks don’t provide leather wallets, they provide the payment instruments that go inside them. Surely, by analogy, it makes sense for banks to focus on API-based strategies to make their services available to other wallets, right? Then it doesn’t matter if the wallets people use are apps, cloud-based or whatever else.

While some folks tend to think about APIs as being little bits of arcane code that only developers care about it, the truth of the matter is that billions, possibly even trillions, of dollars are at stake in what will soon be a series of API wars.

[From How APIs Are Fueling the Mobile Banking Wars]

This particular article is about banking APIs, but the area we were looking at was mobile wallet, and this needs other kinds of APIs to make it fly: in particular, a decent mobile wallet will need access to operator APIs for location, billing and secure storage on the SIM, access to identity services provided by the operator or other third parties and presumably many other kinds that I haven’t thought of yet. And why will banks etc provide these APIs? Because it may be the only way they can get at the information around the transactions. And that seems like it me be a reasonable stakeholder settlement, when you think about what you might want your mobile wallet to do.

Actually, to help facilitate discussion on the topic, before we go any further I would like to propose some simple terminology. A “virtual wallet” tries to make an electronic version of your physical wallet, a “mobile wallet” is a virtual wallet that uses some capability of the mobile device to add convenience and a “hyper wallet” does what a smart wallet should do, if you see what I mean. A hyper wallet doesn’t try and simulate a physical wallet: it meet the requirements for a wallet in the modern, online world. It doesn’t emulate the leather wallet, it blows the leather wallet away.

“The physical wallet, which had no innovation in the last 50 years, will become an artifact,” John J. Donahoe, the chief executive of eBay, told me recently.

[From The Post-Cash, Post-Credit-Card Economy – NYTimes.com]

I suppose the innovation of 50 years ago that John is referring to was addition of payment card pockets! I think John is right, of course, and I’m very much on that side of the fence. And I also agree with what someone else from his organisation has just said on the same topic.

Your mobile phone won’t be the one device that will forever banish your leather wallet to the back of a drawer. It will, however, be an important access point to your digital wallet — which will live in the cloud and follow you wherever you go

[From The iPhone 5 Doesn’t Have NFC — So What? – Carey Kolaja – Voices – AllThingsD]

This echoes the point I made about the role of hardware. Even when everything goes into the cloud, the keys to the kingdom will still need to be stored in tamper-resistant hardware, and this means that chips and clouds can, and must, coexist. I’ll blog more about this some other time. But back to the hyper wallet that will blow the leather wallet away whether the data is stored locally or in the cloud. What kind of things should a hyper wallet do? Now, obviously, one thing it can do is auto-reconfigure depending on location, time of day, offers received and stuff like that: it can become contextual as the SoLoMo personal nexus. When you walk into Starbucks, your Starbucks wallet will open up show you any offers, invite you to order and confirm payment. All you have to do is wander up to the waiting area and listen out for your name. Goodbye POS. And goodbye cards too, by the way.

I suppose what I wanted to flag up in this post is that many, even most, of the cool things that hyper wallets will do are related to identity, not to payments. This isn’t simply my narrow and deranged vision of future.

Dua said Google wants to “electronify” all kinds of credentials, cards and tickets, everything from boarding passes and concert tickets to identification and gift cards. That would make Google Wallet a central hub for users that they can turn to regularly.

[From Google Wallet aspires to hold all your cards and tickets — Tech News and Analysis]

So the most important APIs into the wallet will be the ones that help the service providers to know who you are. Naturally, I would advocate delivering a rich set of identity services (including pseudonymous identities) to give service providers infrastructure that can help them to overcome security and privacy issues to provide great consumer services and great data to the API providers. If were to be advising, say, a mobile operator consortium on the potential architecture for future wallet services I’d definitely start by separating the digital identity and digital money APIs and then building my wallet service on top of these if I decided that I needed a wallet of my own. But these same APIs should be my trump card to other wallet providers (i.e., retailers) and keep me in the loop no matter how the wallet wars work out.

These are personal opinions and should not be misunderstood as representing the opinions of 
Consult Hyperion or any of its clients or suppliers