Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The VISA Contactless Payment Specification (the latest version 2.0.2 is supported since the VSDC 2.7 applet) considers three possible contactless card profiles (instead of the MasterCard term "mode", VISA uses the term "profile", which will be used in the text of this book when describing contactless VISA cards):
The following restrictions are imposed on the VISA Contactless card and terminal:
Tab. 7.3. Card and Terminal Application Compatibility
When choosing a card profile during an operation, the terminal is guided by the following rule:
Tab. 7.4. Selecting a card profile when performing a contactless operation
General VISA requirements for contactless payments, cards and readers can be supplemented by the following provisions:
In the future, it is planned to replace the dCW value with a version 17 cryptogram, which is a signature of such transaction details as a random terminal number, a PBX transaction counter, a transaction size and an Issuer Application Data (IAD) object containing a CVR and CVN (Cryptogram Version Number) object. Thus, the version 17 cryptogram is an abbreviated version of the version 10 cryptogram widely used in VISA.
An MSD profile VISA Contactless card transaction is processed as follows. After selecting the application, the terminal informs the card about its capabilities to support VISA Contactless profiles. This information is provided through the data sent to the card in the GET PROCESSING OPTIONS command (the PDOL object in VISA, unlike MasterCard, is not empty).
Upon receipt of the GET PROCESSING OPTIONS command, the card determines that the operation will be performed using the MSD profile, and captures this fact by setting the corresponding value of bit 8 of the second byte of the AIP object. The card then calculates the dCW value and inserts it and the ATC value into Track 2 Equivalent Data. Thus, the VISA Contactless terminal (in contrast to the MasterCard case) does not need to do anything with the Track 2 Equivalent Data read from the card, except to include them in an authorization request sent to the host of the serving bank.
After receiving a response to the GET PROCESSING OPTIONS command, the terminal sends the READ RECORD commands to the card, with the help of which it reads the Track 2 Equivalent Data object generated by the card, as well as some other data (for example, Track 1 Discretionary Data (Tag'9FlF)). After that, the processing of the transaction on the card side is completed. The terminal generates an authorization request and sends it to the host of the serving bank, as it does in the case of processing a magnetic stripe card.
As in the case of MasterCard PayPass MagStripe, the following methods of cardholder verification are allowed when processing a VISA MSD card transaction: signature on the terminal receipt and PIN Online. When performing a contactless transaction, the cardholder may not be verified.
Let us now dwell on the qVSDC profile, which VISA pays special attention to as a contactless application for markets with a developed infrastructure for servicing microprocessor cards. The following are the main characteristics of the qVSDC protocol.
A contactless transaction made with a VISA Contactless card using the qVSDC profile can be authorized both online and offline.
Before the transaction starts (before the card is in the reader's working area), the contactless terminal performs Preliminary Transaction Processing. The terminal checks whether the size of the contactless transaction does not exceed the following terminal limits:
The TTQ data object received from the terminal informs the card with the following information:
Most of the work is done by the qVSDC card during the processing of the GET PROCESSING OPTIONS command. At this time, the card performs risk management procedures, calculates a cryptogram and, in the case of an offline operation, generates a dynamic signature value.
When performing risk management procedures, the card determines:
Then the card analyzes the results of the risk management procedure and transfers its decisions to the terminal in the Card Transaction Qualifiers '9FC6' data object contained in the response to the GET PROCESSING OPTIONS command. The Card Transaction Qualifiers object determines the need for:
To generate a dynamic signature, VISA recommends using the Fast DDA (fDDA) method, which uses the Chinese Remainder Theorem (CRT) to compute the signature using the RSA algorithm. As explained earlier, the Chinese Remainder Theorem reduces the signature computation time by about 4 times. The signature is generated by the card only after the terminal and the card have agreed to perform the operation offline. For online transactions, dynamic authentication of the card application is not performed. Note that the SDA method can be used to authenticate the qVSDC card data.
VISA recommends that the size of the RSA key modulus used for dynamic authentication should not exceed 1024 bits. The experiment shows that for a processor with a clock frequency of 8 MHz, an RSA operation with a 1024 bit key on a long key without using a CRT takes 750 ms, with a CRT it takes about 200 ms. The gain in time for calculating the signature is obvious.
The qVSDC profile uses either version 10 or 17 cryptograms (an abbreviated version of version 10 cryptogram).
If the terminal and the card decide that the qVSDC card operation should be authorized online, the card-side operation ends with a response to the GET PROCESSING OPTIONS command. In this case, dynamic authentication of the card application is not performed and the AFL object is not returned to the terminal: the terminal does not need any additional card data to proceed with the transaction.
If the card and the terminal decide that the transaction should be authorized offline, the card returns an AFL object to the terminal and the terminal uses READ RECORD commands to read the data needed to authenticate the qVSDC application offline.
As a result, in response to the GET PROCESSING OPTIONS command, the card returns to the terminal the data shown in Table. 7.5.
In Table 7.5, the plus sign indicates the data returned to the terminal in response to the GET PROCESSING OPTIONS command, depending on the type of cryptogram generated by the card.
After completing the processing of the transaction by the card, the terminal authenticates the card application, checks the card expiration value and the list of blocked cards (Terminal exception file). If, as a result of these checks, the card and the terminal decide to approve the operation offline, then this is what happens. If either the card or the terminal thinks
Tab. 7.5. Response data to GET PROCESSING OPTIONS command
that the transaction needs to be rejected, it is rejected. The transaction can also be sent for authorization to the issuer, or the card can use the contact VSDC application to process the transaction if the Terminal Contactless Transaction Limit is exceeded and the contact VSDC application is supported by the card.
Thus, the qVSDC profile can significantly reduce the transaction processing time due to:
At the same time, there are limitations on the functionality of the full VSDC application. Cardholder verification using the method
PIN Offline is only possible if the PIN-code is encrypted when it is transferred to the card (Enciphered PIN Offline).
The table below. 7.6. demonstrates a comparison of VISA Contactless card profiles.
Tab. 7.6. Comparison of VISA Contactless card profiles
Below are the values of the special fields of authorization and clearing messages used for contactless payments in the VISA network:
VISA Wave cards are dual interface cards. They can be used both online (Malaysia) and offline (Taiwan). The PIN is not used for cardholder verification.
Processing a VISA Wave card transaction exactly repeats the processing of a VSDC card transaction via a contact interface, up to the processing of the INTERNAL AUTHENTICATE command (all VISA Wave cards support DDA). After processing this command, the card-side transaction ends. Next, the terminal verifies the dynamic signature of the card received in response to the INTERNAL AUTHENTICATE command, and, depending on the result of the verification, continues processing the transaction through the magnetic card acceptance infrastructure.
- MSD (Magnetic Stripe Data) - a profile that is analogous to MasterCard PayPass MagStripe and is used in the infrastructure for accepting cards with a magnetic stripe;
- qVSDC (quick VSDC) - a profile that implements the basic security mechanisms adopted in the EMV standard, but in an updated form in order to minimize the processing time of a transaction (supported since the VSDC 2.6 applet);
- full VSDC (or Contactless VSDC) - a profile that implements the VSDC standard through the T = CL contactless interface using the PPSE directory to select an application.
The following restrictions are imposed on the VISA Contactless card and terminal:
- any VISA Contactless card must support the qVSDC and MSD profiles;
- any VISA Contactless terminal (terminal accepting contactless cards) supports either qVSDC or MSD;
- VISA Contactless terminal can support qVSDC and MSD profiles simultaneously;
- full VSDC profile support is an option both for the card (in VSDC 2.6 and later applets) and for the terminal.
Tab. 7.3. Card and Terminal Application Compatibility
| Profiles supported by the card | Terminal Supported Profiles | Profile to select for processing the operation |
| MSD and qVSDC | MSD | MSD |
| MSD and qVSDC | qVSDC | qVSDC |
When choosing a card profile during an operation, the terminal is guided by the following rule:
- the qVSDC profile takes precedence over the MSD profile;
- full EMV profile takes precedence over qVSDC and MSD profiles.
Tab. 7.4. Selecting a card profile when performing a contactless operation
| Contactless reader | Contactless card | |
| MSD and qVSDC profiles | MSD, qVSDC and full VSDC profiles | |
| MSD | MSD | MSD |
| qVSDC | qVSDC | qVSDC |
| MSD and qVSDC | qVSDC | qVSDC |
| MSD, qVSDC, full VSDC | qVSDC | full VSDC |
| MSD and full VSDC | MSD | full VSDC |
| qVSDC and full VSDC | qVSDC | full VSDC |
General VISA requirements for contactless payments, cards and readers can be supplemented by the following provisions:
- the time of dialogue between the card and the terminal when performing contactless operations on MSD and qVSDC cards should not exceed 500 ms;
- Cards capable of working offline (qVSDC and full VSDC profile cards) must support the DDA method;
- terminals that accept offline qVSDC and full VSDC profile cards must support SDA and DDA methods.
In the future, it is planned to replace the dCW value with a version 17 cryptogram, which is a signature of such transaction details as a random terminal number, a PBX transaction counter, a transaction size and an Issuer Application Data (IAD) object containing a CVR and CVN (Cryptogram Version Number) object. Thus, the version 17 cryptogram is an abbreviated version of the version 10 cryptogram widely used in VISA.
An MSD profile VISA Contactless card transaction is processed as follows. After selecting the application, the terminal informs the card about its capabilities to support VISA Contactless profiles. This information is provided through the data sent to the card in the GET PROCESSING OPTIONS command (the PDOL object in VISA, unlike MasterCard, is not empty).
Upon receipt of the GET PROCESSING OPTIONS command, the card determines that the operation will be performed using the MSD profile, and captures this fact by setting the corresponding value of bit 8 of the second byte of the AIP object. The card then calculates the dCW value and inserts it and the ATC value into Track 2 Equivalent Data. Thus, the VISA Contactless terminal (in contrast to the MasterCard case) does not need to do anything with the Track 2 Equivalent Data read from the card, except to include them in an authorization request sent to the host of the serving bank.
After receiving a response to the GET PROCESSING OPTIONS command, the terminal sends the READ RECORD commands to the card, with the help of which it reads the Track 2 Equivalent Data object generated by the card, as well as some other data (for example, Track 1 Discretionary Data (Tag'9FlF)). After that, the processing of the transaction on the card side is completed. The terminal generates an authorization request and sends it to the host of the serving bank, as it does in the case of processing a magnetic stripe card.
As in the case of MasterCard PayPass MagStripe, the following methods of cardholder verification are allowed when processing a VISA MSD card transaction: signature on the terminal receipt and PIN Online. When performing a contactless transaction, the cardholder may not be verified.
Let us now dwell on the qVSDC profile, which VISA pays special attention to as a contactless application for markets with a developed infrastructure for servicing microprocessor cards. The following are the main characteristics of the qVSDC protocol.
A contactless transaction made with a VISA Contactless card using the qVSDC profile can be authorized both online and offline.
Before the transaction starts (before the card is in the reader's working area), the contactless terminal performs Preliminary Transaction Processing. The terminal checks whether the size of the contactless transaction does not exceed the following terminal limits:
- Terminal Contactless Transaction Limit. If the limit is exceeded, the transaction cannot be processed through the contactless interface and must be processed in a different way;
- Terminal Floor Limit. If the limit is exceeded, the transaction must be processed in the online authorization mode;
- Terminal CVM limit. If the limit is exceeded, the transaction must be processed with mandatory verification of the cardholder.
The TTQ data object received from the terminal informs the card with the following information:
- does the terminal support profiles MSD, qVSDC, full contactless VSDC, contact VSDC;
- whether the reader is offline-only or online-capable;
- whether the terminal supports signature, PIN Online, both, or does not support any method of cardholder verification;
- the reader's decision on the need to verify the cardholder when processing a transaction;
- the reader's decision on the need to process the transaction online.
Most of the work is done by the qVSDC card during the processing of the GET PROCESSING OPTIONS command. At this time, the card performs risk management procedures, calculates a cryptogram and, in the case of an offline operation, generates a dynamic signature value.
When performing risk management procedures, the card determines:
- whether the transaction is international or domestic;
- whether verification of the cardholder is required;
- whether the card is new;
- whether online processing of the transaction is required;
- whether the card prefers to process the transaction using the contact VSDC application over the online transaction using the qVSDC application, and if the transaction is offline, checks the contactless application counters shared with the VSDC application:
- counter of the number of international transactions, if the transaction is international;
Then the card analyzes the results of the risk management procedure and transfers its decisions to the terminal in the Card Transaction Qualifiers '9FC6' data object contained in the response to the GET PROCESSING OPTIONS command. The Card Transaction Qualifiers object determines the need for:
- verification of the cardholder using the PIN Online method;
- verification of the cardholder using the cardholder's signature;
- processing the transaction in real time if the dynamic authentication of the qVSDC application has failed and the reader can work online;
- termination of processing the operation if dynamic authentication of the qVSDC application has failed and the reader supports work with the VDSC application through the contact interface.
To generate a dynamic signature, VISA recommends using the Fast DDA (fDDA) method, which uses the Chinese Remainder Theorem (CRT) to compute the signature using the RSA algorithm. As explained earlier, the Chinese Remainder Theorem reduces the signature computation time by about 4 times. The signature is generated by the card only after the terminal and the card have agreed to perform the operation offline. For online transactions, dynamic authentication of the card application is not performed. Note that the SDA method can be used to authenticate the qVSDC card data.
VISA recommends that the size of the RSA key modulus used for dynamic authentication should not exceed 1024 bits. The experiment shows that for a processor with a clock frequency of 8 MHz, an RSA operation with a 1024 bit key on a long key without using a CRT takes 750 ms, with a CRT it takes about 200 ms. The gain in time for calculating the signature is obvious.
The qVSDC profile uses either version 10 or 17 cryptograms (an abbreviated version of version 10 cryptogram).
If the terminal and the card decide that the qVSDC card operation should be authorized online, the card-side operation ends with a response to the GET PROCESSING OPTIONS command. In this case, dynamic authentication of the card application is not performed and the AFL object is not returned to the terminal: the terminal does not need any additional card data to proceed with the transaction.
If the card and the terminal decide that the transaction should be authorized offline, the card returns an AFL object to the terminal and the terminal uses READ RECORD commands to read the data needed to authenticate the qVSDC application offline.
As a result, in response to the GET PROCESSING OPTIONS command, the card returns to the terminal the data shown in Table. 7.5.
In Table 7.5, the plus sign indicates the data returned to the terminal in response to the GET PROCESSING OPTIONS command, depending on the type of cryptogram generated by the card.
After completing the processing of the transaction by the card, the terminal authenticates the card application, checks the card expiration value and the list of blocked cards (Terminal exception file). If, as a result of these checks, the card and the terminal decide to approve the operation offline, then this is what happens. If either the card or the terminal thinks
Tab. 7.5. Response data to GET PROCESSING OPTIONS command
| Tag | Data object name | Cryptogram type | ||
| AAS | ARQC | TS | ||
| '82' | AIP | + | + | + |
| '94' | AFL | + | ||
| '9F36' | ATC | + | + | + |
| '57' | Track 2 Equivalent Data | + | + | + |
| '9F10' | Issuer Application Data | + | + | + |
| '9F26' | Application Cryptogram | + | + | + |
| '5F34' | PAN Sequence Number | + | + | + |
| '9F4B' | Signed Dynamic Application Data | + | ||
| '9F6C' | Card Transaction Qualifiers | + | + | + |
| '9F5D' | Available Offline Spending Amount (for printing or displaying on a terminal screen) | + | + | + |
| '5F20' | Cardholder Name | + | + |
that the transaction needs to be rejected, it is rejected. The transaction can also be sent for authorization to the issuer, or the card can use the contact VSDC application to process the transaction if the Terminal Contactless Transaction Limit is exceeded and the contact VSDC application is supported by the card.
Thus, the qVSDC profile can significantly reduce the transaction processing time due to:
- use of preliminary processing of the transaction by the terminal;
- completion of the dialogue between the card and the terminal, either immediately after the response to the GET PROCESSING OPTIONS command in case of online authorization, or after the completion of the GET PROCESSING OPTIONS command processing and subsequent reading of the data required to perform offline authentication in the case of an offline operation;
- application of the Fast DDA algorithm and restrictions on the size of the RSA key modulus (no more than 1024 bits);
- calculation of a dynamic signature by a card only in the case of offline processing of the transaction.
At the same time, there are limitations on the functionality of the full VSDC application. Cardholder verification using the method
PIN Offline is only possible if the PIN-code is encrypted when it is transferred to the card (Enciphered PIN Offline).
The table below. 7.6. demonstrates a comparison of VISA Contactless card profiles.
Tab. 7.6. Comparison of VISA Contactless card profiles
| Main criteria | MSD | qVSDC | full VSDC |
| Fast transactions (<500ms) | + | + | - |
| Online counterfeiting protection | + | + | + |
| Anti-counterfeiting in offline mode | - | + | + |
| Control of offline meters | - | + | + |
| Offline PIN | - | - | + |
Below are the values of the special fields of authorization and clearing messages used for contactless payments in the VISA network:
- special POS Entry Mode values are used: for MSD the field is 91, for qVSDC and full VSDC - 07;
- The Terminal Capability / POS Entry Capability field, depending on the capabilities of the terminal and the requirements of a particular market, can take values 2, 5 and 8.
VISA Wave cards are dual interface cards. They can be used both online (Malaysia) and offline (Taiwan). The PIN is not used for cardholder verification.
Processing a VISA Wave card transaction exactly repeats the processing of a VSDC card transaction via a contact interface, up to the processing of the INTERNAL AUTHENTICATE command (all VISA Wave cards support DDA). After processing this command, the card-side transaction ends. Next, the terminal verifies the dynamic signature of the card received in response to the INTERNAL AUTHENTICATE command, and, depending on the result of the verification, continues processing the transaction through the magnetic card acceptance infrastructure.
