PIN code for card payments - points above i
Good day to all!
After reading several articles on the hub 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 understand the topic of entering PIN code on POS terminals and finally answer, to the best of my knowledge, the question: why is PIN input required in some cases and not in others?
If the topic is also of interest to the community, then in the future you will find several more articles about the principles of operation ofthis whole 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 of our country. Actually, I am engaged in setting up POS terminals from scratch and before, actually, putting into operation.
This is my first article, so I apologize in advance for some confusion, as well as for the fact that I might 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 the computer on which some program runs - the configuration center of all POS terminals. This is where the so-called “application configuration files” are created, that is, what is poured into POS and characterizes its operation.
In TMS, all POS operation parameters are set, both very significant (for example, a list of payment systems with which POS works, settings of these systems, CVM lists, 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 that the terminal “understands”. This file is poured into 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 is poured onto the EMV chip of the card at the application loading stage(CVM - Cardholder Verification Method). It can also be changed during the transaction with a special emitter script sent from the processing center, but I will allow myself to let go of these subtleties.
Each issuing bank selects a CVM list based on its requirements. Here is an example of a classic CVM list:
4403410342031E031F02 The
decoding looks like this:
And it reads from left to right (I apologize in advance for the clumsy scheme from the master of the minus 92 level):
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 very simply: during a transaction, two CVM lists (cards and terminals) are compared. Only those verification methods that match on both sheets work (in fact, the intersection of CVM sheets is checked). Other methods are discarded!
That is, in this example, the algorithm is as follows:
Ask for a crypted PIN (after checking if there is such a method in the CVM list of the terminal), if the user refuses (this is the very press of the red button on the PIN keyboard) - request an offline offline PIN (and he has the right to refuse - see the picture), if it refuses again - ask for an online PIN (it is checked not by the card, but by the host), if it again refuses - ask for a signature (you can’t refuse it anymore - see the picture again). If there is no signature verification in the terminal’s CVM list, the method is skipped (this does NOT amount to failure!) And the No CVM method is used with the condition “If not unattended cash and not manual cash and not purchase” (but usually it’s not very used). If this method is not in the CVM list of the terminal, then the check does not pass 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 more clear to everyone why the card in the device asks for a PIN, and in the other device the same card asks for a signature. And why the other card works correctly with the PIN request in the same device, and the card that works in the third one refuses to work here 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 there will no longer be any surprise in stores about this.
Thank you all for your attention!
After reading several articles on the hub 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 understand the topic of entering PIN code on POS terminals and finally answer, to the best of my knowledge, the question: why is PIN input required in some cases and not in others?
If the topic is also of interest to the community, then in the future you will find several more articles about the principles of operation of
But first, a preface.
It just so happened that I work in one of the banks of our country. Actually, I am engaged in setting up POS terminals from scratch and before, actually, putting into operation.
This is my first article, so I apologize in advance for some confusion, as well as for the fact that I might 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 the computer on which some program runs - the configuration center of all POS terminals. This is where the so-called “application configuration files” are created, that is, what is poured into POS and characterizes its operation.
In TMS, all POS operation parameters are set, both very significant (for example, a list of payment systems with which POS works, settings of these systems, CVM lists, 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 that the terminal “understands”. This file is poured into 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 is poured onto the EMV chip of the card at the application loading stage(CVM - Cardholder Verification Method). It can also be changed during the transaction with a special emitter script sent from the processing center, but I will allow myself to let go of these subtleties.
Each issuing bank selects a CVM list based on its requirements. Here is an example of a classic CVM list:
4403410342031E031F02 The
decoding looks like this:
And it reads from left to right (I apologize in advance for the clumsy scheme from the master of the minus 92 level):
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 very simply: during a transaction, two CVM lists (cards and terminals) are compared. Only those verification methods that match on both sheets work (in fact, the intersection of CVM sheets is checked). Other methods are discarded!
That is, in this example, the algorithm is as follows:
Ask for a crypted PIN (after checking if there is such a method in the CVM list of the terminal), if the user refuses (this is the very press of the red button on the PIN keyboard) - request an offline offline PIN (and he has the right to refuse - see the picture), if it refuses again - ask for an online PIN (it is checked not by the card, but by the host), if it again refuses - ask for a signature (you can’t refuse it anymore - see the picture again). If there is no signature verification in the terminal’s CVM list, the method is skipped (this does NOT amount to failure!) And the No CVM method is used with the condition “If not unattended cash and not manual cash and not purchase” (but usually it’s not very used). If this method is not in the CVM list of the terminal, then the check does not pass 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 more clear to everyone why the card in the device asks for a PIN, and in the other device the same card asks for a signature. And why the other card works correctly with the PIN request in the same device, and the card that works in the third one refuses to work here 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 there will no longer be any surprise in stores about this.
Thank you all for your attention!