Contact-less Mess

Contactless / proximity payments are all the hype these days (actually last several years). They are supported and heavily marketed by pretty much all payment schemes. Mastercard has PayPass, Visa has PayWave, American Express has ExpressPay, Discover has ZIP and JCB has JSpeedy.

Similarly, the NFC based mobile proximity payments (mainly using so called 'NFC card emulation mode') are being aggressively introduced as close 'cousins' of contactless cards (just more powerful and UI capable).

At the lowest level they all build upon the ISO 14443 standard. However at higher levels all of these payment schemes have different application protocol implementation flavors and also within each of the payment scheme's specific implementations they all offer 2 different profiles / modes of operation (mag stripe emulation and optimized-EMV)

It is a nightmare and messy scenario for anyone trying to understand and introduce / rollout the the conatctless / NFC technology at the POS and try to support acceptance of each of the payment scheme's contactless cards

What POS implementors and merchants are facing is the following

a.) for each payment scheme they must plan to go through separate certification process of a contactless POS kernel and to have budget to periodically re-certify it

b.) for each payment scheme the POS kernel must automatically support 2 separate modes : mag stripe emulation and optimized EMV

c.) since all contactless transactions expose potential vulnerabilities and because each scheme has its own unique implementation twist, they must separately understand and validate each payment scheme implementation for potential vulnerabilities and mitigate those

d.) if contactless offline transactions are supported / allowed by a particular payment scheme implementation, they must understand the risks and liabilities involved

e.) they must understand how POS terminal handles failed contactless transactions for each payment scheme implementation and mode (due to card tearing at POS). Basically they must have separate test case sets for every payment scheme implementation and also for each of the 2 supported modes of operation within each payment scheme

Basically we here have 5 different competing payment scheme contactless implementations X 2 different mandatory modes of operation (mag stripe + optimized EMV) for each payment scheme ! Basically total of 10 different contactless implementations - all that for basically doing the same simple thing i.e. execute quick 'tap payment' at POS? WOW.

No wonder traditional payment industry can't help itself and lower per transaction costs. They keep building huge silos trying to protect their own turfs. There is no place for real innovation which would eventually improve the electronic payment transaction economics. Forget about it.

Contactless payments are marketed as perfect replacements for everyday low value purchases like coffee / tea, donut, sandwitch, etc ... almost every transaction amount in these payment use cases would be less than 20 $ / euros. With this kind of implementation fragmentation and heavy implementation costs (as a natural consequence) it is impossible to expect any improvement in transaction economics for low value payments.

As a result contactless payments struggle with wide acceptance. All existing contactless implementations currently in place are heavily subsidized by the payment schemes as PR bound loss leaders. They are also mainly deployed by big merchant chains which have had enough negotiating power to get favorable (mostly free) deals from issuers and schemes.

It is about time for the payment industry to sharpen the pencils, if possible unify the contactless specification (as is the case for contact EMV), put it under EMVco control and follow the same standards OR make a bold and brave move to adopt the completely different contactless implementation specialized for low value payments.