Apple's Wallet-Without-Payments: If This Works, Maybe We'll Try The Hard Part

Apple's announcement on Monday (June 11) of Passbook, the iPhone's mobile wallet that does everything except traditional payments, is a classic unthinkable move: Apple did the easy part first. If customers like using Passbook for tickets, coupons and loyalty cards, then maybe Apple will tackle the hard part: mobile payments.

There are several ways Apple could do that. But one thing seems clear: After the fruitless straining of Google Wallet, ISIS and PayPal to get customers and retailers on board, Apple's design philosophy of "it just works" means the impact on retailers of iPhone mobile payments should be nearly invisible—except that customers may actually use it.

The announcement this week was only a small part of the forthcoming upgrade to iOS, and Apple executive Scott Forstall didn't mention NFC. Instead, his demo showed Starbucks and Apple Store cards, Target coupons, and Amtrak and United Airlines reservations. He also mentioned an API to let third parties add payment functions—as long as, like Starbucks, they use 2D or 3D barcodes.

This is Apple's long-awaited entry into mobile wallets? No tap-to-pay, no deals with retailers or processors or banks or card brands or carriers? Of all the smartphone vendors, Apple has the most clout with all the players it needs to line up for mobile payments. And sure, Google and ISIS and PayPal are looking like non-starters with users, but if Apple offers it, Apple's fanatical customer base will use it—right?

That seems to be what Apple is trying to find out. Apple is paradoxically a lot less confident of the Apple Effect than many retailers and most mobile-payments pundits. Apple is also a lot less confident in the whole idea of mobile wallets than Google, ISIS and PayPal. The best reason for that caution: the mobile-wallet experiences of Google, ISIS and PayPal.

Not everyone shares that hesitation. The same day Apple was announcing its wallet-without-payments, the smartphone blog Android Central published slides that seem to confirm that Sprint is working on its own Google Wallet-like system, right down to the tap-and-PIN approach. That's yet another pain point for Google, if it becomes a reality, because Sprint is currently Google's only official carrier partner.

An earlier story, published on June 7 in NFC Times, suggested Sprint could launch its own mobile wallet as early as this summer. But Sprint hasn't announced anything, and this yet-another-wallet may never officially see the light of day. The obvious question: If customers don't use mobile wallets from Google or ISIS, why will they use the same thing from Sprint or anyone else?

Apple's answer to that question: Make the easy parts of a mobile wallet. Unveil them as a very small part of a much bigger announcement (say, how 'bout that new MacBook Air and turn-by-turn maps?). Then see whether users jump on the new wallet feature enthusiastically—Apple Effect or not—before Apple dives into the payments problem. It makes Passbook an elegant first step into what has turned out to be one of the most swamp-like problems in retail.

If it doesn't work—if the Apple Effect is a myth in mobile payments, or iPhone users just don't see the point—Apple can quietly scrap any mobile-payments plans it has in the works (which it does, with a whole string of related Patent applications under its corporate belt) and go on to something different.

Apple's unstated point: Everyone else is doing it backward. The payment comes at the end—if it ever comes at all.

But suppose iPhone and iPad users love Passbook. How can Apple go after NFC payments?But let's suppose iPhone and iPad users love Passbook. How can Apple go after NFC payments? The easy part of that problem is sticking a few chips inside the phone. The hard part: making it "just work," the way Apple's customers are accustomed to.

Could Apple partner with Google or ISIS or PayPal? That seemed possible a year ago, but not now. Apple really doesn't want anything to do with Google—it has stripped Google Maps out of iOS and made a point of mocking Google at the event this week. That's not a prelude to partnership. ISIS has had trouble lining up interested retailers for its Salt Lake City, Utah, and Austin, Texas, trials this summer, and the trials still don't have a publicly announced start date. That doesn't build confidence.

And PayPal is the one payments player that really doesn't need Apple (for that matter, PayPal's in-store payments don't even need a phone). Apple likes to have a strong hand in any partnership. With PayPal, Apple wouldn't have any hand at all.

Besides, neither Google's nor ISIS's nor anyone else's NFC mobile payments are exactly elegant. You can't use just any payment card, and you have to go through a moderately complex process to acquire, install and activate the card. That's not Apple-style elegance. With Apple, you buy and activate the iPhone, and then everything else just works.

That suggests Apple won't cut its own Google- and ISIS-style deals with issuing banks, processing networks and retailers, either. If a bank said no, Apple would have to tell users, "Sorry, you can't use that card—try again." If a retailer didn't sign on, that Apple user's iPhone simply wouldn't work the way it's supposed to. That's anathema to Apple.

But wait—Apple already has 400 million payment-card numbers, one for each iTunes customer (and that includes every iPhone user). Why not just transmit those payment-card numbers to the phone during a mobile-payment transaction, then beam it from the phone to the POS using NFC, so the phone behaves just like a contactless card? It just works, and it works at any retailer where Google Wallet, ISIS or contactless plastic cards are accepted—no special retailer cooperation required.

That might work, and it would be the easiest path for retailers: no POS software changes required. But it would cut Apple completely out of the mobile-payments loop. There might also be PCI issues. And the first issuing bank that complained about Apple using iTunes account information for something other than iTunes purchases could turn Apple's elegant kludge into a sorry legal mess.

Of course, Apple could make sure customers sign off on the use of their payment cards when they sign up for an Apple mobile-payments scheme. That's fine for new customers (and because no current iPhones have NFC built in, every NFC payments customer will be buying a new phone).

But Apple will need NFC phones out there testing before customers can use mobile payments—remember, it all has to just work.But Apple will need NFC phones out there testing before customers can use mobile payments—remember, it all has to just work the first time a customer tries it. That means NFC iPhones will have to be available before mobile payments are announced, and when those iPhone users get an iOS upgrade that supports mobile payments, it has to just work.

No wonder it's taken Apple so long to even dip a toe into mobile payments.

There's at least one other way Apple could make users' transition to NFC payments a seamless experience. Suppose Apple buys a card-issuing bank that exists only for the purpose of issuing a Visa or MasterCard number to each iTunes account. (With $100 billion in the bank, Apple can afford to buy a bank.) Then suppose that payment account number was automatically inserted into the NFC Secure Element when Apple finally turned on its mobile payments.

At a tap-to-pay POS, the phone would behave just like a contactless card. But the retailer would receive the number for that Apple payment-card account—which would then go through the processor to the Apple-owned bank, which would immediately pass the charge onto the payment card for the iTunes account, which would go through still another processor to the original card-issuing bank for approval. Then the OK would get passed back up the line.

If the card is denied, the denial gets passed back up the line, and the customer would know why—it's a problem with the card he gave Apple for iTunes. If the customer contests a charge, that's actually contesting a charge on iTunes—which Apple will pass back up the line by contesting the charge with the retailer.

And Apple would collect interchange from the retailer and pay it to the customer's issuing bank—at least in the beginning. That means Apple wouldn't be making any money from mobile payments, just collecting large quantities of information on its users' payment-card purchases. And potentially dominating the mobile-payments market, of course. (Any interchange relief for retail chains would only come later—if at all. Remember, this is the same Apple that takes a 30 percent bite from every music, video and E-book purchase its customers make from iTunes.)

Best of all, as a mobile-payments system it just works—largely because nobody is in a position to say no, except customers.

Is this actually what Apple has in mind? Probably not—as simple as it would be for customers and retailers, it still has too many potential points of failure. But that simplicity for customers and retailers is exactly what has proven so hard for mobile payments. There are ways Apple can do it—if customers are interested.

Just don't expect it to happen until Apple makes sure that's true.