Original URL: http://www.theregister.co.uk/2012/09/14/isis_delay/
ISIS puts off US NFC pay-by-bonk bid
We said summer launch ... but never said which summer
A consortium of US operators backing the ISIS electronic wallet platform has admitted that a promised "summer" NFC payments launch is not going to happen, but isn't saying what the new schedule is or even if there is one.
ISIS was supposed to launch in Salt Lake City and Austin during the summer, but with the official end of summer only a couple of weeks away the operator-backed consortium has admitted that the schedule has slipped and won't say when the public will be able to start using ISIS.
What the consortium is saying, in various statements and interviews, is that the delay won't change the technology or business model which ISIS will eventually offer. That's a relief as major changes have already been made in the hope of making pay-by-bonk more attractive to banks and credit-card companies. There's not much more that could be altered, so the delay is just about putting all the pieces in place.
ISIS is an electronic wallet platform, stored on the SIM but standardised between AT&T, Verizon and T-Mobile, so companies can develop an ISIS-compatible instance of their payment/loyalty/ticketing cards and deploy across the networks.
The UK's Project Oscar, which recently got EU approval, attempts to achieve the same thing and similarly locks out one mobile operator (Sprint was the unlucky mobe-co in the US, Three was left out the UK). Pay-by-bonk in the UK is eased by the fact that almost all cards are already bonkable, and terminals are rapidly becoming bonk-compatible, so phones will slot into that existing infrastructure. The US, on the other hand, will need greater investment to make it happen.
Getting that infrastructure in place is probably what's delaying the ISIS deployment. Although the consortium hasn't admitted that, it has failed to provide any alternative explanation. Wanting to get it right is admirable, and with Apple still eschewing NFC and Google Wallet stumbling along one might conclude that the delay won't be significant, but that would miss just how clever Google's new approach is.
Rather than storing instances of payment cards on the phone, Google's new approach is to store one (Google-branded) card on the phone and put all the customer's credit cards in the cloud. Payments are made from that one card, which works even without connectivity, with the balance being deducted from the customer's credit card as soon as connectivity is available.
The beauty of this is that the banks don't need to create Google Wallet versions of their cards, and now that the card companies are signing up to Google's "Save To Wallet" system, the end users don't even need to know all that is happening.
Save To Wallet is now embraced by Discover, Barclaycard US and half a dozen others, according to NFC World. The system provides a button on the card-issuer's site which copies the card details into Google's cloud with a single click. But even more interesting, it copies the card's logo into the Google Wallet application on the phone, so when the user makes a payment they can select which card to use just as though the card were stored on the wallet, which it isn't.
In fact the tap notifies Google that this payment should be deducted from that card, when connectivity is available, but the bonking payment is still made using the Google-backed card embedded in the phone.
Whether that model will extend to loyalty cards and the ticketing applications which are expected to drive NFC adoption is debatable, but for basic proximity payments it removes the need for each card issuer to create their one bonking app while maintaining the illusion that they have one - a perfect result for all concerned, except ISIS and Oscar, which are both planning to make money hosting those very apps. ®