MasterCard PayPass and VISA Contactless Payment Specification

MasterCard PayPass
As noted above, contactless MasterCard PayPass cards can support the magnetic stripe mode (MasterCard PayPass MagStripe) and the chip card mode (MasterCard PayPass M/Chip).
The magnetic stripe mode is implemented on contactless cards without a contact interface. The mod is described in The MasterCard PayPass MagStripe V. 3.2 specification. the main distinctive features of the MasterCard PayPass MagStripe mod are listed Below:
the card stores track 2 magnetic stripe data, and in the case of a credit card, it can store Track 1 data. However, for security reasons, which will be discussed below, it is not recommended to store the cardholder’s name in the magnetic stripe data. This, in turn, means that it is not recommended to store Track 1 data, since it stores the name of the cardholder and this is the only fundamental difference between Track 1 and Track 2;
the card can store a special Unpredictable Number Data Object (UDOL). By default, if the UDOL object is not present on the card, the terminal considers that THIS object defines a single Unpredictable Number object (Tag ‘9F6A’), whose data field is 4 bytes long;
the card supports a special COMPUTE CRYPTOGRAPHIC CHECKSUM command, whose argument is data defined in the UDOL object. As a result, the card uses the 3DES algorithm and a secret key (the session key output is not used to speed up transaction processing) to calculate the cvc3 dynamic value. The 3DES function uses UDOL and ATC data concatenation as an argument. Thus, the value of the CVC3 value always depends on the UN and ATC objects (the standard provides for the possibility of using a static CVC3 value, but we will not stop there);
the card can store a CVM List object that includes one of two or both ways to verify the cardholder-check signature and online PIN verification.

A transaction on a MasterCard PayPass MagStripe card is processed in real time, i.e. it requires the Issuer’s authorization. After selecting the application (SELECT command), initializing the transaction (GET PROCESSING OPTIONS command without terminal and transaction data, since the PDOL object in the MasterCard specifications is empty), the terminal reads (using the READ RECORD commands) all records specified in the AFL file and sends the card the COMPUTE CRYPTOGRAPHIC CHECKSUM command.
After receiving a response to the COMPUTE CRYPTOGRAPHIC CHECKSUM command, the transaction processing on the card side is completed, and the card can be removed from the reader’s work area. The terminal continues the transaction process, designing data of the second track card magnetic stripe Track 2. To do this, he inserts the CVC3 value to the place value CVC in the Track 2, and the data UN and ATC puts in the Issuer Discretionary Data field content of the second track card Track 2.
Then everything happens the same way as in the case of processing a transaction on a card with a magnetic stripe: the terminal sends the operation data, including the card’s magnetic stripe data, to the host of the servicing Bank. The only difference is that the magnetic stripe data is constructed by the terminal in the way described above. During the transaction, the cardholder can be verified by signing the receipt or checking the PIN code online. Obviously, the cardholder cannot be verified.
The MasterCard PayPass M/Chip mod is defined by the specifications MasterCard PayPass M/Chip V. 1. 3, MasterCard PayPass M/Chip Flex V. 1.1 (starting from version M/Chip 4 R2, will be included in the M/Chip 4 standard). This mod optimizes the transaction processing process based on the EMV standard in order to minimize the operation execution time.
The features of implementing MasterCard PayPass M/Chip are listed below.
The MasterCard PayPass M/Chip contactless card must support both contact and contactless modes at the same time. Contact mode is required in order to:
the card could be accepted in terminals that do not work with contactless cards;
the card was able to be serviced via the contact interface if the conditions for conducting an operation via the contactless interface are not met (for example, the transaction size is too large).
it was possible to reset the offline counters of a contactless application using the script processing procedure via the contact interface: offline counters are common for contact and contactless modes;
to simplify the process of personalizing the card using the contact interface.
In PayPass M / Chip, the dynamic authentication method for the application is CDA (DDA is not applied); the static authentication method SDA can be used.
The PIN Offline cardholder verification method is not used as a CVM, but PIN Online methods and the cardholder’s signature on the receipt can be used.
The MasterCard PayPass M / Chip card also supports the MagStripe mod: it can process both GENERATE AC and COMPUTE CRYPTOGRAPHIC CHECKSUM commands. The terminal determines the card mode using bit 8 in the second byte of the AIP object data field of the contactless application. If this bit is equal to 1, the card supports the PayPass M/Chip mod, and therefore the PayPass MagStripe mod. Otherwise (the bit is 0), the card only supports the PayPass MagStripe mod.
In turn, the terminal that supports the PayPass M/Chip mod also supports the PayPass MagStripe mod. This terminal uses AIP data to generate either the GENERATE AC command for the PayPass M/Chip card, or the COMPUTE CRYPTOGRAPHIC CHECKSUM command for the PayPass MagStripe card. On the contrary, a terminal that supports the PayPass MagStripe mod is not required to support the PayPass M/Chip mod.
Thus, the compatibility of PayPass MagStripe and PayPass M/Chip products is ensured by observing the principle that the card and terminal that support the PayPass M/Chip mod simultaneously support the PayPass MagStripe mod. An illustration of the compatibility of terminals and cards is shown in figure 7.9.
Note that the AFL object for a contactless fashion may differ from the AFL object for a contact fashion. In addition, it is advisable to make the appropriate settings in the Application Control object, indicating that the PIN Offline method is not supported by the card (deactivate the VERIFY command by setting the values of bits 3 and 4 of the first byte of the Application Control object to 0).
It should also be noted that prior to version M/Chip 4 R2, the contact and contactless m/Chip applications also share the card key to generate the cryptogram. This significantly complicates the use of different card numbers for contact and contactless applications, which is highly desirable from the point of view of improving the security of operations. The fact is that, as mentioned earlier, the card number is used when displaying the card key. Therefore, due to the presence of a common cryptogram generation key on the card, it is necessary either to use a single card number for contact and contactless applications, or to modernize the Issuer’s processing system so that the card number corresponding to the contact mode is used when generating the card key.
When processing a transaction using a PayPass M/Chip card, the terminal’s command stream is terminated with the first GENERATE AC command. After the card generates a response to this command, the transaction on the card side ends.
When servicing the card in a terminal that operates only in offline mode (offline-only terminal), after selecting the application, initializing the operation, and reading the card application data, the terminal immediately sends the GENERATE AC command to the card. The card generates a response to the GENERATE AC command and completes the operation. Thus, a transaction on the card side is completed before the terminal performs authentication of the card application, checks for processing restrictions, verification of the cardholder, terminal risk Management procedures, and making a decision on how to complete the transaction on the terminal side (Terminal Action Analysis). All these procedures are performed after the card is removed from the reader zone and only if the card has made a decision as a result of its risk management procedures (Card Action Analysis) the successful completion of the transaction (in response to the GENERATE AC command, the card requests the TC cryptogram). The final result of transaction authorization is determined as a result by the terminal based on the decision-making procedure performed by it.
When servicing a card in online-capable terminals, all commands are executed in the same sequence as in a normal EMV transaction, with the exception of the following. Authentication of the card application is performed by the terminal after receiving a response to the GENERATE AC command (as in the case of the offline-only terminal, the transaction on the card side ends after it sends a response to the GENERATE AC command). In addition, the script processing procedure is not performed in the case of an online operation (more precisely, it cannot be performed due to the above).
Thus, in the second case, the terminal’s risk management is performed before it generates the GENERATE AC command. In this case, after the dialog with the card is completed, only the application authentication is performed. It is clear that the terminal can perform application authentication after receiving a response to the GENERATE AC command, since the PayPass M / Chip standard uses one of two authentication methods — SDA or CDA.
Note that the change in the processing scheme of a standard contact EMV transaction in the case of a contactless card is aimed solely at reducing the time of the card’s dialogue with the terminal.
The values of special fields for authorization and clearing messages in the MasterCard network are listed below. Banknet (CIS) messages should indicate that a contactless card transaction has been completed as follows:
the Subelement 1 (POS Terminal PAN Entry Mode) of the data element DE 022 (POS Entry Mode) must be equal to 07 if information is read from the PayPass M/Chip card, and 91 if information is read from the PayPass MagStripe card;
the Subelement 11 (POS Card Data Input Capability) of the DE 061 (POS Data) data element must be 3 if the PayPass m/Chip terminal is used, and 4 if the PayPass MagStripe terminal is used.

The following new data element values appear in GCMS clearing messages:
the Subelement 1 (POS card data input capabilities) of the DE 022 (POS Entry Mode) data element must be equal to M if the terminal supports reading PAN via the PayPass m/Chip interface, and a If the terminal supports reading PAN only from the PayPass MagStripe card;
the Subelement 7 (card data input mode) of the DE 022 (POS Entry Mode) data element must be equal to M if the terminal reads PAN via the PayPass m/Chip interface, and a If PAN is read from the PayPass MagStripe card.

VISA Contactless
In the VISA Contactless Payment Specification (latest version
starting with the VSDC 2.7 applet, three possible contactless card profiles are considered (instead of the term “mode” accepted in MasterCard, VISA uses THE term “profile”, which will be used in the text of this book when describing VISA contactless cards):
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 upgraded form to minimize transaction processing time (supported starting with the VSDC 2.6 applet);
full VSDC (or Contactless VSDC) is a profile that implements the VSDC standard via the t = CL contactless interface using the PPSE directory to select an application.
The following restrictions apply to the VISA Contactless card and terminal:
any VISA Contactless card must support qVSDC and MSD profiles;
any VISA Contactless terminal (a terminal that accepts contactless cards) supports either qVSDC or MSD.
VISA Contactless terminal can support qVSDC and MSD profiles simultaneously;
full VSDC profile support is an option for both the card (in VSDC 2.6 and later applets) and the terminal.

Since any VISA Contactless card supports the qVSDC and MSD profiles, and each terminal supports either qVSDC or MSD, this ensures that any VISA Contactless card is accepted at any VISA Contactless terminal.

Profiles supported by the card Profiles supported by the terminal Profile selected for processing the operation
MSD and qVSDC MSD MSD
MSD and qVSDC qVSDC qVSDC

When selecting a card profile during an operation, the terminal follows the following rule:
the qVSDC profile has an advantage over the MSD profile;
the full EMV profile has an advantage over the qVSDC and MSD profiles.
As a result, the choice of a profile for performing a contactless operation is determined by the table 7.4 below.

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

VISA’s General requirements for contactless payments, cards, and readers may be supplemented by the following provisions:
the time of the card and terminal dialog when performing contactless operations on MSD and qVSDC cards should not exceed 500 MS;
cards that can work offline (qvsdc and full VSDC profile cards) must support the DDA method;
terminals that accept qvsdc and full VSDC profile cards offline must support the SDA and DDA methods.
The MSD profile is largely similar to the MasterCard PayPass MagStripe mod. When using the MSD profile, contactless payments are made online, and the Issuer is sent a request for authorization containing the card’s magnetic stripe data (Track 2 Equivalent Data), in which the value of the dynamic CVV (dCVV) is substituted for the iCVV value (static CVV value stored in Track 2 Equivalent Data). The dCVV value is calculated using the same algorithm as the CVV value, with the only difference that the function argument is the value of the ATC transaction counter (Tag ‘9F36’), and not the card number, expiration date, and service code, as in the case of a magnetic stripe card.
In the future, it is planned to replace the dCVV value with a version 17 cryptogram, which is the signature of such transaction details as the terminal random number, the ATC transaction counter, the transaction size, and the Issuer Application Data (IAD) object containing the CVR and CVN (Cryptogram Version Number) object. Thus, the cryptogram version 17 is a shortened version of the widely used version 10 cryptogram in the VISA system.
A transaction on a VISA Contactless card of the MSD profile is processed as follows. After selecting the application, the terminal informs the card about its capabilities to support VISA Contactless profiles. This information is sent via data sent to the card in the GET PROCESSING OPTIONS command (the PDOL object in VISA, unlike MasterCard, is not empty).
When receiving the GET PROCESSING OPTIONS command, the card determines that the operation will be performed using the MSD profile, and fixes this fact by setting the corresponding value of bit 8 of the second byte of the AIP object. The card then calculates the dCVV value and inserts it and the ATC value into Track 2 Equivalent Data. Thus, the VISA Contactless terminal (unlike the case of MasterCard) does not need to do anything with the Track 2 Equivalent Data read from the card, except to include it in the authorization request sent to the host of the servicing Bank.
After receiving a response to the GET PROCESSING OPTIONS command, the terminal sends THE read RECORD commands to the card, which it uses to read the Track 2 Equivalent Data object generated by the card, as well as some other data (for example, Track 1 Discretionary Data (Tag ‘9F1F)). After that, the transaction processing on the card side is completed. The terminal generates an authorization request and sends it to the host of the servicing Bank, as it does in the case of processing a card with a magnetic stripe.
As with 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, verification of the cardholder may not be performed.
Let’s now focus 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 main characteristics of the qVSDC Protocol are listed below.
A contactless transaction made on a VISA Contactless card using the qVSDC profile can be authorized both online and offline.
Before the transaction is processed (before the card is in the reader’s working area), the contactless terminal performs preliminary Transaction Processing. The terminal checks whether the size of a contactless transaction does not exceed the following limits of the terminal:
Terminal Contactless Transaction Limit. If the limit is exceeded, the transaction cannot be processed via 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 online authorization mode;
Terminal CVM limit. If the limit is exceeded, the transaction must be processed with mandatory verification of the cardholder.
After completing the pre-processing, the terminal invites the contactless card holder to bring the card to the reader (place the card in the reader’s work area). Next, the terminal selects the qVSDC application and reports the results of pre-processing to the card in THE get PROCESSING OPTIONS application initialization command. The results of pre-processing are contained in the TTQ object (Terminal Transaction Qualifiers, Tag ‘9F66’), which is a mandatory element of the PDOL object in the FCI Template of the qVSDC contactless application.
The TTQ data object received from the terminal informs the card of the following information:
does the terminal support MSD, qVSDC, full contactless VSDC, contact VSDC profiles;
is the reader offline-only or online-capable;
does the terminal support signature, PIN Online, and both, or does it not support any method of cardholder verification;
the reader’s decision to verify the cardholder when processing a transaction;
the reader’s decision to process the transaction online.

In addition to the TTQ object, the terminal passes the card in the GET PROCESSING OPTIONS command at least the transaction size and a random number generated by the terminal (Unpredictable Number).
The largest amount of work is performed by the qVSDC card while processing the GET PROCESSING OPTIONS command. During this time, the card performs risk management procedures, calculates the cryptogram, and generates a dynamic signature value for an offline operation.
When performing risk management procedures, the card determines:
whether the transaction is international or domestic.
does the cardholder need to be verified;
whether the card is new.
whether online transaction processing is required;
does the card prefer to process transactions using the contact VSDC app to process transactions online using the qVSDC app, and when processing transactions offline, checks the contactless app counters shared with the VSDC app:
counter for the number of international transactions, if the transaction is international;

VLP (VISA Low-value Payment), or VLP and CTTA (Cumulative Total Transaction Amount), or VLP or CTTA when the transaction is intra-country.
The card then analyzes the results of the risk management procedure and passes its decisions to the terminal in the Card Transaction Qualifiers ‘9FC6’ data object, which is contained in the response to the GET PROCESSING OPTIONS command. The Card Transaction Qualifiers object determines whether:
verification of the cardholder using the PIN Online method;
verification of the cardholder using the cardholder’s signature;
real-time transaction processing if dynamic authentication of the qVSDC application failed and the reader can work online;
termination of operation processing if dynamic authentication of the qVSDC application failed and the reader supports working with the VDSC application via the contact interface.
The Card Transaction Qualifiers object is formed using the results of the risk management procedure and the Card Additional Process object (Tag ‘9F68’), which plays the role of an ADA (Application Default Action) object in the VSDC application for the qVSDC application.
To generate a dynamic signature, VISA recommends using the Fast DDA (fDDA) method, which uses the Chinese remainder theorem (CRT) to calculate the signature using the RSA algorithm. As previously explained, the Chinese remainder theorem reduces the signature calculation time by about 4 times. Signature generation is performed 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 qvsdc card data.
According to VISA’s recommendation, the size of the RSA key module 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 CRT takes 750 MS, while using CRT takes about 200 MS. The gain in time of computation of the signature is obvious.
The qVSDC profile uses cryptograms version 10 or 17 (a shortened version of the cryptogram version 10).

If the terminal and the card decide that a 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 continue the transaction.
If the card and terminal decide that the transaction should be authorized offline, the card returns the AFL object to the terminal and the terminal uses the READ RECORD commands to read the data required to perform offline authentication of the qVSDC application.
As a result, in response to the GET PROCESSING OPTIONS command, the card returns the data shown in table 7.5 to the terminal.
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 processing the transaction with the card, the terminal authenticates the card application, checks the card expiration value and the list of blocked cards (Terminal exception file). If the card and terminal decide to approve the operation offline as a result of these checks, this is what happens. If either the card or the terminal believes,

Response data for the GET PROCESSING OPTIONS command
Tag Name of the data object cryptogram Type
AAC ARQC TC
‘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 the terminal screen) + + +
‘5F20’ Cardholder Name + +

If a 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 allows you to significantly reduce the transaction processing time by:
using pre-processing of a transaction by a terminal;
end of the card dialog with the terminal either immediately after responding to the GET PROCESSING OPTIONS command in the case of online authorization, or after processing the GET PROCESSING OPTIONS command and then reading the data required for offline authentication, in the case of an offline operation;
using the Fast DDA algorithm and limiting the size of the RSA key module (no more than 1024 bits);
dynamic signature calculations are performed only when the transaction is processed offline.

In conclusion, we will briefly focus on the full VSDC profile. Terminals that support this profile must be equipped with special card holders that allow you to guarantee that the card will remain in the reader’s work area for a long time (enough time to authorize a contactless operation in real time). In this case, the transaction is processed in exactly the same way as when using the VSDC application via the contact interface: the transaction can be served online or offline, script processing and authentication by the application of the card of its Issuer can be used, offline counters are reset after successful authorization of the online operation, and so on. You can also reset the VLP Available Fund value. To do this, just set bit 5 of byte 3 of the ADA object to 1. This bit instructs the application to set the VLP Available Funds value to the VLP Funds Limit value when the cardholder has been successfully verified using the PIN Offline method.
At the same time, there are restrictions on the functionality of the full VSDC app. Verification of the cardholder using the method

PIN Offline is only possible if the PIN code is encrypted when it is transmitted to the card (Encrypted PIN Offline).

VISA Contactless
Comparison of VISA Contactless card profiles
Main criteria MSD qVSDC full VSDC
Fast transactions (<500ms) + + —
Online fraud protection + + +
Protection against forgery in offline mode — + +
Control the offline counters — + +
Offline PIN — — +

The values of special fields for authorization and clearing messages used for contactless payments in the VISA network are listed below:
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 can take the values 2, 5, and 8 depending on the terminal’s capabilities and the requirements of a particular market.
Completing the review of VISA contactless technologies, it is necessary to mention VISA Wave cards, with which THE payment system started its projects on contactless payments in the countries of the Asia-Pacific region. This technology is gradually being phased out and is listed here because of its widespread popularity in the market and only to give the reader an idea that it has little in common with the officially recognized VISA contactless card profiles described above.
VISA Wave cards are cards with a dual interface. They can be used both online (Malaysia) and offline (Taiwan). PIN code is not used for verification of the cardholder.
Processing a VISA Wave card transaction is exactly the same as processing a VSDC card transaction that works through the contact interface, up to the processing of the INTERNAL AUTHENTICATE command (all VISA Wave cards support DDA). After processing this command, the transaction on the side of the card is completed. Next, the terminal checks the dynamic card signature received in response to the INTERNAL AUTHENTICATE command, and depending on the verification result, continues processing the transaction through the magnetic card acceptance infrastructure.