QR codes - or the poor man's NFC: a usability report

Pacific Coffee is the main competitor to Starbucks in Hong Kong and as such is embattled in a fierce turf war. Next to the Starbucksesque assortments of pastries and coffee, the company also sells its own RFID based stored value card. The card serves two functions - it's a reloadable stored value card that can be used for payments and it's also as a loyalty card (points) that records and manages the customers purchase profile. The customer is incentivized with rebates and the company gets the customers data.

Honeywell QR code scanner

Honeywell QR code scanner

Now, brand new is the roll out of a QR code based payment system using an iPhone eWallet-like application. Once the eWallet app is installed, the customer has to either create a profile using the card number of an existing stored value card OR buy a virtual card online using his/her PayPal account - this works directly from the eWallet.

Buying a new virtual card has some drawbacks - for one, it is not possible to specify the amount to be loaded onto the card. It's always $200 HKD (~25 USD). But more troublesome is the question of privacy as the application is mandating to know the birth date, gender and phone number of the customer. This might be normal in Hong Kong but it's certainly a concern elsewhere.

eWallet QR code

eWallet QR code

Once the profile has been created, a QR code is generated for that particular card number and displayed on the iPhone. There are many fun things one can do with QR codes, for example, scan them. In this case any QR reader app will reveal that the QR code in question represents a 100-byte string. Furthermore, one can re-create the QR code using the string and print it, thus creating multiple copies of the same QR code. I’ve tried this by making a screen shot on my iPhone, then loading that image into another iPhone app (QRReader), which was able to decipher the 100-byte string without any hassles, then I copy and pasted this into the function to create a new QR code and the result looked exactly like the original QR code. Why would someone want to do that? No real reason except to illustrate the system lacks basic security. Obviously, with an upper limit of $25 USD, this is not really a concern but it shows the constraints of such a system.
QRReader generated QR code

QRReader generated QR code


But more importantly, from a usability perspective, scanning the QR code at point of sales is not exactly a great user experience because it requires that the customer takes out the iPhone, unlocks it, opens the Pacific Coffee eWallet, watches the animation, swipes to the necessary option, displays the QR code and holds the phone towards the QR scanner. The last step turns out to be a balancing act because one can't be too close or too far away from the scanner - so far I haven't figured out what the right distance is which means it's trial and error.
I used my own generated QR code on my last two purchases and there it took several attempts to get the distance right because, I suspect, the image is too large. But it was also a test to see if my generated QR code was really the exact same as the one from the eWallet application.

After experimenting with this setup, my conclusion is that it’s a costly stepping-stone towards full NFC. Rolling out the QR scanners in all retail locations and integrating them with the existing payment infrastructure was certainly an expensive affair. But what strikes me as something overlooked is the fact that Pacific Coffee already has RFID infrastructure in place for its own cards, so a much simpler solution could have been to issue a new form factor for its existing RFID tags, such as phone stickers or key chains, while still leveraging the iPhone eWallet (remember: QR codes are passive anyway). Ultimately, this would have had the same effect for the customer but with the following benefits: It wouldn't require installation of new infrastructure, it would not confuse the customer to yet another payment scheme, it would increase security and the technology could potentially be re-used when phones are equipped with NFC (NFC has the ability to emulate tags, if the underlying hardware operates on the same frequency). As it stands, the QR system appears to be more of a novelty and I suspect the reason to implement this at all is because NFC for all its promises has not made it into the iPhone, which is still the standard.

Now, before closing this and thinking long and hard (about 3 minutes) how this system should have been conceived, I have the following to offer to Pacific Coffee: Instead of using this as a payment system, why not use it as order & pay. Or in other words, keep the virtual payment card (and the ability to get one through the eWallet) but let the user pick items on the phone, add them into a basket and check out by creating a unique QR code that not only has the virtual card number embedded but also the items that were just ordered. In other words, completely bypassing the order line. That would be a real incentive for me and it would actually work.