Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The issue of interoperability between card, terminal and bank host applications is a cornerstone of EMV implementation. EMV is a complex and young standard. Therefore, the suppliers of equipment, cards and applications for the host of the processing center have discrepancies in the standard (which are gradually clarified as the standard is introduced), sometimes leading to the fact that the card transaction cannot be processed at the terminal or is rejected by the payment network. In such cases (see clause 4.1), payment systems either reject the transaction (sometimes the card issuer does this), or allow the card to be serviced in fallback mode to the magnetic stripe.
For illustration, we will point out only some of the practical reasons for the occurrence of a fallback to the magnetic stripe or unsuccessful completion of a transaction by the issuer's network / host. These reasons are sometimes general and sometimes very specific and are the result of errors in the terminal and / or card applications.
Chapter 6. CHARACTERISTICS OF MIGRATION ON MICROPROCESSOR CARDS 449 of the CDA authentication method, this will cause authorization denial, since it contradicts the requirements of the EMV 4.2 standard, according to which the Unpredictable Number element must be mentioned in both CDOL1 and CDOL2 lists.
For example, a “terminal” can be installed in a fraudulent store, which will represent all transactions on hybrid cards in fallback mode to the magnetic stripe. As a result, it is easy to use magnetic stripe-cloned cards in such a terminal (see section 6.6).
The situation is even more dramatic in ATMs. The fact is that the ATM considers a magnetic stripe-cloned card containing only the magnetic stripe as a card with a chip of which it cannot establish communications (there is no ATR response from the card). The ATM “does not see” that there is no physical chip on the card, and fully trusts the data of the service code written on the magnetic stripe of the card. As a result, for each such card, he performs an operation in the fallback mode on the magnetic stripe.
As such, leading card associations are making efforts to eliminate magnetic stripe fallback altogether as soon as possible. For this, payment systems and EMVCo primarily pay attention to the issue of ensuring compliance of cards and terminals with EMV standards and the requirements of payment systems. From the very beginning of the implementation of the EMV standard, procedures were developed for testing terminals and cards, as well as integration tests to make sure that the entire cycle of an IPC transaction meets the requirements of payment systems.
EMVCo has developed and published a list of tests to verify that terminals comply with EMV specifications. All these tests are divided into two parts: Type Approval Level 1 and Type Approval Level 2. Tests Approval Level 1 test the physical and electrical characteristics of the card reader (more precisely in terms of the EMV standard - the interface module of the IFM terminal) with the requirements specified in the Book 1 of the EMV standard. The Type Approval Level 2 tests determine the compliance of the terminal application kernel with the EMV standard. The logical level of the terminal's operation with the card is checked: the terminal forms commands and processes responses to them, the terminal correctly performs the application selection procedures, offline card authentication, risk management, Issuer Script Processing, etc.
To carry out testing of terminals, EMVCo company accredits special laboratories.
Upon successful completion of testing, EMVCo publishes a Letter of Approval and places the certified product on the list published in the appropriate section on the company's website www.emvco.com.
Certification of card applications for compliance with the specifications of payment systems is carried out by accredited laboratories of the respective payment systems. EMVCo only certifies cards with CPA and CCD-compatible cards.
To ensure high-quality processing of transactions with microprocessor cards, payment systems also carry out certification of participating banks migrating to IPC technology. For this, tests are used to assess the performance of the bank's processing center in terms of processing transactions under the IPC, both from the issue of cards and from the side of their servicing in the bank's terminal network. At the same time, the correctness of all stages of transaction processing is checked.
In the case of testing by the servicing bank, the correctness of the transaction processing during servicing the card at the terminal and the information exchange between the terminal and the host of the servicing bank (Terminal Integration Program), the format of the authorization request to the payment network, the processing of the response received from the network, and its delivery to the terminal are checked who initiated the operation (End-to-end Validation).
When testing the emission, the correctness of the personalization of the card application is checked (VPA - VISA Permanent Assistance and CPV - Card Personalization Validation procedures in the MasterCard system), as well as the processing of a transaction using a microprocessor card, starting from the moment of receiving an authorization message from the network and ending with sending an authorization response to the network ( End-to-end Validation).
For illustration, we will point out only some of the practical reasons for the occurrence of a fallback to the magnetic stripe or unsuccessful completion of a transaction by the issuer's network / host. These reasons are sometimes general and sometimes very specific and are the result of errors in the terminal and / or card applications.
- 1. Problems on the host of the serving bank (distortion and truncation of data, incorrect data formatting, usually related to PAN Sequence Number, Issuer Discretionary Data, Issuer Authentication Data, Issuer Script Template).
- 2. Problems on the terminal (distortion and cropping of data, incorrect formatting).
- 3. On some POS-terminals the change of convention was not processed correctly. For example, when servicing French cards BO ', in the first response to the Reset signal, the card sent the ATR string in the indirect convention mode with the indication of a communication protocol byte that does not correspond to the EMV application. The terminal, as it should be, initiated a warm reset of the card (Warm Reset), to which the card now responded with ATR, fully compatible with EMV, but with a change to the agreement to direct (direct convention). The terminal did not accept the agreement change and initiated a fallback to the magnetic stripe.
- 4. Attempt of the terminal to obtain information about the PIN Try Counter using the GET DATA command in the case when the card does not support PIN Offline checks in the CVM List. The card responds to a command with an error code that forced the terminal to prompt the merchant's cashier to switch to fallback mode.
- 5. Not loaded in time system keys for CCD card case. Failure to verify Signed Dynamic Application Data leads to the fact that the transaction cannot be serviced even in real time (it is impossible to recover the ARQC cryptogram from the signed data). As a result, the processing of the operation fails without the possibility of switching to the fallback mode on the magnetic stripe.
- 6. Some terminals incorrectly generate POS Entry Mode (in MasterCard terms) for an IPC transaction in a terminal that accepts smart cards - 80x instead of 05x.
- 7. Incorrect filling of the fields with service characters (padding) in the FCI Template when personalizing the card. The general rule is violated: inside FCI Template padding is allowed before, after and between TLV data, and not inside data objects of this template.
- 8. Failure of card authentication using the SDA method when the length of the issuer's public key module is 127 bytes - some RSA programs implemented on the terminals worked only with modules that are multiples of 16.
- 9. Incorrect processing by the terminal of the Cryptogram Information Data item received in response to the AC GENERATE command.
- 10. The terminal should ignore data that it does not understand, and not react to them by refusing to service the card. For example, there is a known case when the terminal received FCI Issuer Discretionary Data objects (Tag '5F0C') in response to the SELECT command, among which there was an Issuer URL object (Tag '5F50) unknown to the terminal. As a result, the operation ended with a Card Data Error code (0200).
- 11. There are cases when the terminal was implemented without a PIN PAD device, later such a device was connected to the terminal, but the configuration parameters of the terminal application were not changed accordingly. As a result, the Terminal Capabilities object (Tag '9F33') remained unchanged, indicating to the card that the terminal does not support PIN Offline. As a result, transactions on some Japanese cards and French BO 'cards requiring PIN verification were rejected.
- 12. Cases are known when the terminal application contained errors resulting in a denial of card service. For example, the “forgetting” by the terminal after the completion of the next transaction of resetting the flag about the failure of card authentication, depending on the personalization method of the next card served in such a terminal, led either to a denial of authorization in offline mode or to forcing the authorization of the transaction in real time.
- 13. If the size of the data of the second track of the Track 2 Equivalent Data magnetic stripe stored in the card application is not equal to an integer number of bytes, then it is necessary to supplement this data with service characters until the size is a multiple of an integer number of bytes. Some of the service banks did not accept Padding on this data object.
- 14. Cases are known when the Language Preference data item was not present in the FCI Template PSE directory, but was present in the FCI Template of the selected card application directory. This is contrary to the EMV rules that this item must be the same in the FCI Template in the PSE and ADF directories. The terminal detected this violation and rejected the transaction.
- 15. In some cases, the fallback mode is caused by situations when, when selecting an application, the confirmation of the cardholder is required, and the receiving device does not allow the cardholder to confirm his choice.
- 16. There were cases when the terminal rejected transactions if it found BER-TLV encoded data less than 127 bytes long, while the Length field of the data object was 2 bytes long. Indeed, to encode an element less than 127 bytes in size, it is sufficient to have a Length field of 1 byte, but EMV rules do not prohibit storing such data in an object with a Length field of 2 or 3 bytes.
- 17. It was found that some terminals were rejecting the transaction because the Application Label or Application Preferred Name data items contained spaces. The terminals have acted in this way, since the specified data items are in the format of alphanumeric data, and the space does not apply to alphanumeric characters. Subsequently, terminal applications were modified, since EMV deals with the encoding of the Application Label and Application Preferred Name elements printed on the check.
- 18. There were cases when, in the absence of ICC Public Key Remainder data, the terminal set only the TCC Data Missing 'bit in the test results without setting the' Offline Dynamic Data Authentication failed 'bit.
- 19. Noted the fact that some cards in the CDOL2 list do not contain a reference to the Unpredictable Number element. In case of use
Chapter 6. CHARACTERISTICS OF MIGRATION ON MICROPROCESSOR CARDS 449 of the CDA authentication method, this will cause authorization denial, since it contradicts the requirements of the EMV 4.2 standard, according to which the Unpredictable Number element must be mentioned in both CDOL1 and CDOL2 lists.
- 20. Sometimes there are problems associated with the fact that the terminal perceives the equality of the modules of the public keys of the card issuer and the system as an error. In accordance with the EMV 3.1.1 standard, the issuer's key module must be strictly less than the system's key module. The strict inequality was replaced by a non-strict one in the version of the EMV 4.0 standard. However, in older versions of terminals, this check has not changed and causes problems with transaction authorization.
- 21. Some older terminal models have difficulty working with relatively long RSA keys (for example, when working with keys whose modulus is greater than or equal to 1152 bits).
- 22. It was noticed that some interfaces between the terminal and the host of the servicing bank do not support the issuer's scripts larger than 24 bytes. In accordance with EMV 4.2, the size of only one Issuer Script Template command block can be equal to 128 bytes, and the issuer can send an unlimited number of such blocks to the card.
- 23. There were cases when the size of the transaction in the ARQC cryptogram and the field "Transaction size" of the message x100 differed, which is why the issuer rejected the transaction. The error was due to the fact that the terminal transmitted the preliminary value of the transaction size to the card, and the final value was sent to the issuer.
- 24. Incorrect processing of the encrypted PIN-block when using the cardholder verification method Enciphered PIN Offline.
- 25. Issuer Application Data is too long. Due to the different values of the sizes of the specified data object in different payment systems, confusion arose when the card was personalized by the issuer.
- POS Entry Data (DE 022) = 80x in the MasterCard system;
- DE60.3 - “l” (Fallback. No info about chip read error on previous transaction in that terminal) or “2” (Fallback. There was chip read error on previous transaction in that terminal) in VISA.
For example, a “terminal” can be installed in a fraudulent store, which will represent all transactions on hybrid cards in fallback mode to the magnetic stripe. As a result, it is easy to use magnetic stripe-cloned cards in such a terminal (see section 6.6).
The situation is even more dramatic in ATMs. The fact is that the ATM considers a magnetic stripe-cloned card containing only the magnetic stripe as a card with a chip of which it cannot establish communications (there is no ATR response from the card). The ATM “does not see” that there is no physical chip on the card, and fully trusts the data of the service code written on the magnetic stripe of the card. As a result, for each such card, he performs an operation in the fallback mode on the magnetic stripe.
As such, leading card associations are making efforts to eliminate magnetic stripe fallback altogether as soon as possible. For this, payment systems and EMVCo primarily pay attention to the issue of ensuring compliance of cards and terminals with EMV standards and the requirements of payment systems. From the very beginning of the implementation of the EMV standard, procedures were developed for testing terminals and cards, as well as integration tests to make sure that the entire cycle of an IPC transaction meets the requirements of payment systems.
EMVCo has developed and published a list of tests to verify that terminals comply with EMV specifications. All these tests are divided into two parts: Type Approval Level 1 and Type Approval Level 2. Tests Approval Level 1 test the physical and electrical characteristics of the card reader (more precisely in terms of the EMV standard - the interface module of the IFM terminal) with the requirements specified in the Book 1 of the EMV standard. The Type Approval Level 2 tests determine the compliance of the terminal application kernel with the EMV standard. The logical level of the terminal's operation with the card is checked: the terminal forms commands and processes responses to them, the terminal correctly performs the application selection procedures, offline card authentication, risk management, Issuer Script Processing, etc.
To carry out testing of terminals, EMVCo company accredits special laboratories.
Upon successful completion of testing, EMVCo publishes a Letter of Approval and places the certified product on the list published in the appropriate section on the company's website www.emvco.com.
Certification of card applications for compliance with the specifications of payment systems is carried out by accredited laboratories of the respective payment systems. EMVCo only certifies cards with CPA and CCD-compatible cards.
To ensure high-quality processing of transactions with microprocessor cards, payment systems also carry out certification of participating banks migrating to IPC technology. For this, tests are used to assess the performance of the bank's processing center in terms of processing transactions under the IPC, both from the issue of cards and from the side of their servicing in the bank's terminal network. At the same time, the correctness of all stages of transaction processing is checked.
In the case of testing by the servicing bank, the correctness of the transaction processing during servicing the card at the terminal and the information exchange between the terminal and the host of the servicing bank (Terminal Integration Program), the format of the authorization request to the payment network, the processing of the response received from the network, and its delivery to the terminal are checked who initiated the operation (End-to-end Validation).
When testing the emission, the correctness of the personalization of the card application is checked (VPA - VISA Permanent Assistance and CPV - Card Personalization Validation procedures in the MasterCard system), as well as the processing of a transaction using a microprocessor card, starting from the moment of receiving an authorization message from the network and ending with sending an authorization response to the network ( End-to-end Validation).
