SB nº 206: Clarification for EMV® QR Code Specifications

EMV^® Specification Bulletin No. 206 First Edition July 2018 Clarifications for EMV QR Code Specifications This Specification Bulletin proposes several clarifications in the EMV QR Code Specifications for Payment Systems, Consumer-Presented Mode version 1.0 and Merchant-Presented Mode version 1.0.

Applicability

This Spec Bulletin applies to:  EMV QR Code Specification for Payment Systems Consumer-Presented Mode version 1.0 [CPM]  EMV QR Code Specification for Payment Systems Merchant-Presented Mode version 1.0 [MPM] Related Documents  None

Description

EMVCo has received queries on the [CPM] and [MPM] since their publication in July, 2017. This specification bulletin contains several clarifications as a result of those queries, and they are intended to improve the reading and ensure consistent implementations of the specifications. There are no functional changes to the specifications.

countries.

Specification Changes Change for [CPM] 1. Presence of the Application PAN (tag '5A') and Track 2 Equivalent Data (tag '57') in the POI Data. In Table 6.1, List of POI Data, the Application PAN (tag '5A') and Track 2 Equivalent Data (tag '57') are defined with the condition of presence being, "Either Track 2 Equivalent Data must be present or Application PAN must be present." After the existing condition sentence, add the following new sentences: At least one of the two data objects must be present in the POI Data. Although it is not precluded that both data objects are present, considerations should be given, for example, relating to the overall size of data in the QR Code, when determining whether to include both data objects in the POI Data. Please check with the respective payment systems for specific implementation requirements. Changes for [MPM] 1. Clarification of intended users for Merchant Account Information Templates (IDs "26" – "51") In Table 4.1, Allocation of Merchant Account Information (IDs"02" to "51"), for the row "26" – "51", change the Meaning from: Templates reserved for additional payment networks. For content of this template, please refer to Table 4.2. to: Templates reserved for additional any payment networks fulfilling the requirements in section 4.7.11, Merchant Account Information Template (IDs "26" to "51"). For content of this template, please refer to Table 4.2.

countries.

2. Clarification of several data definitions  Table 3.6: Data Objects Under the Root of a QR Code Change the following rows as shown below: Name ID Format Length Presence Comment Merchant Account Information "02"- ans "51" Each M var. up to "99" At least one Merchant Account Information data object shall be present. RFU for EMVCo "65"- S "79" Each O var. up to "99" Data objects reserved for EMVCo Unreserved Templates "80"- S "99" Each O var. up to "99" Unreserved Templates  Table 0.1: Data Objects for Additional Data Field Template (ID "62") Change the following rows as shown below: Name ID Format Length Presence RFU for EMVCo "10"- S var. O "49" Payment System specific "50"- S var. O templates. "99"  Table 3.8: Data Objects for Merchant Information—Language Template (ID "64") Change the following row as shown below: Name ID Format Length Presence RFU for EMVCo "03"–"99" S var. up to "99" Data objects reserved for EMVCo

countries.

 Table 4.2: Data Object ID Allocation in Merchant Account Information Template (IDs "26" to "51") Change the following row as shown below: ID "01""99" Meaning Format Length Presence Comment Payment network S specific var. O Association of data objects to IDs and type of data object is specific to the Globally Unique Identifier.  Table 0.2: Data Object ID Allocation in Payment System Specific Templates Change the following row as shown below: ID Meaning Type Length Presence Comment "01"- Payment System S "99" specific var. O Association of data objects to IDs and type of data object is specific to the Globally Unique Identifier.  Table 0.3: Data Object ID Allocation in Unreserved Templates (IDs "80" to"99") Change the following row as shown below: ID Meaning Type Length Presence Comment "01"- Context Specific S var. O "99" Data Association of data objects to IDs and type of data object is specific to the Globally Unique Identifier.  4.4 Data Object Length After section 4.4.1.2, add the following sentence: Please note that the total size of data within a template must not exceed the maximum allowed length of "99". 3. Clarification on the computation of the CRC Please change Requirement 4.7.3.2 to the following:

4.7.3.2 Following the calculation of the checksum, the resulting 2-byte hexadecimal value shall be encoded as a 4-character Alphanumeric Special value by converting each nibble to the corresponding an Alphanumeric Special character. A nibble with hex value ‘0’ is converted to "0" (= hex value ‘30’), a nibble with hex value ‘1’ is converted to "1" (= hex value ‘31’) and

countries.

so on. Hex values ‘A’ to ‘F’ must be converted to uppercase characters "A" to "F" (= hex values ‘41’ to ‘46’). Example: a CRC with a two-byte hexadecimal value of '007B' is converted to "007B" and included in the QR Code as "6304007B".

countries.

Legal Notice

The EMV^® Specifications are provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV^® Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV^® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV^® Specifications

countries.