The recent announcement by Apple that it has incorporated an NFC chip into the latest iPhone (at Last) and that this is supported by a payment service, Apple Pay, is good news. The mobile payment systems seemed to have stalled for a while until this happened. This, combined with the adoption of Chip & PIN by the US, means that US retailers are finally starting to upgrade their POS terminals, and support for NFC is mostly coming along with adoption of chip & PIN.
The main part of the Apple announcement is that the Apple Pay system will support Tokenisation. This is not well understood out there so I will attempt to explain what this actually is and how it works.
Registration process. The first step is to create a token and associate it with an account. On the Apple Pay system you send a photograph of your card. I presume this is then processed by OCR to read the PAN from the card and then Apple servers submit this and request a token for the card. A token looks exactly like a normal card number, the first 6 digits are the Bank ID Number (BID) but this will be from a specific token range for that issuing bank. Apple then stores this token number on the phone.
When a transaction happens the normal NFC protocols are followed, but the token number is presented to the reader, rather than the subscribers’ PAN. This is then processed in the normal way by the retailer, and sent via the acquiring bank to Visa scheme systems for processing. The Visa systems recognise the BIN number as a token range and pass the token number to a tokenisation system. This will ten apply the special token rules to the transaction. In the case of Apple Pay the transaction will only be accepted if it came from an iPhone. It determines this from elements in the transaction record provided by the merchant.
If the transaction passes these tests then the transaction is passed back into the normal processing, but with the customers actual PAN replacing the token. Normal processing then presents this to the issuing bank for authorisation and collection.
The consequence of this is that the retailer will not be able to correlate transactions that happen with the real card and those where a token is presented. Not so much of a problem at the moment when Apple Pay is the only service. But say you had 15 different tokens, and presented different ones, this is going to confuse retailer systems that analyse sales patterns. This is a very important part of large retail operations, and an increasing part of smaller operations.
Then we come to the competition a number of large retailers in the US are launching their own mobile payment system. CurrentC is the brand name of the service offered by Merchant Customer Exchange. This differs from all the above, in that it expressly tries to maximise the identity information that it retains so retailers can analyse the sales patterns. It also bypasses the Card schemes, to minimise transaction processing fees.
For retail operations one of the major expenses is their transaction processing fees. This is an extremely complex area. The fee structures charged by the card schemes run to thousands of pages of rules, exceptions caveats and the like. But basically a retailer will need to spend a percentage of their revenue on these transaction fees. For large retailer this could be as low as 0.1%, but more normally it would be more like 1% to 2% for POS transactions. These will vary depending if the card is a credit or debit card, and every nuance of the processing.
These fees are the main driver behind the CurrentC scheme, as this will connect direct to banks, transaction fees for the retailer owned MCX system will be much lower. But they will have to attract customers to their system. At the moment these retailers seem to be alienating their customers by refusing to accept Apple Pay transactions.
Many Issuers offer various reward schemes, as part of their consumer offering. These are paid for largely out of the processing fees they charge. So a payment transaction for a product will be presented for say $15.00 this will be deducted from the customer’s account, but the issuing bank will only pay 99% of this to the acquiring bank, who will then take their cut before passing onto to the retailers account.
references:
Apply Pay https://www.apple.com/apple-pay/ https://en.wikipedia.org/wiki/Apple_Pay
CurrentC http://www.mcx.com/ https://en.wikipedia.org/wiki/Merchant_Customer_Exchange
EMVCo http://www.emvco.com/
– Tokenisation Standards http://www.emvco.com/specifications.aspx?id=263
– EMV Contactless http://www.emvco.com/specifications.aspx?id=21
Google HCE
– SDK https://developer.android.com/guide/topics/connectivity/nfc/hce.html
– Wikipedia https://en.wikipedia.org/wiki/Host_card_emulation
Transaction Fees
– Overview: http://www.cardfellow.com/blog/credit-card-processing-fees/
– POS 1%-2% Large retailers 0.5% http://www.transfirst.com/processing-rates-fees/retail
– Mobile / eCommerce 2% – 3%
– Fraud 0.5% if well managed
Glossary:
Issuing Bank the bank that gives the card to the customer
Acquiring Bank the bank that processes the retail transaction
PAN Primary Account Number, this is the credit card number
BIN Bank Identification Number this is the first 6 digits of the PAN
News reports:
http://www.theverge.com/2014/10/25/7069863/retailers-are-disabling-nfc-readers-to-shut-out-apple-pay
Following Apple’s announcement last month, both Wal-Mart and Best Buy confirmed to The Wall Street Journal that customers would not be able to use the system in their stores. Earlier this week, a leaked internal memo from Rite Aid revealed that the drug store chain was modifying or disabling its NFC readers, preventing access to Apple Pay (and other systems, like Google Wallet and wireless carrier-backed SoftCard, which also depend on the contact-less technology). A representative later confirmed the news to iMore. Today, CVS followed suit and shut out Apple Pay, according to reports. Both will support CurrentC on launch next year. The companies have not immediately returned requests for comment.
From a publicity standpoint, a data security issue is one of the worst things that could happen to CurrentC right now. The app exists only in a private testing mode, but its plans call for a public launch sometime next year. Since CurrentC bypasses credit cards, the system will ask millions of shoppers to upload sensitive banking information to its servers. Users will also be asked to embrace features that allow CurrentC to track their physical location, information about their transactions, and other data.
MCX’s privacy policy says it may make commercial deals to acquire personal data from third parties, combining that with data it is gathering on its own to build its service. Dekkers says that anyone wishing to remain completely anonymous while using the system will be able to do so.
Anonymity is the default setting for Apple Pay, which makes a selling point of its inability to collect information about transactions. It’s a limitation that irks even some of its supporters. Apple also uses a technique called tokenization: temporary codes, rather than credit card numbers, are used to process payments, which can’t go through unless a user also scans a thumb with an iPhone fingerprint reader.
Posted by Stuart Ward 
Stuart's Weblog 