1.

EMV ISSUER Interoperability Best Practices

#
1

IWGVD009-V00 Impact Date Posted

January 2005

Best Practice Description

Support for Cardholder Confirmation Requiring cardholder confirmation on cards (Application Priority Indicator bit 8 = 1) may impact the cards' usability at terminals that do not support cardholder confirmation. Terminals not supporting cardholder confirmation will not allow the selection of card applications that require it. Issuers should therefore weigh the cardholder service benefits of requiring cardholder confirmation against the risk of being unable to use the application at terminals not providing for cardholder confirmation. A) For Issuers of cards containing a single payment application, it is recommended that cardholder confirmation is not set within the application. B) For Issuers of cards containing multiple payment applications, it is recommended that cardholder confirmation not be set on the primary application of the card, i.e. the application that is duplicated on the cards magnetic stripe. For additional guidance on the setting of cardholder confirmation, Issuers should consult their payment system.

Reference
EMV Book 1, Section 12.4 Step 2 EMV Book 1 Table 49

A) During Application Selection when there is only one mutually supported application and cardholder confirmation is required by the card application (bit 8 of the API is set to 1), but the terminal does not provide for confirmation by the cardholder, the terminal terminates the session. B) When multiple applications are mutually supported and the terminal does not provide for cardholder confirmation, applications requiring cardholder confirmation are excluded from possible selection. If all mutually supported applications require cardholder confirmation and the terminal does not provide for cardholder confirmation, no applications are available for selection and the transaction is terminated.

Use of Issuer Public Key Exponent The terminal uses the card's Issuer Public Key with an 16 exponent of either 3 or 2 +1 during RSA calculations associated Offline Data Authentication and Offline Enciphered PIN. It is recommended that issuers choose an exponent of 3 because use of the longer exponent adversely impacts transaction times at certain devices.

Use of the longer exponent results in longer transaction times at certain devices.

January 2005

EMV Book 2, Sections 5.1 and 6.1

December 2009

1. EMV ISSUER Interoperability Best Practices

#
3

IWGVD009-V00 Impact Date Posted

January 2005

Best Practice Description

Payment Systems Interoperability Tools Payment Systems have developed documentation, tools, and processes to assist Issuers in ensuring that cards issued comply with payment system rules and policies. As part of their EMV implementation processes, Issuers should ensure that they obtain and use the appropriate Payment Systems tools during implementation of their programs.

Reference

Not implementing this practice could potentially lead to violations of payment system rules and policies or could lead to interoperability problems with their cards.

EMV Card Application Features Issuers should assure that the card platform supports the application features that are to be personalized on the card. For example, cards personalized with DDA support must support RSA and DDA processing. Cards personalized with Offline PIN support must support the VERIFY command.

Not implementing this practice result in Issuers purchasing cards that do not meet their full requirements.

January 2005

Application Label Issuers should ensure that applications on cards with multiple payment applications are encoded with an appropriate Application Label. The display of this Application Label allows the cardholder to distinguish between the supported applications during the cardholder selection process.

If the Application Labels are not properly encoded, If the cardholder is presented with multiple payment applications at the Point-of-Transaction, they will not be able to distinguish between payment applications if the Application Labels are not properly encoded.

January 2005

EMV Book 4, Section 11.3 EMV Book 1, Section 11.3.4, (see note below table 45)

Allowable Padding Issuers should only use 00 bytes for padding since FF may be dropped from future versions of the Specifications. For more information, please refer to EMVCo Application Note 22, ISO Padding of Constructed Data Objects.

Not implementing this practice will prevent possible future use by ISO of private class constructed data objects having tags >31.

January 2005

Book 3, Annex B1

Offline Data Authentication Issuers should consider personalizing cards to attempt to go online when SDA or DDA fails as opposed to immediately declining offline.

Not implementing this practice may result in unwarranted declines.

January 2005

Book 3, Section 10.7

December 2009

1. EMV ISSUER Interoperability Best Practices

#
8

IWGVD009-V00 Impact Date Posted

January 2005

Best Practice Description

Length of Issuer and ICC Public Key Issuers should choose an Issuer Public key or an ICC Public key whose length in bits is a multiple of 16.

Reference

Some older terminals may have a problem with handling keys that are a multiple of 8 bits but not 16 bits.

ATC Checking by Issuer The Issuer host may receive duplicate ATC values for each authorization when the previous authorization request resulted in an Online PIN failure. Issuers should consider not automatically declining transactions solely due to this condition as an indication of fraudulent activity.

Many ATMs respond to RC55 by requesting a PIN re-entry without going back into EMV processing. Therefore the ATC will not increment for the second authorization request. Not implementing this practice may result in unwarranted declines.

January 2005

10

The Interpretation of Historical Bytes in ATR by Terminals Certain terminals in France incorrectly process cards which have certain specific values in the historical bytes in the ATR. Although the use of historical bytes is outside the scope of EMV, it is recommended not to use value 04 in the 2nd byte of the historical bytes. The error is definitively on the terminal side, and EMVCo is working with the terminal vendor to have a fix available, nevertheless the number of terminals in the field is such that it is likely to take long before field resolution is complete. In the meantime issuers should therefore take this recommendation into account when issuing cards.

Not implementing this practice could cause the termination of transactions and negative cardholder experience at these problematic French terminals

May 2007

I0061

December 2009

1. EMV ISSUER Interoperability Best Practices

#
11

IWGVD009-V00 Impact Date Posted

November 2009

Best Practice Description

Requesting Terminal AID in PDOL or other DOLs A review of existing terminals shows that some terminals do not populate the data element named Application Identifier (AID) terminal (tag '9F06') correctly. A card would request this data in the PDOL or another DOL if the card needed this Terminal AID for internal card processing. This best practice alerts issuers that the Terminal AID value returned from the terminal might not be correct. EMVCo has published Draft Specification Bulletin #75 that clarifies the population of Terminal AID, but it will take many years for currently installed terminals that do not populate Terminal AID correctly to be removed from the field. Therefore, cards should not rely on Terminal AID for important processing decisions.

Reference

Any card processing dependent upon receiving an accurate Terminal AID from the terminal might encounter difficulties due to the terminals that do not populate this data element correctly.

December 2009

2. EMV ACQUIRER Interoperability Best Practices

#
1

IWGVD005-V00

Best Practice Description

Supporting EMV-approved Features Acquirers and merchants should ensure that their devices use the features for which EMVCo approved its kernel. Devices should not use features that were not tested during EMVCo Type Approval. Features that were included in Type Approval should not be turned off. For example, if the device kernel was approved with Offline PIN support, the device shall support a PIN pad for Offline PIN.

Impact
Not implementing this practice could lead to unpredictable transaction results.

Date Posted
January 2005

Reference

Terminal support of Online Cryptogram Validation Data To facilitate validation of the online cryptogram, the device [SHALL] send the same data in the online authorization that was sent to the card in the first GENERATE AC command. The device shall send the same data in the batch data capture message that was sent to the card in the last GENERATE AC command preceding the sending the batch data capture message. For example, when a tip is added to the Transaction Amount at the end of the transaction, both the amount used in the GENERATE AC command and final amount should be sent in the batch-clearing message.

Not implementing this practice could lead to failures in the Card Authentication process because data used to validate the cryptogram is different from the data used to generate the cryptogram.

January 2005

Book 4, Section 12

Terminals Language Support and display of the Application Preferred Name Acquirers should ensure that devices properly display the characters required to support the language of the location where the terminal is installed and any other supported languages. Additional character sets may be supported to allow display of Application Preferred Name in other character sets. For example, if the terminal supports Issuer Code Table7, the terminal will be able to display Application Preferred Names requiring the Greek alphabet.

Incorrect terminal display of the Application Preferred Name and other screen prompts may lead to cardholder and merchant confusion.

January 2005

Book 3, Annex A, Table 33 for Issuer Code Table Index

December 2009

2. EMV ACQUIRER Interoperability Best Practices

#
4

IWGVD005-V00 Impact Date Posted

January 2005

Best Practice Description

Terminal Management Systems Acquirers are strongly encouraged to use a Terminal Management System (TMS) for the purposes of configuring and updating their EMV devices. EMV introduces features, functions and required data to terminals that are more effectively managed using a TMS. Some of these features and functions are: Certificate Authority (CA) Public Key Management Terminal Action Codes Configuration Application Identifier Random Transaction Selection Parameters Terminal Processing Restrictions Floor Limits

Reference

Failure to use a Terminal Management System may make the task of managing the EMV features and data elements more difficult, time-consuming and error-prone.

A TMS is recommended to provide the Acquirer with control over the process of changing or updating data elements and features on their devices. 5 Payment Systems Interoperability Tools Payment Systems have developed documentation, tools and processes to assist Acquirers in ensuring that terminals deployed comply with scheme rules and policies. As part of their EMV implementation processes, Acquirers should obtain and use the appropriate Payment Systems tools during implementation of their programs. Not implementing this practice could potentially lead to violations of payment system rules and policies or could lead to interoperability problems with their devices. January 2005

December 2009

2. EMV ACQUIRER Interoperability Best Practices

#
6

IWGVD005-V00 Impact Date Posted

January 2005

Best Practice Description

Coding of Application PAN Sequence Number Acquirers should use care in correctly populating the PAN Sequence Number. It shall be populated from the Chip value and be coded in the correct format. Refer to the Payment Systems for more specific information and guidance.

Reference
Book 3, Annex A, Table 33

Incorrect PAN Sequence Numbers will cause ARQC validation to fail.

The Interpretation of Historical Bytes in ATR by Terminals Certain cards might have values in the historical bytes in the ATR. The use of historical bytes is outside the scope of EMV. The acquirer should ensure that deployed terminals do not select and/or reject cards based upon values in the historical bytes.

Not implementing this practice could cause the termination of transactions and unnecessary sale loss at the merchant.

February 2007

Issues List I0062

The length supported for computing Hash in SDA/DDA/CDA It is reminded that SHA-1 algorithm is designed to hash in blocks, so it is perfectly possible to hash an arbitrary size with a finite buffer. To shorten transaction duration, issuers are today reducing the number of records to be read by gathering data as much as possible resulting in an increasing number of bytes to be signed. Terminal vendors shall implement the hash algorithm to be compatible with a high number of bytes

Not implementing this practice could cause the termination of the processing.

February 2007

Issues List I0067

December 2009

3. EMV CARD VENDOR Interoperability Best Practices

#
1

IWGVD005-V00

Best Practice Description

Commands Issued at Times Not Defined in the EMV Specifications Card vendors should be aware that some terminals may send commands that are not expected by the card or commands that reference data that is not supported by the card. For example, a terminal might issue a GET DATA for the PIN Try Counter even though the card's CVM List does not include Offline CVM. Cards should avoid shutting down when they receive at an unexpected command or a command for unsupported data. Instead of shutting down, cards should return an error status indicating that the command is not supported or that the data is not available.

Consequences of Non compliance

This is being recommended to prevent interoperability problems where a transaction does not complete because a card receives a command that it is not expecting from the terminal.

Date Posted
January 2005

Reference

The Interpretation of Historical Bytes in ATR by Terminals Certain terminals in France incorrectly process cards which have certain specific values in the historical bytes in the ATR. Although the use of historical bytes is outside the scope of EMV, it is recommended not to use value 04 in the 2nd byte of the historical bytes. The error is definitively on the terminal side, and EMVCo is working with the terminal vendor to have a fix available, nevertheless the number of terminals in the field is such that it is likely to take long before field resolution is complete. In the meantime Card vendors and personalization bureaus should therefore take this recommendation into account when providing their products and/or services to issuers.

Not implementing this practice could cause the termination of transactions and negative cardholder experience at these problematic French terminals

May 2007

I0061

December 2009

4. EMV TERMINAL DEVICE VENDOR Interoperability Best Practices

#
1

IWGVD005-V00

Best Practice Description Commands Issued at Times Not Defined in the EMV Specifications
Terminal vendors should be aware that certain cards might shut down when they receive a command that is not specifically described in the EMV specification for that point in the transaction. For example, a card that does not support Offline PIN might shut down when it receives a GET DATA command for the PIN Try Counter. When possible, terminals should avoid sending commands that might not be expected by the card.

Consequences of Non compliance

This is being recommended to prevent EMVCo Type Approval test failures and potential interoperability problems where a transaction does not complete because a terminal sends a command that the card cannot process.

Date Posted
January 2005

Reference

Terminal Software Modularization It is recommended that terminal vendors adopt a modular approach to their design. A flexible, modular approach is highly recommended so that minor changes can be made without the need for major modifications to the terminals infrastructure. Also, multi-application processing will necessitate the modularization of code into core libraries that all terminal applications will use. Recommended modules are: Table-driven currency codes Cardholder and merchant clerk interface, including tabledriven prompts and responses Drivers for peripherals, including integrated Point-of-Sale device connections and printer interfaces Communication and message drivers

Not implementing this practice could increase the cost of terminal deployment and may result in long delays for terminal approval following software changes that may have affected the EMV kernel.

January 2005

Book 4, Section 8

Care should be taken to ensure that the design of modularized software architecture is such that the approved EMV kernel/software is not affected. Functions that are outside the scope of EMV such as terminal display functionality should be outside the EMV kernel so that these functions may be updated without requiring a kernel update and re-approval. December 2009

4. EMV TERMINAL DEVICE VENDOR Interoperability Best Practices

#
3

IWGVD005-V00 Date Posted

January 2007

Best Practice Description

The Interpretation of Historical Bytes in ATR by Terminals Terminal vendors should be aware that certain cards might have values in the historical bytes in the ATR. The use of historical bytes is outside the scope of EMV. Terminals should not reject cards based upon values in the historical bytes.

Consequences of Non compliance

Not implementing this practice could cause the termination of transactions and unnecessary sale loss at the merchant.

Reference
Issues List I0062

The Usage of Historical Byte in ATR for Application Selection in Terminals The use of historical bytes is outside the scope of EMV, and there are no internationally recognized standards for use of the historical bytes. EMV applications should be selected using EMV's Application Selection function. Terminals should not rely solely on historical bytes to make processing decisions.

Not implementing this practice could cause the selection of incorrect applications and may result in the termination of transactions.

January 2007

Issues List I0061

The length supported for computing Hash in SDA/DDA/CDA It is reminded that SHA-1 algorithm is designed to hash in blocks, so it is perfectly possible to hash an arbitrary size with a finite buffer. To shorten transaction duration, issuers are today reducing the number of records to be read by gathering data as much as possible resulting in an increasing number of bytes to be signed. Terminal vendors shall implement the hash algorithm to be compatible with a high number of bytes

Not implementing this practice could cause the termination of the processing.

January 2007

Issues List I0067

December 2009

10