Our Blog

Apple Pay brings new problems for acquirers

It’s now clear that all the pieces that Apple needed for its launch into mobile payments – via Apple Pay – fell into place with precision.

Apple Pay

 

If Tim Cook needed the perfect technical blueprint for Apple Pay then he got it last March when the EMVCo tokenization specifications (it’s a large PDF – but keep it open, it comes in useful later in this blog) were unveiled.

The specifications – rubber-stamped by EMVCo – will likely enable Apple to change the mobile payments marketplace. At its iPhone 6/Apple Watch launch in Cupertino, Apple revealed their Apple Pay partners: Visa, MasterCard, and American Express. Let’s take a look at the standard for EMVCo’s tokenization:

“EMV Specifications based on contact chip, contactless chip, common payment application (CPA), card personalisation, and tokenization . . . is overseen by EMVCo’s six member organisations—American Express, Discover, JCB, MasterCard, UnionPay, and Visa.”

The above statement is taken from EMVCo’s own website. Apple Pay launches in the US in October 2014 and three of the big four US card schemes are already involved (at the time of posting Discover were in talks with Apple to get involved). The card schemes are on their side and the technical specifications make Apple’s entry into the mPOS marketplace all the smoother.

What has changed with EMVCo’s tokenization specifications?

Last March’s EMVCo tokenization specifications established the concept of a ‘token requestor’

The card schemes have also (incredibly) allowed Apple to brand the payments service as their own. It’s Apple Pay now and that will never change. Apple Pay, by the way, is the first implementation of the new EMVCo tokenization specifications, which begs the question as to whether Apple were involved in the drafting of the specifications in the first place.

A superb post from Richard Brown – on his ‘Thoughts on the future of finance’ blog – sums up what happened back in March. He points out that the key to Apple Pay was a paragraph on pages 26-27 in the EMVCo tokenization specifications: “Payment Token Requestors may be traditional participants within the payments industry or newly emerging participants. Potential Token Requestors include, but are not limited to: Card-on-file Merchants; Acquirers; Acquirer Processors, and payment gateways on behalf of Merchants; Payment enablers, such as original equipment manufacturer (OEM) device manufacturers; Digital wallet providers, and Card Issuers”.

“Token Requestors will be required to register with Token Service Providers and comply with their proprietary registry requirements, systems, and processes. After successful registration with a Token Service Provider, the Token Requestor will be assigned a Token Requestor ID.”

Apple – the ‘newly emerging participant’ – is now the token requestor and the card schemes are the token service provider (TSP). As Richard Brown points out later in his blog post: “Imagine you were trying to build something like Apple Pay. This is exactly what you would need. You’re faced with consumers with cards from thousands of issuers and you want to create tokens that can be processed by merchants who use one of tens of acquirers”.

“You need a system that gives you a token that all acquirers can process and which the schemes can route to the right issuers… it makes sense that it be the schemes who provide such a services.”

Problems created for acquirers with Apple Pay

The EMVCo tokenization specifications create problems for acquirers in that crucial card identification information is no longer available: for example, what currency the card is issued in. With Apple Pay, the customer’s card details are never revealed – instead a token is used, authorised by Touch ID on the iPhone 6.

Once payment is authorized via Touch ID, the merchant receives the consumer’s payment token from the consumer’s iPhone 6 via NFC. The payment token encapsulates the information needed by that merchant to complete a payment transaction.

This payment token includes a cryptogram, unique to that specific purchase, that can be decrypted with the merchant’s private key or when the payment information is transmitted to a payment processor’s server that has the merchant’s private key.

Merchants intent on accepting Apple Pay payments will have to install a reader at checkout. These NFC readers are currently being used by fewer than 10% of merchants. This number was likely to rise prior to the introduction of Apple Pay with the EMV request to upgrade by 2015.

The replacement of the card number with a token will present a number of challenges to acquirers, mainly related to the missing card number. The first 6-12 digits of a card number are often used by acquirers, for example, for Dynamic Currency Conversion (DCC) purposes.

According to respected payments industry commentator Tom Noyes “the network planning on tokenization is just tremendous. There are no changes to the network, using authentication messages as the mechanism for issuers to approve and bind the token. Apple token assurance information will be used in the existing card data fields – all just fantastic stuff.” Noyes added in a recent blog post: “In my view this is a giant leap beyond EMV chip-and-pin, and is now (by far) the most secure payments scheme on the planet.”

While EMV practically ensures that the individual performing the transaction has the physical card. We feel that the challenge for Apple Pay will be the security of registration.

The EMVCo specifications propose that tokenization be standardized and, according to Noyes, implies strongly that it should be the schemes who perform the work, not the acquirers. This, in theory, saves work for acquirers but how will acquirers determine, for example, the bank identification number (BIN) of a credit card?

This paragraph from page 34 of the EMVCo tokenization specifications (PDF still open?) is interesting:

“Payment Tokens that are generated SHALL include a Token Expiry Date. The Token Expiry Date SHALL meet the format requirements of a PAN Expiry Date. Payment Tokens SHALL be generated using Token BINs in such a way as to ensure the preservation of product and other attributes of the PAN throughout all existing transaction processes.”

Does this imply that DCC must continue to be supported, as the currency of the card would surely fall under the ‘other attributes’ category? The BIN can be used to look up ancillary information (such as the currency of the card). Merchants and acquirers who offer DCC to their customers may not be able to offer this service to customers using Apple Pay, unless:

  • The token is structured so as to preserve the original bin number (i.e. the first 6 digits are preserved), or
  • Apple provide ancillary information to go along with the card number (i.e. the issuer and the currency of the card).

Section 6.2 of the EMVCo payment tokenization specification technical framework covers ‘Routing and Account range tables’, but simply states that account range tables need to distinguish token BINs from traditional BIN ranges. Aviso believes that acquirers will encounter problems with this – problems we’ll go into in more detail in future posts.

Next post

We will revisit the payment industry issues created by the introduction of Apple Pay. Our next blog will focus on the technical issues that await Apple Pay when introduced in Europe.

Contact us

For more information on our products and services contact us at info@aviso.io, or follow us on Twitter and LinkedIn.

Related posts