Apple (AAPL) just announced its new iPhone 6 models and the Apple Watch, and what to my mind is the real killer app of mobile space – Apple Pay. This service will truly revolutionize payments in the $13 trillion per year credit/debit card industry.
In an article for Seeking Alpha, I went over the basics of the Tokenization system that is now being used by the industry when possible. I explained how a Point of Service (POS) transaction with a credit card goes through the following steps:
- User presents card to cashier or swipes at cash register,
- Register sends card number (PAN) to the tokenization system,
- Tokenization system returns with a new number – the token – that will stand in for the PAN for this transaction only,
- Register sends payment details off to bank card with new token instead of the PAN. Only this token now gets stored until payment is completed and for record keeping.
Since the token is tied to the transaction, it cannot be used again. Alternatively, the token may be tied to a particular merchant. In this case it can be used again, but only by that merchant. Yet again, a token may be tied to a device, such as a digital wallet. Then that device may use the token repeatedly, but only so long as it can supply proper credentials to convince the overall system that it is indeed the correct device and that it itself has not been compromised.
What is missing from the SA article is all the processing between #2 and #3 above. I just glossed over it with some hand waving, leaving the authorization system rather fuzzy. This post is to explain that process in a bit more detail.
The main source for this is the EMV Payment Tokenization Specification – Technical Framework.
Token request system
The more complete system is shown in the following diagram. In it, the customer provides a card to the merchant.
There are a couple of particular roles in the system that need to be explained.
Token Service Providers are entities within the Tokenization ecosystem that are authorized to provide Payment Tokens to registered Token Requestors. They are responsible for building and managing their own proprietary Token Requestor APIs, Token Vaults, Token provisioning platforms, and Token registries. They are also responsible for see that issued tokens do not overlap existing Personal Account Numbers. (Remember – a token is the same length and follows the same format as normal card numbers.)
The TSP should also communicate with the card issuer in order to validate any given request.
The role of the Token Requestor may be performed by an existing entity within the system such as the issuing bank, a Card-on-File merchant, a merchant’s Acquirer (see below for definition), or a digital wallet provider. It is some agency that has properly registered according to the specifications to provide an official request with the Token Service Provider.
So the steps would be (more or less) as follows:
- User presents card to cashier or swipes at cash register.
- Register (Merchant) sends card number (PAN) via its Token Presentment service to an official Token Requestor.
It should be noted that the Merchant’s system will also send data regarding the validation of the card presenter, and that this information will be used by the system in judging the trustworthiness of the transaction. (Example: Cashier checks user’s picture ID.)
- Requester forwards the request – including the PAN – to a Token Service Provider.
- The TSP checks with the issuing bank, and then returns a new number – the token – that will stand in for the PAN for this transaction only.
Note: The TSP retains the mapping of token to the original PAN. (part of the token is an ID for the TSP.
- Requester returns this to the Merchant’s system.
- The Merchant’s system then sends payment details via its normal channels for payment, but with the new token instead of the PAN. Only this token now gets stored until payment is completed and for record keeping.
The key role here is played by the Token Service Provider. It is the one that actually generates the token, maintains the mapping data, and ultimately supplies the original PAN to the issuing bank when presented for payment.
Thus, the PAN – the real account number – is hidden and protected except:
- at the site and time of the original transaction, and
- at the time of settling the payment with the issuing bank
Digital wallets and embedded chip cards
In fact, when it comes to Digital Wallets, item number 1 is also removed as the wallet itself negotiates the token. In this case, the Merchant never sees the original PAN.
My understanding is that the cards that have the embedded ICC chip, also have a semi permanent token that is used for purchases for those merchants that have appropriate scanning equipment. This also bypasses the need for the merchant to ever see the PAN.
In both cases, if a token value is somehow compromised, then that token can be revoked at the TSP, and a new one written into the wallet or the card chip, and the original PAN is never affected.
Compromising a token is extremely difficult since they are heavily encrypted during any transmission, and with a digital wallet they are required to be accompanied by a token cryptogram that insures the integrity of the user
Even if a token is intercepted and decoded, it is always tied either to one particular transaction, to a given merchant (in the case of Card-on-File ), or to a smartcard chip, or to some particular hardware device (e.g. user’s iPhone).
Figure 2 shows more detail yet.
First, it brings in the Acquirer which is:
- An acquirer, or acquiring financial institution, is a bank that processes and settles a merchant’s daily credit card transactions, and then in turn settles those transactions with the card issuer/association. Merchants must maintain such an account to receive credit for credit card transactions… In this way, such a financial institution acquires, or serves as the intermediary, to facilitate the credit transaction and pays the merchant, less a discount fee for the service.
The flow of operation is similar to that above with just the following additions.
- It shows the fact that the cardholder may actually present a valid token if he is using a smartcard or a digital wallet,
- The role of the Acquirer is illustrated, and
- The communications channel via the Payment Network is shown, giving a more accurate representation.
Mobile NFC scenario
Finally, I add the top part of the Mobile NFC scenario. The rest is identical to the bottom of the previous figure.
There are a few things to note here:
- The device provides its own payment token, thus the PAN is never exposed.
- The data from the device includes not just the token substituting for the PAN but also:
- Token expiration date
- The formal ID of the original Token Requester
- Token Cryptogram
- Additionally, the Authorization Request includes the POS Entry Mode.
The Token Cryptogram is a critical part of the system. It is:
- A cryptogram generated using the Payment Token and additional transaction data to create a transaction-unique value. The calculation and format may vary by use case.
Since the substitute-PAN token does not change in the digital wallet (nor do 2.1 or 2.2 above), it adds an important level of security. The cryptogram is unique to a given transaction, and can embed other data that will validate that the token itself is being used correctly.
The Token Assurance Level allows for different levels of certainty that the token is being issued for a non-fraudulent purpose. It is defined as:
- A value that allows the Token Service Provider to indicate the confidence level of the Payment Token to PAN / Cardholder binding. It is determined as a result of the type of Identification and Verification (ID&V) performed and the entity that performed it. It may also be influenced by additional factors such as the Token Location.
- The Token Assurance Level is set when issuing a Payment Token and may be updated if additional ID&V is performed. The Token Assurance Level value is defined by the Token Service Provider.
Part of the security system is the POS Entry Mode which specifies the method by which the token was presented to the point of sale. This could be Card-on-File for, say, Amazon.com, or a digital wallet. When a token is created, it can be restricted for use to a given domain. Thus, a token for Card-on-File at Home Depot, could not be used except for online purchases at Home Depot itself. Tokens assigned to a digital wallet could be presented only via that wallet. Inappropriate presentment of a token would meet with rejection.
The tokenization of credit card transactions, particularly when coupled with the use of smartcards and digital wallets, creates a payment system that is immensely more secure than the current one.
Under this scenario, the recent Home Depot and Target hacks would have encountered data that for the most part would be useless.
Dear friend – if you appreciate my commentary please view my products linked below.
Elegant, Handcrafted, Genuine Leather