Quoted Text

Apple, retailers at odds over mobile payments
Brett Molina and Marco della Cava, USA TODAY 4:03 p.m. EDT October 27, 2014
Apple_Pay
(Photo: MasterCard)

When retailers CVS and Rite Aid disabled access to Apple Pay over the weekend, the companies kicked a consumer hornet's nest.

Angry customer tweets followed the sudden shutdown Sunday, with some Apple Pay users implying they would stop shopping at the pharmacies. Some analysts feel this brief and perhaps inadvertent exposure to Apple's near-field communications (NFC) payment model may lead to these chains' inevitable acceptance of the new payment system.

"It could get ugly for CVS and Rite Aid if consumers are asking for Apple Pay," says Patrick Moorhead of Moor Insights & Strategy, adding that the more iPhone 6 models that move into circulation, the more pressure there may be to adopt Apple Pay.

"What's more, if (CVS and others) consider getting rid of their NFC readers for scanners, they would also be eliminating the opportunity to use PayPal and Google Wallet," he says. "Ultimately, they could consider offering customers both options."


The national pharmacy chains are among several companies joining forces on the Merchant Customer Exchange (MCX), a network of retailers banding together to launch their own mobile payments service, CurrentC, which could become a potential rival to Apple Pay.


TheStreet's Jim Cramer shares his thoughts on drug retailers Rite Aid and CVS refusing to accept Apple Pay at their stores. Apple has Visa and MasterCard, the two most important companies when it comes to payments. Newslook

For retailers, the goal of CurrentC is to avoid credit card processing fees, which generally amount to 2% to 4% of each individual transaction, says research firm eMarketer.

"You could argue it's really a solution for them," says eMarketer financial analyst Bryan Yeager. "It's not so much a solution that's targeted at the customers."

Quoted Text

About EMVCo
EMVCo exists to facilitate worldwide interoperability and acceptance of secure payment transactions.  It accomplishes this by managing and evolving the EMV®1 Specifications and related testing processes.  This includes, but is not limited to, card and terminal evaluation, security evaluation, and management of interoperability issues.  Today there are EMV Specifications based on contact chip, contactless chip, common payment application (CPA), card personalisation, and tokenisation.

This work is overseen by EMVCo’s six member organisations—American Express, Discover, JCB, MasterCard, UnionPay, and Visa—and supported by dozens of banks, merchants, processors, vendors and other industry stakeholders who participate as EMVCo Associates.

EMVCo is managed by the Board of Managers, which is comprised of two representatives from each of the member payment systems.  The EMVCo Executive Committee, also managed by payment system representatives, provides guidance on EMVCo’s long-term strategy.  Various Working Groups complete EMVCo’s work, and decisions are made on a consensus bases to ensure card infrastructure uniformity.

In 2010, EMVCo launched the EMVCo Associates Programme (EAP), which has established an invaluable mechanism for key industry stakeholders to provide input to EMVCo’s Board of Managers, Executive Committee, and Working Groups. A range of organisations—including payment systems, networks, banks, processors, vendors, and more—contribute their expertise to improve the EMV Specifications.

1 EMV is a registered trademark in the U.S. and other countries, and is an unregistered trademark in other countries, owned by EMVCo.

Quoted Text

Making Sense of the EMV Tokenisation Specification
Posted on October 19, 2014 by Francisco Corella
Apple Pay has brought attention to the concept of tokenization by storing a payment token in the user’s mobile device instead of a card number, a.k.a. a primary account number, or PAN. The Apple Pay announcement was accompanied by an announcement of a token service provided by MasterCard and a similar announcement of another token service provided by Visa.

Tokenization is not a new concept. Token services such as the TransArmor offering of First Data have been commercially available for years. But as I explained in a previous post there are two different kinds of tokenization, an earlier kind and a new kind. The earlier kind of tokenization is a private arrangement between the merchant and a payment processor chosen by the merchant, whereby the processor replaces the PAN with a token in the authorization response, returning the token to the merchant and storing the PAN on the merchant’s behalf. In the new kind of tokenization, used by Apple Pay and provided by MasterCard, Visa, and presumably American Express, the token replaces the PAN within the user’s mobile device, and is forwarded to the acquirer and the payment network in the course of a transaction. The purpose of the earlier kind of tokenization is to allow the merchant to outsource the storage of the PAN to an entity that can store it more securely. The purpose of the new kind of tokenization is to prevent cross-channel fraud or, more specifically, to prevent an account reference sniffed from an NFC channel in the course of a cryptogram-secured transaction from being used in a traditional web-form or magnetic-stripe transaction does does not require verification of a cryptogram. The new kind of tokenization has the potential to greatly improve payment security while the payment industry transitions to a stage where all transactions require cryptogram verification.

The new kind of tokenization is described in a document entitled EMV Tokenisation Specification — Technical Framework. We have looked at the document in detail and we report our findings in a white paper. The document is, to be blunt, seriously flawed. It leaves most operational details to be specified separately in the message specifications of each of the payment networks (presumably MasterCard, Visa and American Express), and it is plagued with ambiguities, inconsistencies and downright nonsense. Nevertheless, I believe we have been able to come up with an interpretation of the document that makes sense for some of the use cases. (Other use cases cannot be made to work following the approach taken in the document.)

Here are the conclusions drawn by the white paper.

Apple Pay use case. In the use case that is probably implemented by Apple Pay for both in-store and in-app transactions, a token service provider provisions a token and a shared key to the mobile device. When it comes to making a payment, the merchant sends a cryptographic nonce to the device and the device generates a cryptogram, which is a symmetric digital signature computed with the shared key on data that includes the nonce. (A cryptographic nonce is a number that is only used once in a given context.) The merchant includes the token and the cryptogram in the authorization request, which travels via the acquirer to the payment network. The payment network asks the token service provider to validate the cryptogram on behalf of the issuer and map the token to the PAN; then it forwards to the issuer a modified authorization request that includes both the token and the PAN but not the cryptogram. The role of payment service provider can be fulfilled by the payment network itself without essentially altering the use case.

Alternative use case with end-to-end security. As an alternative, the issuer itself can play the role of token service provider and provision the token and shared key to the mobile device, just as it provisions a shared key to a chip card in a non-tokenized transaction. (The issuer may also provision a token to a chip card; the token is then stored in the chip while the PAN is embossed on the card.) In that case the payment network forwards the authorization request to the issuer without replacing the token with the PAN. The transaction flow is essentially the same as in a non-tokenized transaction. The cryptogram is validated by the issuer, preserving the end-to-end security that is lost when the cryptogram is validated by the payment network or a third party playing the role of token service provider.

Alternative to tokenization. Instead of provisioning a token to a mobile device (or a chip card), the issuer can achieve essentially the same level of security by provisioning a secondary account number and flagging it in its own database as being intended exclusively for use in EMV transactions, which require cryptogram validation.

If you have comments on the white paper, please leave them here.