Oracle: Is NFC too slow for payments and coupons?

Business software firm Oracle has been conducting experiments with NFC and has found it “too time consuming” to use at the point of sale, the firm’s David Dorf has reported.


Oracle asked it if was really achievable to replace loyalty cards, coupons and payment cards with a single tap of the phone. In its experiments it found that the time taken in opening each file caused too much delay:

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.

So far we’ve just talked about reading data. Writing data takes a big longer, and moving the phone away from the reader during a write operations 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 identified 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.

Have NFC World readers experienced similar issues, or are there better ways of doing this that result in a faster overall transaction time?

Next: Visit the NFCW Expo to find new suppliers and solutions

2 comments on this article

  1. Why does the interaction should happen only at POS? Cant the model be such a way that the consumer starts applying the coupons while shopping, like while in the aisles using their smartphones?

    Here is how it should work – When the consumer picks up goods from the aisles, they scan the product and apply discounts/coupons and validate them – a one time use “unique token” is issued and kept in the servers. This “unique token” will tie all the coupons to the purchase, and will invalidate all the coupons once a purchase is confirmed by the store. Back to the lines, once the consumer reaches the POS for final payments, they just keep scanning each item, cross checking all the items and final price is applied. Once the payment is done through NFC, the backend servers will invalidate the “token” and thereby the associated coupons.

    By having a distributed architecture like this, heavy reliance on interaction at the POS is limited.

  2. Two seconds per file? How large is your file? How many bytes are you reading and writing? How much time spent in the ISO-14443 communication protocol, how much time spent by the smartcard in manipulating the data, how much time spent by the POS in processing the data?

    Why it only takes 300ms for a transit smartcard to finish a transaction and it takes your 2 sec per file? Why blame NFC?

Comments are closed.