I can promise one thing now at the very beginning: this will be the longest article of the series and I will never again venture to engross the attention of the dear readers for such a long time, but this part is so coherent that I don’t want to split it up. Nevertheless, I trust that it is worth reading.
When presenting the contact and chip transaction, we have reached the point where the terminal have already mapped what kind of payment applications can be found on the bank card. It is not typical at all, but if more than one of them can be used in the given situation, the terminal will offer the buyer to choose one of them. Then the cardholders can decide how they want to use their plastic, either as a debit card limited to domestic payments only, or as an USD-denominated credit card. This solution is not really widespread and we generally use separate cards for these purposes, however, it also demonstrates what all our chip would be capable of.
Let us stay at the single application model known for most of us, when our terminal itself chooses the payment application. As I have already mentioned before, from here a complicated series of operations is started by the assistance of the card and the terminal, which is not a coincidence, since every payment transaction for them is like a blind date. Naturally, it is known of both that they want THAT only – to carry out a payment transaction – but they have to be convinced in advance, whether they can trust in each other and the other is able to meet their expectations.
As a first step, the chip offhand responses to the application selection with giving a lot of valuable information and tells, for example, what human languages can be used by the terminal during the communication with the card holder. Neither do I feel bad if I don’t have to fight with the local language abroad, but at once I can see the English language supported by the ATM on the display, if the device was not prepared for my own mother language. In addition, the data received back also convince the accepting device of its ability to run the payment application on the chip, and the transaction can start.
Then the terminal resets its storages to default settings and issues an instruction to the card (’Get Processing Option’) in order to get new important information. In the answer the card tells about itself what authentication procedures it is able to use and specifies which files written on the chip the terminal should read the data from to continue the transaction. The latter one which is a list of the files needed (’Application File Locator’) is important, because different values have to be used when a contact payment transaction starts or we have already put the card into the reader. It can be solved if the chip gives different list to the terminal in different cases, so it will be able to work with the values that conform to the given conditions.
After that, the terminal smoothly reads through the previously received file list by using ’Read Record’ instructions , and obtains the data needed for the transaction from the chip by interpreting the records found there. These records contain the values not in bulk but structured (if you are deeply interested in it, you can search for it on the internet under the name of BER encoding), where each value is described by a so-called TLV, which is an acronym derived from the English designation: ‘Tag-Length-Value’. Accordingly, hexadecimal character series that have been read from files are to be interpreted in a way that first we find a tag (label), and then we can see the length of the data, and finally the data itself. Usually it is followed by a new tag, then comes the length and the data again. I said ‘usually’, because the BER standard is a bit more difficult and there are, for example, specially arranged data groups, but it is really important for those people only, who deal with designing and parameterizing card profiles, for me and some of my colleagues, for instance.
The EMV standard and card corporation specifications assign a tag to each data field, for example, the country code of the issuer bank (’Issuer Country Code’) is stored by the well-sounding 5F28 tag. The currency managed as default by the application (‘Application Currency Code’) is stored by the sonorous 9F42. There are many of these small labels, i.e. tags, and everything must be written on the chips in a specific way, when the bank card is finished in the ‘bank card factory’. For the sake of order it should be noted, that there are some special data that are not stored in the aforementioned files, but they must directly be read from the chip by using ‘Get Data’ instructions. The point is that all information which must be shared by the card holder’s bank with the accepting device must be obtained by the terminal from the chip as described above.
It’s maybe surprising, but nothing has happened so far between the card and the terminal, which would be a great secret, and anyone who is skilled in it can even alone carry out the above operations at home, using own bank card without having any authorizations or knowing any secrets. But after that the terminal will have the opportunity to authenticate the data in offline mode, when it can verify the authenticity of the values received from the card without asking it from anyone else, for example from the issuer bank in online mode. There are several methods to do it. The accepting device selects from them on the basis of how it learned the capabilities of the chip as described above during the ‘Get Processing Option’, but offline authentication of the data always happens with verifying digital certificates. But more details about that will be written later in another chapter.
In the next step the terminal performs additional checks (’Processing Restrictions’) to verify if the chip meets particular criteria for the transaction, for example, if it has not expired, or if the card can be used for cash withdrawal or for purchase only, when we are standing in front of an ATM.
If there are no restrictions on the transaction, the card holder can be identified (’Cardholder Verification’), which means that now we need to convince the accepting device that we don’t want to purchase or withdraw money with using a card of someone else. There are also several possibilities for it. When reading out the records, the chip has already given a list to the terminal, which is the so-called CVM list (’Cardholder Verification Method List’). The issuer bank sets up an order of priority according to which it wants to have the possible verifications carried out. Here is a typical CVM list next below:
- Online PIN verification
- Offline PIN verification by encrypted PIN
- Offline PIN verification by non-encrypted PIN
- Signature verification
- No CVM
In case of a CVM list, the terminal first asks for the PIN and sends it encrypted to the host for verification, if the device is online-compliant. If there is no contact, it instructs the chip to verify whether the PIN corresponds with the value stored on the chip. It’s safe because the chip never gives out the PIN stored on it but only answers the question to the terminal, whether it is considered to be good or not, and no one can ever read out the PIN itself from the card. This verification method is called offline PIN verification, where encrypted data exchange is also the preferred method in this case, since it precedes the non-encrypted one on the list. If, for any reason, it is not possible to verify the PIN, because, let’s say, the PIN pad by the terminal is out of order, the accepting device prints a slip to be signed by the card holder and the salesman can compare it with the signature on the back of the card. (I see, so that’s why our card is invalid without our signature on the back of it…). Although it is not mentioned on the list, it may happen that the accepting device reads the PIN and then asks for a signature, but such a strict method is rarely used by the card issuers. In our example, after signature verification, there is only one line, i.e. ‘No CVM’ which is a special case of transactions. It basically determines the behavior of the card, as it will be less tolerant for carrying out further operations, because the card holder could not be verified.
This is followed by the risk management of the accepting device (’Terminal Risk Management’). This sounds pretty ugly, but actually it just means that the terminal analyses some circumstances, based on the data received from the card, principally to decide whether they can complete this transaction together with the card (offline transaction), or rather transfer the risk of acceptance to the issuer (online transaction). If, for instance, the transaction amount is too large, or the card has not been verified by the host for a very long time (i.e.: many transactions before), the terminal will surely initiate online transaction, if it is capable of that.
By the time we get here, the accepting device has done its utmost to analyze the circumstances and now it’s time to make a decision on (’Terminal Action Analysis’) what should be the course of the transaction after that. There are three options to choose:
1. Accept the card transaction offline
2. Initiate online transaction
3. Reject the transaction immediately
Its decision will be shared with the card in form of an instruction (’1st Generate AC’ command), and it may be also surprising that it will instruct the card to make the final decision. For this, of course, the terminal provides a lot of data to the chip, based on which the card can carry out the pre-decision review (‘Card Action Analysis’). In addition to many other data, the chip will get the amount and currency of the transaction, type and country code of the terminal, as well as results of the terminal verifications (‘Terminal Verification Result’ and ‘CVM Result’). The chip now knows everything about the current transaction. For instance, it can see which country the terminal is from, so it can estimate whether it is an international or a domestic transaction. It can see the amount and that’s good because, with its own counters, it can further refine the decision to be made on the course of the transaction. In the chip there is, for example, a box to store the amount we have spent offline since the date of the last online transaction. The terminal cannot know it but the chip can, and if the accumulated amount exceeds the adjusted limit, the chip will not be willing to complete the payment operation with the terminal, but it will ask for online acceptance from the card issuer, i.e. from the host. The point is that, similarly to the terminal, the chip will make a decision on the course of the transaction, although its hand is tied (… or its foot? We usually hear about the foot of a chip, but who knows what the evolution has in store?):
A. If the terminal has previously decided to refuse the transaction, the chip cannot do anything else and then no payment is made by our card.
B. If online transaction is needed according to the terminal, the card can agree to it or refuse the transaction.
C. If this transaction is not considered too dangerous by the terminal and the less secure offline transaction is enough, the chip may also agree to it or may tighten up, and the chip itself may initiate online operation, or may simply refuse the transaction.
The two offline operations are closed relatively simply, since the terminal either takes note of the refusal of the transaction or accepts the successfulness of the operation and accordingly performs the usual operations (e.g.: prints the receipt which is well-known for all of us), but in this case, the card issuer bank is not asked what opinion it has of the transaction. Here I would like to note that my series does not cover the topic on how the accounting is implemented between the merchant, the financial institution that operates the accepting device and the card issuer bank, but, of course, result of the offline transactions will also become known to the card holder’s bank sooner or later.
However, the online operation is much more interesting, because the chip does not only simply communicate its decision to the terminal, but it also compiles a message to the host at once. From now on, first and foremost, after evaluating the information received from the chip, the host verifies whether the incoming request is justified, but I will write about it in a later section. The main thing is that all such messages (which are otherwise called authorization request messages, i.e. ARQC – ‘Authorization Request Cryptogram’) arrive in the card holder’s bank, where these can be judged by their own set of rules. The issuer bank sends a response (ARPC – ‘Authorization Response Cryptogram’) including either the approval or the refusal of the transaction. The terminal, using this response, sends a new message to the chip (‘2nd Generate AC’), in which it encourages the card to close the transaction between each other in one way or another. The chip evaluates the situation before sending a response, and then, similarly to the above, sends either a refusal or an approval message to the terminal, and it will close the transaction according to it. The ARPC arriving from the host has another benefit, namely that based on it the chip will reset the offline counters to zero, which means that at the next purchase the chip will already know that it was given an authorization by its bank for the payment not so long ago, during an online transaction.
Oops! It really wasn’t short, but as you can see from the above, it is not my fault. Payment transactions are quite complicated, even if they take place in a few seconds in the background during the time of purchase. Sometimes I tried to simplify and I did not go into details, what other parameters have impact on the individual decisions, I left out some special transaction cases and did not mention how the issuer bank can rewrite some values on a card already used by the card holder, which will affect the card’s future operation. The latter ones are called ‘Post Issuance’ operations, the best-known example of which is PIN change. I think we have come quite a long way in discovering our bank cards, but there are still some issues to continue it.