Some quick context: For years, advocates of NFC (and RFID contactless payment before that) mobile payments have argued that it will be much faster than magstripe. The practical reality is that the time for the transaction processing is pretty much going to be identical—about two seconds—for all of the above.
The real difference in time—and there truly is one—has nothing to do with IT, authentication or any other technological issue. It's the practical reality that shoppers tend to keep credit and debit cards buried deep within their wallet/pocketbook, whereas they tend to either have their mobile phone in their hand or in a convenient outer pocket, easily within Bluetooth range. That extends the debate from whether a swipe or a wave is faster to whether the entire mobile payment process is easier and faster because of how people use mobile phones.
Against this backdrop, we have a recent blog post from one of the more sophisticated retail tech advocates out there, David Dorf, who toils by daylight as the senior director of technology strategy for Oracle's retail group. (Quick reality check: Most bloggers who work for major vendors are extensions of that vendor first and a blogger second. Dorf is that rare breed who isn't.)
Enough of that nice stuff. Dorf's argument—which admittedly is a trifle bit self-serving this time (although that doesn't make it not true)—is that NFC's value is not in merely processing a single transaction. It's when the next step is taken and it simultaneously handles CRM/loyalty, coupon and payment details.
Dorf reported that Oracle ran some internal NFC experiments and "we found it to be too time consuming to open each of three files to read the contents representing loyalty, coupons and payment. It took roughly two seconds per file, which doesn't sound slow, but it moves the consumer from a 'tap' to a 'tap and hold.' To avoid this issue, we combined the data from all three files into a single one, using separators between the data types. This works well, enabling the consumer to simply tap to handle the combined data exchange with POS. But realistically, the data is owned by three different organizations, and they will want their own files."
Fair enough. Dorf then reported on some glitches encountered during the data-write portion.Fair enough. Dorf then reported on some glitches encountered during the data-write portion. "Writing data takes a big longer and moving the phone away from the reader during a write operation will cause an error. When a coupon is redeemed, we may want to erase it, or add a new one during checkout. This extends the time even longer. The fastest approach might be to simply store a read-only unique identifier on the phone that a third party can link to a loyalty number, list of coupons and payment choices on some far away server. Forcing all the work to the back-end servers would certainly simplify the role of NFC but also require the POS to be online."
Dorf's point about politics and turf control is a valid thought. But the fear goes both ways. How many retailers will fear opening up their CRM databases, wondering if the details might possibly leak back to the processor, to the phone (What? Apple might record something private? One can't imagine such a thing!) and possibly wind up in the hands of a rival?
All of this gets us back to the question, "How much of a delay will this deliver?" The practical point is that consumers will likely accept any reasonable delays, as long as the offerings are ubiquitous enough. Remember the early days of ATMs and all of those consumer complaints? Whatever happened to those complaints? The consumers got used to it and the banks—being banks—smiled and ignored them.
One person who had strong concerns about what Dorf posted was J.P. Norair, the chief architect with Dash-7, a non-profit wireless data alliance with member manufacturers, systems integrators and developers. Norair posted a comment to Dorf's piece, where he argued that "the biggest problem with speed isn't the NFC, which is faster than older passive standards, but crappy middleware and crappy, message-based middleware protocols. The comm lag between the reader and the thing that is issuing commands and processing the data is the biggest source of slow performance. Taking NFC to 1Gbps (which isn't actually possible) isn't going to solve the performance issue."
Norair also pointed the finger at "so many serial lines between POS and POP terminal still run at 9600 bps." and lots of "messaging protocols require full circuits, all the way to the database, for even the most mundane commands."
In a telephone conversation on Wednesday (April 20), Norair said his key concern is that too many POS systems today are designed to make a 200-milisecond (one-fifth of a second) round-trip hit for every individual task. "It needs 3 to 6 hits just for the authentication alone. The rest—for user data elements, preference setting, cookie equivalents, timeouts, things like that—take at least two and maybe five more hits," he said. Instead, Norair argues that it's better "to write a middleware protocol instead of hitting the server every time. A cloud model doesn't scale wirelessly. And everything on some central server, that doesn't scale at all. Some intelligence has to be brought down to the endpoint, to get latency down."
The problem with Norair's argument is: To what end? That's a lot of effort and money and for what benefit? Will shaving off fractions of a second—and at most, maybe one full second—make any meaningful difference to the shopper's experience?
Is a customer that hard to entertain for two seconds? Couldn't that time be filled with a "paper or plastic?" or "do you have your club card today?" question?
IT people often strive for the ultimate in efficiency and needless delays are maddening. In this instance, though, the practical business reality is to just endure those frustrations. If the customers won't notice, it's really hard to cost-justify it.