advertisement
advertisement

This is page 2 of:

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

June 14th, 2012

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.


advertisement

Comments are closed.

Newsletters

StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!
advertisement

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

StorefrontBacktalk
Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.