News By Tag
News By Location
Will Apple Pay kill the QR code?
However, with Apple having just 'raised the bar' significantly in its launch of ApplePay it will undoubtedly remove the possibility for the QR code to ever gain any ground - or to make any business case again as a payment enabler. The ApplePay infrastructure is very clear now (well it is not clear at all, but we can draw together the following parts of the infrastructure:
a) The adoption of EMV and a well-practiced security is adopted.
b) NFC enabled transactions (whether you like it or not - whether it has an EU or USA adoption rate) - which ensures that the NFC standard is adopted, and they the EMV Co protocols and encryption is present.
c) Tokenisation - to protect the personal details
d) Two/Three factor authentication - i.e. using the scanned fingerprint (or whatever is scanned to validate the transaction)
e) A reduced costs (interchange fee) and liability protection for pretty much all parties.
So why not do any of this with a QR code? Technically, this is almost all possible, but of course technical possibility and a good idea in the QR codes won't make this work. Using a QR code produced by a device (that the consumer has) would look pretty, but would mean that:
- The customer has to enter the transaction details to validate - unless another way of communicating with the merchant was created and standardised globally.
- The protections that are in the chip on a card and in the secure area in the device where the card details are stored including floor limits, counts, rules, service codes and resets would all be bypassed.
- The secure part of the chip used and set-up by Apple would have to be accessible by developers to create QR codes - which Apple should never allow (due to a compromised of that secure element (and probably not allowed by the banks/schemes either); and because they would probably not want others to use their rails - due to commercial protectionism.
- Retailers would have to create new software and protocols for reading the QR codes at the points of sale, and then create EMV CO protocols to be used to secure the transactions - which of course would preclude the retailer validation or a two way dialogue with the card / secure element.
- And ALL vendors would have to build standards for this and compete with their proprietary protocols and add massive costs for retailers.
- 3FA or further authentication validation would be impossible/hard to introduce without the EMV / NFC standards backbone.
This creates the underlying problems in:
a) The EMV Co and NFC standards, which require that there is a 2-way hand-shakes and communication with the device and the secure element and a decryption process would be circumvented.
b) The card schemes, who will have required the NFC to be adopted as the communication vehicle for the transactions to be permitted in Apple Pay would be removed,
c) The issuers to allow the transaction to attract the interchange concession, to be transacted using the EMV Co / NFC standards and a channel that can be used to validate the transaction and ensure closed security would be gone.
Accordingly, the security, payment guarantees, standards and security would all be removed or circumvented. So QR codes in the transactions for payments can now never be progressed - as Apple has surely killed it off in one single stroke by introducing something far superior, far more future proofed and adopting all the latest and global 'industry standards' to do this through - in a way that no-one else could have achieved and made to happen.
QR codes were only a transient interim technology, that only had a place in small ways to bridge the gap that has now been theoretically bridged.
We have heard a LOT about the impact of the ApplePay announcement on who/what will be affected, but one thing is sure: It has killed the QR code as a payment vehicle - but of course it will 'live on' as a very good 'informational application' tool where it has been used thus far - i.e. to stop people needing to type various things into a device.
Adopting QR code developments with access to secure elements in the device CHIP is NOT an option, and it is VERY VERY VERY VERY VERY unlikely that the access to the secure element (i.e. the underlying security) will be accessible to TP developers in this way either.
Author of this article is Bill Trueman who is the director of RiskSkill.com a global risk review and risk management organization. For more information visit http://www.riskskill.com/