Hacker
Professional
- Messages
- 1,044
- Reaction score
- 824
- Points
- 113
Good day everyone!
After reading several articles about plastic cards, POS terminals and related things, it seemed to me that this topic is quite interesting to the community. In this small publication, I want to finally analyze the topic of entering a PIN-code at POS terminals and finally answer, to the best of my knowledge, the question: why in some cases it is required to enter a PIN, and in others not?
If the topic is of the same interest to the community, then in the future you will find several more articles on the principles of operation ofthis entire kitchen , everything related to POS-terminal equipment, processing centers and plastic cards.
But first, a preface.
It just so happened that I work in one of the banks in our country. Actually, I am engaged in setting up POS terminals "from scratch" to, in fact, commissioning.
This is my first article, so I apologize in advance for some confusion, as well as for the fact that, perhaps, I will miss something, because it is impossible to fit all the details into the framework of the article.
First of all, it will be necessary to mention TMS (Terminal Management Server \ Station). In short, this is a computer running some program - the center for configuring all POS terminals. It is there that the so-called "application configuration files" are created, that is, what is poured into the POS and characterizes its work.
In TMS, all the parameters of POS operation are set, both very significant (for example, a list of payment systems that POS works with, settings of these systems, CVM sheets, terminal action codes), and insignificant (such as the order of the menu items on the screen terminal, or check design).
As a result, a specially packed file appears at the output, which the terminal "understands". This file is uploaded to the terminal.
Now about the essence: to ask or not to ask for a PIN (in the case of an EMV card):
The so-called CVM-list (CVM - Cardholder Verification Method) is uploaded to the EMV-chip of the card at the stage of loading the application . It can also be changed during the transaction with a special issuing script sent from the processing center, but I will allow myself to let go of these subtleties.
Each issuing bank chooses a CVM list based on its requirements. Here is an example of a classic CVM sheet:
4403410342031E031F02 The
decryption looks like this:
And it reads from left to right (I apologize in advance for the clumsy scheme from the paint master minus 92 leveled):
The terminal itself also has its own terminal CVM list. It is set in TMS at the stage of compiling configuration files that are uploaded to POS. It is set up by the bank - the acquirer, again, according to its requests.
Everything works quite simply: during a transaction, two CVM lists (cards and terminals) are compared. Only those verification methods that match in both sheets are triggered (in fact, the intersection of CVM sheets is checked). The rest of the methods are discarded!
That is, in this example, the algorithm is as follows:
Ask for the encrypted PIN (after checking if there is such a method in the CVM-list of the terminal), if the user refuses (this is the same pressing of the red button on the PIN-keyboard) - request an offline open PIN (and he has the right to refuse - see the picture), if he refuses again, request an online PIN (it is verified not by the card, but by the host), if he refused again, request a signature (you can no longer refuse it - see the picture again). If there is no signature verification in the CVM list of the terminal, the method is skipped (this is NOT equated to a refusal!) And the “No CVM” method is used with the condition “If not unattended cash and not manual cash and not purchase” (but usually it is rarely found anywhere used). If this method is not in the CVM list of the terminal, then the check fails and the transaction is rejected.
Naturally, the number of different variations of CVM-lists of cards and terminals - and even more so their combinations - is very large. So now, I think, it has become clearer to everyone why a card in a device asks for a PIN, and in another device the same card asks for a signature. And why the other card works properly with the PIN request in the same device, and the card that works in the third one refuses to work at all. I also hope that after reading this article, the topic of requesting PIN codes when paying with a card has become more clear and transparent and you will no longer have to be surprised in stores about this.
Thank you all for your attention!
After reading several articles about plastic cards, POS terminals and related things, it seemed to me that this topic is quite interesting to the community. In this small publication, I want to finally analyze the topic of entering a PIN-code at POS terminals and finally answer, to the best of my knowledge, the question: why in some cases it is required to enter a PIN, and in others not?
If the topic is of the same interest to the community, then in the future you will find several more articles on the principles of operation of
But first, a preface.
It just so happened that I work in one of the banks in our country. Actually, I am engaged in setting up POS terminals "from scratch" to, in fact, commissioning.
This is my first article, so I apologize in advance for some confusion, as well as for the fact that, perhaps, I will miss something, because it is impossible to fit all the details into the framework of the article.
First of all, it will be necessary to mention TMS (Terminal Management Server \ Station). In short, this is a computer running some program - the center for configuring all POS terminals. It is there that the so-called "application configuration files" are created, that is, what is poured into the POS and characterizes its work.
In TMS, all the parameters of POS operation are set, both very significant (for example, a list of payment systems that POS works with, settings of these systems, CVM sheets, terminal action codes), and insignificant (such as the order of the menu items on the screen terminal, or check design).
As a result, a specially packed file appears at the output, which the terminal "understands". This file is uploaded to the terminal.
Now about the essence: to ask or not to ask for a PIN (in the case of an EMV card):
The so-called CVM-list (CVM - Cardholder Verification Method) is uploaded to the EMV-chip of the card at the stage of loading the application . It can also be changed during the transaction with a special issuing script sent from the processing center, but I will allow myself to let go of these subtleties.
Each issuing bank chooses a CVM list based on its requirements. Here is an example of a classic CVM sheet:
4403410342031E031F02 The
decryption looks like this:
And it reads from left to right (I apologize in advance for the clumsy scheme from the paint master minus 92 leveled):
The terminal itself also has its own terminal CVM list. It is set in TMS at the stage of compiling configuration files that are uploaded to POS. It is set up by the bank - the acquirer, again, according to its requests.
Everything works quite simply: during a transaction, two CVM lists (cards and terminals) are compared. Only those verification methods that match in both sheets are triggered (in fact, the intersection of CVM sheets is checked). The rest of the methods are discarded!
That is, in this example, the algorithm is as follows:
Ask for the encrypted PIN (after checking if there is such a method in the CVM-list of the terminal), if the user refuses (this is the same pressing of the red button on the PIN-keyboard) - request an offline open PIN (and he has the right to refuse - see the picture), if he refuses again, request an online PIN (it is verified not by the card, but by the host), if he refused again, request a signature (you can no longer refuse it - see the picture again). If there is no signature verification in the CVM list of the terminal, the method is skipped (this is NOT equated to a refusal!) And the “No CVM” method is used with the condition “If not unattended cash and not manual cash and not purchase” (but usually it is rarely found anywhere used). If this method is not in the CVM list of the terminal, then the check fails and the transaction is rejected.
Naturally, the number of different variations of CVM-lists of cards and terminals - and even more so their combinations - is very large. So now, I think, it has become clearer to everyone why a card in a device asks for a PIN, and in another device the same card asks for a signature. And why the other card works properly with the PIN request in the same device, and the card that works in the third one refuses to work at all. I also hope that after reading this article, the topic of requesting PIN codes when paying with a card has become more clear and transparent and you will no longer have to be surprised in stores about this.
Thank you all for your attention!
