Microsoft Wallet: Retailers, Do It Yourself

The mobile wallet that Microsoft unveiled on June 20 turns out to be a radically unbundled approach, at least compared to Google Wallet and ISIS. The wallet app itself just collects individual issuing-bank and loyalty-card apps, while Microsoft is handing off responsibility for securing payment-card numbers to mobile carriers. It looks like Microsoft isn't even touching transactions—which is good and bad news for retailers.

The good news: no Google-style POS changes required, at least not to meet Microsoft specs. The bad news: no help from Microsoft, either. Unless you build your own in-store shopping app, the Microsoft Wallet will basically do contactless card emulation—and not much more.

Microsoft has refused to answer any questions about the wallet, which is just one feature of the Windows Phone 8 operating system it expects to ship later this year. That suggests either there's a lot Microsoft hasn't figured out about how it will work or there's a lot less here than you'd expect from a "mobile wallet." Based on what the software giant has said, it looks like the answer is "less."

For example, the wallet demo for developers last week was about 10 minutes out of a two-hour presentation. But that was time enough for Microsoft exec Joe Belfiore—manager of the Windows Phone Program—to explain that all the payment cards in the wallet were actually individual apps—for example, a Chase app for a Chase payment card, another Chase app for a debit card—bundled together with the wallet user interface. Nothing wrong with that, but it's not something that will enable anyone to push the boundaries of CRM.

Microsoft also announced last week that using its phone for tap-to-pay will depend on having an NFC-enabled SIM from a mobile operator. Or in the words of the official announcement, "When paired with a secure SIM from your carrier, you can also pay for things with a tap of your phone at compatible checkout counters."

Translation: The payment-card numbers will be stored in a Secure Element on the SIM. That means the mobile operators, not Microsoft, will control what cards go into the wallet, and that's who card-issuing banks will have to deal with. (Will that involve ISIS or individual carriers' own NFC efforts? At this point, no one is saying.)

From Microsoft's perspective, that's elegant—it makes card numbers somebody else's problem, whether that's getting them onto the SIM, changing or deleting them, or keeping them secure.

For retailers, it means there's no Google or ISIS trying to figure out how to make money without adding to existing interchange fees. Microsoft will presumably make its money by selling phone software licenses.

But it does push some of the complexity directly onto large chains if they'd like to do something a little fancier.But it does push some of the complexity directly onto large chains if they'd like to do something a little fancier than just getting customers to use their mobile phones instead of contactless cards (and considering that most customers don't even know they're carrying contactless cards, that's going to be a tough sell).

Think of it as the Google model—customers pay using their phones and Google pushes ads and coupons, tracks purchases and issues E-receipts—only without Google in the middle. A customer could pay using a payment-card app on the phone, but it will just look like a contactless card to your POS.

To do something more, each retailer will need to create its own in-store shopping app, then make the appropriate adjustments to its POS systems to push out loyalty-card numbers, issue E-receipts and dish out any discounts or coupons. Retailers each get to do it their own way—but they also have to do it their own way.

That may not sound very appealing, but so far the results on non-retailer-driven mobile wallets haven't been encouraging. The closest to a really popular mobile-payment option for big retailers is the one for Starbucks, which has clearly been driven by the chain. Nobody uses the iPhone (or Android or BlackBerry or Windows Phone) to pay for their coffee—they use the Starbucks app. (And they use it a lot.)

Microsoft may simply be taking the easiest path by handing off the hard work to retailers, banks and mobile operators. Of course, Microsoft may also hope to get into mobile wallets the easy way, and later try to carve off a bigger piece of the pie—much like Apple seems to be doing.

Or maybe Google will offer chains an easy way to add Google Wallet functionality to their apps, so the retailer's Windows Phone app will work with the special CRM features that Google subsidized in all those POS modifications. So effectively, Google Wallet would be embedded in a retailer's app, which would be embedded in the Microsoft Wallet. That could make things a little simpler in practice, even if conceptually it's the messiest payment system imaginable.

Still, all this may be moot if someone besides Starbucks doesn't goose customers in the direction of paying with their phones. Google hasn't done it. Neither has PayPal, and ISIS isn't looking likely (we're still waiting to hear that its Salt Lake City and Austin trials have started).

It's clear that Microsoft won't be doing it, either. If chains want mobile payments, they may have to do it themselves.