{"id":431412,"date":"2019-08-21T12:43:47","date_gmt":"2019-08-21T12:43:47","guid":{"rendered":"https:\/\/www.any.hu\/?p=431412"},"modified":"2019-08-21T12:43:47","modified_gmt":"2019-08-21T12:43:47","slug":"about-the-bank-card-transactionspart-2","status":"publish","type":"post","link":"https:\/\/www.any.hu\/en\/about-the-bank-card-transactionspart-2\/","title":{"rendered":"\u2026 about the bank card transactions\u2026part 2."},"content":{"rendered":"

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\u2019t want to split it up. Nevertheless, I trust that it is worth reading. <\/span><\/p>\n

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. <\/span><\/p>\n

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 \u2013 to carry out a payment transaction \u2013 but they have to be convinced in advance, whether they can trust in each other and the other is able to meet their expectations.<\/span><\/p>\n

\"\"<\/b><\/i><\/u><\/p>\n

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\u2019t 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.<\/span><\/p>\n

Then the terminal resets its storages to default settings and issues an instruction to the card (\u2019Get Processing Option\u2019) 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 (\u2019Application File Locator\u2019) 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. <\/span><\/p>\n

After that, the terminal smoothly reads through the previously received file list by using \u2019Read Record\u2019 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: \u2018Tag-Length-Value\u2019. 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 \u2018usually\u2019, 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.<\/span><\/p>\n

The EMV standard and card corporation specifications assign a tag to each data field, for example, the country code of the issuer bank (\u2019Issuer Country Code\u2019) is stored by the well-sounding 5F28 tag. The currency managed as default by the application (\u2018Application Currency Code\u2019) 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 \u2018bank card factory\u2019. 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 \u2018Get Data\u2019 instructions. The point is that all information which must be shared by the card holder\u2019s bank with the accepting device must be obtained by the terminal from the chip as described above.<\/span><\/p>\n

It\u2019s 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.\u00a0 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 \u2018Get Processing Option\u2019, but offline authentication of the data always happens with verifying digital certificates. But more details about that will be written later in another chapter.<\/span><\/p>\n

In the next step the terminal performs additional checks (\u2019Processing Restrictions\u2019) 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. <\/span><\/p>\n

\"\"<\/p>\n

If there are no restrictions on the transaction, the card holder can be identified (\u2019Cardholder Verification\u2019), which means that now we need to convince the accepting device that we don\u2019t 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 (\u2019Cardholder Verification Method List\u2019). 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:<\/span><\/p>\n