PCI Watch

Tracking changes across the Payment Card Industry

Book C-4 Kernel Specification

v2.11 Specifications
Contactless Acceptance Device

EMV® Contactless Specifications for Payment Systems Book C-4 Kernel 4 Specification Version 2.11 June 2023

v2.11

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.

v2.11

Revision Log – Version 2.11 The following changes have been made to the document since the publication of Version 2.10. Some of the numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins. The numbering of existing requirements did not change, unless explicitly stated otherwise. Incorporated changes described in the following Specification Updates:

  • Kernel C-4 Specification Bulletin 287. Other editorial changes:
  • None v2.11 1. 1. 1. 1. 1. 1.5. 1.5. 1. 1. 2. 2.1.1 2.1.2 2.1.3 2.1.4 2.1. 2. 2.2.1 2.2.2 2.2.3 2.2. 2. 4. 4. 4. 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3. v2.11 Page v 4.3. 5. 5. 5. 5. 6. 6. 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2. 7. 7. 7.2.1 7.2.2 7.2.3 7.2. 8. 8. 8.2.1 8.2.2 8.2.3 8.2.4 8.2.5 8.2. 9. 9. 9.2. v2.11 9.2.2 9.2.3 9.2. 10. 10. 10.2.

10.2.2 Zero Amount Allowed and Status Check Requested Validation...102 10.2. 10.2. 11. 11. 11.2. 11.2. 11.2. 11.2. 11.2. 11.2. 12. 12. 12.2. 12.2. 12.2. 13. 13. 13. 14. 14. 14. A.

v2.11

A. A. A. B. B.

v2.11

v2.11

v2.

v2.11

Requirements – Terminal Action Analysis – Offline Only Compare Denial Codes.. 97 Requirements – Terminal Action Analysis – Online Only Compare Denial Codes..

v2.11

Requ

v2.11

/ 166 1

Introduction

Kernel 4 is a contactless Reader kernel designed for interoperability with a suitable contactless payment application including American Express Contactless Payment Products. 1.1

Scope

This document, the EMV Contactless Specifications for Payment Systems, Kernel 4 Specification, defines the mandatory and optional functionality required when implementing Kernel 4.

1.2 Audience This specification is intended for use by system designers in payment systems and financial institution staff responsible for implementing financial applications.

1.3 Volumes of Contactless Specifications This specification is part of an eleven-volume set: Book A: Architecture and General Requirements Book B: Entry Point Specification Book C-2: Kernel 2 Specification Book C-3: Kernel 3 Specification Book C-4: Kernel 4 Specification Book C-5: Kernel 5 Specification Book C-6: Kernel 6 Specification Book C-7: Kernel 7 Specification Book C-8: Kernel 8 Specification Book E: Security and Key Management EMV Level 1 Specifications for Payment Systems – EMV Contactless Interface Specification

v2.11

/ 166 1.4 Reference Material The following specifications and standards contain provisions that are referenced in this specification. The latest version shall apply unless a publication date is explicitly stated. If any provision or definition in this specification differs from those in the listed specifications and standards, the provision or definition herein shall take precedence. [EMV 4.3] [EMV 4.3 Book 1] [EMV 4.3 Book 2] [EMV 4.3 Book 3] [EMV 4.3 Book 4] [PTOKS2.0] [ISO 3166] [ISO 4217] [ISO 7813] [ISO 7816-5] [ISO 7816-4] [ISO 8583] EMV® Integrated Circuit Card Specifications for Payment Systems, Version 4.3, November 2011, including: EMV Integrated Circuit Card Specifications for Payment Systems, Book 1, Application Independent ICC to Terminal Interface Requirements EMV Integrated Circuit Card Specifications for Payment Systems, Book 2, Security and Key Management EMV Integrated Circuit Card Specifications for Payment Systems, Book 3, Application Specification EMV Integrated Circuit Card Specifications for Payment Systems, Book 4, Cardholder, Attendant, and Acquirer Interface Requirements EMV Payment Tokenisation Specification Technical Framework, v2.0 Codes for the representation of names of countries and their subdivisions Codes for the representation of currencies and funds Identification cards – Financial transaction cards Identification cards – Integrated circuit cards – Part 5: Registration of application providers Identification cards – Integrated circuit cards – Part 4: Organization, security and commands for interchange Bank card originated messages – Interchange message specifications – Content for financial transactions

v2.11

/ 166 [ISO 8859] [ISO 639] [PCI-CPoC] 8-bit character encodings. Language codes Contactless Payment on COTS (CpoC™), Version 1.0, December 2019

v2.11

/ 166 1.5 Notational Conventions 1.5.1 Use of Terms Terms and definitions are described in Book A: Architecture and General Requirements, with the addition of the following. Delayed Authorisation In cases where a reader has been deployed in an environment where a real time online transaction authorisation is never possible, a delayed authorisation may be performed. A “Delayed Authorisation” as referred to in this specification is processed by the reader as a Partial Online contactless transaction, with mandatory Offline Data Authentication. Separately from the initial reader and card interaction, a later authorisation request may be made to an Issuer’s system for the purposes of account verification or reservation of funds against an account. Partial Online A Partial Online contactless transaction is one where the card may be removed from the operating field of the reader after the first GENERATE AC response has been received. The result of the transaction is based on the response from the Issuer’s authorisation system. mPOS The term “mPOS” is used to refer to a mobile point of sale where a commercial off-the-shelf (COTS) device, such as a mobile phone or tablet, is used either standalone, to form contactless only mPOS system using the devices NFC interface, or in conjunction with a hardware accessory to form a contact and contactless mPOS system. The functions performed within the “Terminal” or “Reader” definitions may be provided by a mPOS device.

1.5.2 Reserved for Future Use (RFU) A bit specified as Reserved for Future Use (RFU) shall be set as specified, or to 0b if no indication is given. An entity receiving a bit specified as RFU shall ignore such a bit and shall not change its behaviour, unless explicitly stated otherwise. A data field having a value coded on multiple bits or bytes shall not be set to a value specified as RFU. An entity receiving a data field having a value specified as RFU, shall behave as defined by a requirement that specifically addresses the situation, or shall consider it a protocol error if no specific behaviour is defined.

v2.11

/ 166 1.6 mPOS Architectures This section describes the mPOS architectures that differ from the traditional POS systems that use specific devices designed for the purpose of acting as part or all of a card payment acceptance system. mPOS systems use commercial off-the-shelf (COTS) devices, such as mobile phones and tablets, as part or all of the card payment acceptance system. The following terms are used in the mPOS architecture:

  • mPOS (mobile Point Of Sale) – where a consumer mobile device forms part of a portable card acceptance system.
  • COTS (Commercial Off-The-Shelf) – a commercial off-the-shelf consumer mobile device such as a phone or tablet.
  • CPoC (Contactless Payment on COTS) – contactless payment using the NFC interface of a consumer mobile device. Where contactless transactions are performed directly with the NFC contactless interface of a COTS device, this is known as Contactless Payment on COTS (CPoC), also known as Tap on Phone.
  • SPoC (Software PIN on COTS) – PIN entry via a consumer mobile device. Where PIN entry is performed directly on to a COTS device, this is known as Software PIN on COTS (SPoC), also known as PIN on Glass.
  • Accessories – an additional hardware device or dongle that may provide card interfaces, PIN entry, amount entry, or display, that is to be used in conjunction with a COTS device to form an mPOS card acceptance system. An mPOS system will either:
  • comprise entirely of a COTS device only, or
  • may include additional devices to provide features such as card interfaces or PIN entry. The possible POS architectures are based on PIN entry and card interface locations and capabilities, as shown in Table 1-1: Terminal and mPOS Architectures Architecture Reference Table 1-1: Terminal and mPOS Architectures Terminal Architecture PIN Entry Location Contact Interface Location Contactless Interface Location Not applicable Traditional POS POS POS POS A (Accessory) COTS device and Accessory accessory 1 Accessory Accessory v2.11 / 166 Architecture Reference Terminal Architecture PIN Entry Location Contact Interface Location ASP (Accessory, Software PIN) COTS device and accessory1 supporting SPoC COTS device Accessory Contactless Interface Location Accessory C COTS device N/A N/A supporting CPoC Contactless COTS device CSP COTS device COTS N/A supporting CPoC device Contactless, and SPoC 2 Software PIN COTS device Notes: 1 If an accessory device is being used, it will provide a contact and contactless interface. 2 The mPOS-CSP architecture is mentioned in this document for completeness. However, at the time of writing, this architecture is prohibited by [PCI-CPoC]. Therefore, solutions using this architecture can only be deployed after obtaining prior approval. Permission may be granted, based on bespoke functional and security approvals, and will state any restrictions applicable to the deployment, such as number, geographic or duration. The mandated and optional requirements, throughout this specification, are described in generic terms based on traditional POS systems. However, unless otherwise stated, any requirement in this specification is applicable to both traditional POS systems and mPOS systems. Where additional direction is needed for mPOS systems, clauses to include or exclude mPOS architectures are added using phrases such as applicable/not applicable, supported/not supported or including/excluding. References to requirements and functions specific to mPOS architectures are indicated by the prefix “mPOS-“. The mPOS Requirements for the various architectures are detailed in Annex C. Note: Security and functional approvals are determined based on whether mPOS functionality is provided by a dedicated accessory device or by software on the COTS device directly. v2.11 / 166 1.7 Overview This volume includes the following sections and annexes: Section 1 contains general information that helps the reader understand and use this specification. Section 2 describes the Contactless EMV Mode in which a contactless card and reader can operate, and details the different flows that a contactless transaction can take. Section 3 provides a high-level overview of processing according to this specification. Section 4 – 13 detail the different steps that occur in a contactless transaction and specify the command and processing requirements for each step of the transaction. Annex A details the data elements used in contactless transaction processing using Kernel 4. Annex B details the Configuration Data that is provided to the kernel by the Terminal and by Entry Point. Annex C details the mPOS requirements Annex D - Glossary is a glossary of terms and abbreviations used in this specification. v2.11 / 166 2 Contactless EMV Mode and Transaction Flows This section describes the mode in which a contactless card and reader can operate. It also details the different flows that a contactless transaction can take.

2.1 Contactless EMV Mode of Operation This specification supports only EMV Mode in which the Card and Terminal can operate. This specification no longer supports Magstripe Mode:

  • EMV mode – This mode of operation is designed for Issuers and Acquirers supporting EMV data in the authorisation and clearing messages.

2.1.1 Transaction support for Contactless EMV Mode All Readers (including all mPOS architectures) must implement and support only EMV mode, and must not implement and support Magstripe Mode (as per requirements in section 4.3.7). Whether a transaction is capable of proceeding in EMV mode is determined by the ability of the Card and the Terminal to both support EMV mode, as shown in Table 2-1. Table 2-1: Contactless Mode Selection Reader Configured to Support EMV Mode Only Card Supports Mag-Stripe Mode only Not supported. Cardholder is instructed to try another interface, if supported, or try another means of payment. For mPOS-C, mPOS-CSP - Not supported. Cardholder is instructed to try another means of payment. Card Supports Both Mag-Stripe and EMV Modes EMV mode transaction Card Supports EMV mode only EMV Mode transaction

v2.11

/ 166 In this version of the specification Bit 7 and Bit 8 in Contactless Reader Capabilities (Tag '9F6D') will always be set, resulting in Terminal Type – Modified (shown in Table 4-3) Bit 7 and Bit 8 also set. Similarly, Byte 1 Bit 4 to Bit 7 in the Enhanced Contactless Reader Capabilities (shown in Table 4-4) are set to ‘1100'. This data is usually provided to the Card during the GET PROCESSING OPTIONS command. The configuration of Terminal Type – Modified and Enhanced Contactless Reader Capabilities should not be set with conflicting values. If the card requests Terminal Type via the Processing Options Data Object List (PDOL) in the GET PROCESSING OPTIONS command, the reader instead returns Terminal Type – Modified (as described in section 4.3). If the card requests the Enhanced Contactless Reader Capabilities via the Processing Options Data Object List (PDOL) in the GET PROCESSING OPTIONS command the reader shall return the Enhanced Contactless Reader Capabilities. The resulting Terminal Type – Modified and/or the Enhanced Contactless Reader Capabilities data element is requested by the Card via the PDOL to enable the Card to determine its transaction mode. The Card indicates which mode it supports for the transaction in the Application Interchange Profile (AIP) Byte 2 Bit 8 – it is set to 1b to indicate that the Card and Issuer support both EMV and Magstripe Mode, and to 0b to indicate that only Magstripe Mode is supported. The reader shall follow requirements 4.3.7.1 to 4.3.7.3 in order to determine transaction support for EMV Mode. 2.1.2 [Section removed] The content in this section has been purposely removed from this specification, as Expresspay Magstripe Mode is no longer supported. 2.1.3 [Section removed] The content in this section has been purposely removed from this specification, as Expresspay Magstripe Mode is no longer supported.

2.1.4 Contactless EMV Mode Transactions When a contactless transaction is performed in EMV mode, the reader is capable of sending the standard EMV data elements and there are no restrictions.

2.1.5 Contactless Mobile Transaction When a transaction is performed as Contactless Mobile the reader may prompt for an action to be performed on the Mobile device by exiting the transaction with a Try Again Outcome.

v2.11

/ 166 A Contactless Mobile:

  • Follows the Contactless EMV Mode of Operation requirements as per section 4.3.7.
  • May support Mobile CVM (typically, a four-digit code stored in the Card, entered by the user via the phone device keypad and verified by the Card).

2.1.5.1 Mobile CVM Contactless Mobile supports the Mobile CVM

This permits cardholder authentication on the Card using one of the mobile based authentication methods available. The reader manages the requirements for Cardholder Verification and processes the CVM List as for EMV. However, the reader performs no part in the Mobile CVM verification process – the Mobile CVM is captured and verified by an application on the Card, prior to the transaction. The results are passed to the reader as Mobile CVM Results in the response to the GET PROCESSING OPTIONS command or as an exception code in the response to the GENERATE AC command.

2.2 Contactless Transaction Processing A contactless transaction can be performed in the following ways:

  • Offline (not supported for mPOS-C, mPOS-CSP terminals)
  • Partial Online with either:
  • Immediate authorisation or
  • Delayed authorisation (a “Delayed Authorisation” transaction). This shall not be supported for mPOS-C, mPOS-CSP terminals. Figure 2-1 shows the transaction flow for a contactless transaction and highlights the different processes performed for each of these options. v2.11 / 166 Entry Point Processing Card Activation Application Selection Init application processing Read application data Processing restrictions Offline data authentication Figure 2-1: Transaction Flow Overview Cardholder verification Terminal risk management 1st terminal action analysis 1st card action analysis Offline data authentication CDA sig check N Online transaction? Y Authorisation type? Delayed Immediate Offline Y Unable to go online? N Online processing Partial online Delayed authorisation Legend Conditional Step Mandatory Step Transaction completion ‘Try again’ ‘End Application’ ‘Try another interface’ ‘Approved’/’Declined’ 2.2.1 Premature card removal If the cardholder removes the card from the operating field without being prompted to do so, then the kernel returns control to Entry Point, passing an Outcome of Try Again with the following parameter settings: v2.11 / 166 Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout B N/A N/A Yes
  • Message Identifier: '21' (“Present Card Again”)
  • Status: Processing Error
  • Hold Time: 0
  • Language Preference Yes
  • Message Identifier: '21' (“Present Card Again”)
  • Status: Ready to Read.
  • Hold Time: 0
  • Language Preference No No N/A N/A N/A Zero Requirements – Card Early Removal 2.2.1.1 If the card leaves the operating field before the cardholder is prompted to remove it from the field, then the reader shall invoke the User Interface Request Message to display Message Identifier: '21' (“Present Card Again”) and return control to Entry Point. v2.11 / 166 2.2.2 Offline Transaction During an offline transaction, the card and reader either approve or decline a transaction without further online processing. The enablement of Offline Data Authentication is mandatory for the deployment of terminals in offline environments. Only 1st Terminal Action Analysis and 1st Card Action Analysis are performed. mPOS-C, mPOS-CSP terminals do not support offline transactions and shall be online only readers. Requirements – Offline Transaction 2.2.2.1 If a reader indicates that it is offline capable (by setting bits 3-1 of Terminal Type (Tag '9F35') appropriately), then the reader shall be able to perform an offline transaction.

2.2.3 Partial Online Transaction In a Partial Online transaction, the interaction between the card and the reader ends after 1st Card Action Analysis has completed. The enablement of Offline Data Authentication is mandatory for the deployment of terminals in online capable environments where offline transactions are also possible. The result of the transaction is based on the response from the Issuer’s authorisation system. Requirements – Partial Online Transaction 2.2.3.1 If a reader indicates that it is online capable (by setting bits 3-1 of Terminal Type (Tag '9F35') appropriately), then the reader shall be able to perform a Partial Online transaction (i.e. without a second GENERATE AC being sent to the card). A reader performing a Partial Online transaction shall prompt the cardholder to remove the card from the field immediately after the completion of 1st Card Action Analysis. The card should be removed from the operating field only when the reader indicates that it is time to do so. Once the reader has indicated that the card can be removed, whether the card is actually removed or not, the reader will continue to process the transaction as planned. Requirements – Partial Online Transaction Completion 2.2.3.2 If a reader is online capable, and the reader is conducting a Partial Online transaction, then the reader shall complete the transaction as a Partial Online transaction whether the user leaves the card in the field or removes the card when instructed to do so.

v2.11

/ 166 2.2.4 Delayed Authorisation In cases where a reader has been deployed in an environment where a real time online transaction authorisation is not possible, a delayed authorisation may be performed. A reader indicates it supports Delayed Authorisations by setting the Enhanced Contactless Reader Capabilities Byte 4 Bit 7 to 1b. A “Delayed Authorisation” as referred to in this specification is processed by the reader as a partial online transaction, with the interaction between the Card and reader being completed after the 1st Card Action Analysis. Offline Data Authentication support is mandatory for all readers supporting Delayed Authorisations. The enablement of Offline Data Authentication is mandatory for the deployment of terminals in delayed authorization environments. If it is determined that the transaction is to be sent online, the transaction shall be approved at the Terminal and a subsequent delayed authorisation request is made to an Issuer’s authorisation system for the purposes of account verification or reservation of funds against an account. mPOS-C and mPOS-CSP terminals shall not support delayed authorization. Requirements – Delayed Authorisation 2.2.4.1 If the Enhanced Contactless Reader Capabilities Byte 4 Bit 7 to 1b, and Offline Data Authentication has been performed successfully, then the reader shall be able to approve the transaction and perform a Partial Online with delayed authorisation transaction.

2.2.4.2 If the Enhanced Contactless Reader Capabilities Byte 4 Bit 7 to 1b, and the Card returns an AAC in response to the first GENERATE AC, then the reader shall not perform Offline Data Authentication and the transaction shall be declined.

v2.11

/ 166 2.3 Contactless Transaction Configurations The options for all possible combinations of processing a contactless transaction are shown in Table 2-2. Table 2-2: Contactless Transaction Combinations Contactless Terminal Configuration Card Supports either EMV Mode only or Card Supports Both Mag-Stripe and EMV Modes EMV Mode supported Partial Online with delayed authorisation The EMV transaction flow is performed until 1st Card Action Analysis is completed. Offline Data Authentication is mandatory. A card that supports EMV Mode will present a CDOL for Cryptogram Version '01'. (Not applicable for mPOS-C, mPOS-CSP) An online authorisation is performed at a later time. EMV Mode supported Offline (Not applicable for mPOS-C, mPOS-CSP) An offline transaction is performed, if offline is allowed by Issuer configuration settings and Card Risk Management. Offline Data Authentication is mandatory. A card that supports EMV Mode will present a CDOL for Cryptogram Version ‘01’. EMV Mode supported The EMV transaction flow is performed until 1st Card Action Analysis is completed. Partial Online with immediate authorization A Card that supports Expresspay EMV Mode will present a CDOL for Cryptogram Version ‘01’. After going online, the transaction result will be based on the Issuer authorization response. In case of mPOS-C or CSP, if an online connection is not possible prior to the transaction, then the transaction shall not be started. This specification supports the terminal configurations listed in Table 2-3.

v2.11

/ 166 Table 2-3: Reader Configurations Reader Configuration Definition Offline only (Not applicable for mPOS-C, mPOS-CSP) Offline only readers do not have the ability to obtain a real time online authorisation nor do they have the ability to connect online for an authorisation at a later date. Offline Only readers must perform Offline Data Authentication on all transactions. Online only Online only readers require all transactions to be sent online for authorisation and do not have the ability to approve transactions offline. Readers configured in this way do not need to enable Offline Data Authentication. The reader must decline the transaction if it is unable to go online to obtain an authorisation. Offline with Online Capability (Not applicable for mPOS-C, mPOS-CSP) Readers configured in this way are able to process transactions offline or send the transaction online for authorisation if required. Readers configured in this way must enable Offline Data Authentication. Readers of this type shall be capable of being configured to operate as Online Only readers.

v2.11

/ 166 Reader Configuration Delayed Authorisations (Not applicable for mPOS-C, mPOS-CSP) Definition In cases where a reader has been deployed in an environment where real time online transaction authorisation is never possible, a delayed authorisation may be performed. Readers configured in this way must enable Offline Data Authentication. A “Delayed Authorisation” as referred to in this specification is processed by the reader as a Partial Online contactless transaction, with mandatory Offline Data Authentication (unless the card has returned an AAC in response to the first GENERATE AC command, in which case ODA does not need to be performed). Separately from the initial reader and card interaction, a later authorisation request may be made to an Issuer’s system for the purposes of account verification or reservation of funds against an account.

v2.11

/ 166 Requirements – Transaction Combinations 2.3.1.1 If the terminal is performing a Partial Online transaction in EMV mode with an EMV card, then the card may be removed after the 1st Card Action Analysis and the terminal shall complete the Partial Online transaction in EMV mode.

2.3.1.2 If an offline terminal is EMV capable, and the terminal is performing a transaction satisfying risk management requirements with an EMV card, then the card may be removed after the 1st Card Action Analysis and Offline Data Authentication is performed, and the terminal shall complete the transaction in EMV mode.

v2.11

/ 166 3 Processing Overview The following sections provide detailed information about the interaction between the contactless card and reader during a transaction. All functions mentioned in the following sections are performed as described in this specification where detailed or otherwise as described within [EMV 4.3 Book 1] – [EMV 4.3 Book 3]. Some functionality supported by EMV is not permitted or is restricted for contactless transactions. Card Activation and Application Selection shall be performed as in Book B: Entry Point Specification, with new transactions being initiated at Start A or Start B as described in Book B. Figure 2-1 shows an overview of the contactless transaction flow from the point at which a contactless card is introduced into the operating field of a reader to the point when the reader completes the transaction. After processing a contactless transaction, the kernel returns control to Entry Point by passing an Outcome that specifies required actions from Entry Point or the terminal (POS System). Control may subsequently return to the kernel via Book B Start B. This ‘restart’ mechanism enables the kernel to process a retry for failed Mobile CVM processing. The FCI data made available to the kernel by Entry Point may contain Language Preference Code (Tag '5F2D'), which may be supplied as one of the Outcome parameters in order to indicate a preferred language for the display of User Interface Messages. According to Book A, Figure 5-2: Logical Architecture, the Terminal is responsible for any Additional processing (including Online Authorisation) and other services during a transaction. Hence, it may need to retrieve Kernel/Reader data (static and dynamic) and/or Card public data (read from the Card, but not stored in the Kernel after the transaction is finished). As per the description of the Outcome Parameters in Book A, section 6.2, the Data Record and Discretionary Data parameters are the mechanisms the Kernel has to provide data to the Entry Point, Reader and consequently, the Terminal. Data Record minimum data elements are defined in Annex A.4 for Online Authorisation and Clearing. For the Terminal to retrieve any data it needs from the Kernel, for additional processing and services, it must use the Discretionary Data Object List Configuration Data (see Annex B.1 for details). The data elements present in this data object list will, if available, be included in the Discretionary Data Outcome Parameter and the Discretionary Data Present parameter will be set to Yes for the following Outcomes: Approved, Declined, Online Request and Request Online PIN.

v2.11

/ 166 4 Initiate Application Processing 4.1 Overview During Application Initiation, the reader signals to the card that processing of the transaction is beginning. Initiate Application Processing is performed as described in [EMV 4.3 Book 3] and [EMV 4.3 Book 4]. Upon receipt of the Application File Locator (AFL) and Application Interchange Profile (AIP), the reader proceeds to read the application data records from the card. The AFL is a list of parameters identifying the files and records to be read from the card used in processing the transaction. The AIP indicates the capabilities of the card to support specific functions of the application to be taken into consideration by the reader when determining how to process the transaction.

4.2 Commands

  • GET PROCESSING OPTIONS To support Initiate Application Processing as described in [EMV 4.3 Book 3], section 10.1, the card must support the GET PROCESSING OPTIONS command as described in the following section. If the transaction is taking place as Contactless Mobile, then Mobile CVM Results shall be returned in the GET PROCESSING OPTIONS response. (See on Table 8-1: Mobile CVM Results – Tag '9F71') Requirements – GET PROCESSING OPTIONS 4.2.1.1 A reader shall send the GET PROCESSING OPTIONS command to the card following Application Selection. v2.11 / 166 4.3 Processing Requirements 4.3.1 Pre-PDOL Processing The reader must reset Contactless Reader Capabilities Byte 1 Bit 4 to 0b, ‘CVM Not Required’ and Enhanced Contactless Reader Capabilities Byte 3 to 00, since these are specific only to the context of the current transaction. All other Enhanced Contactless Reader Capabilities settings (bytes 1, 2 and 4) are defined at Terminal configuration. If the reader CVM Required Limit Exceeded indicator is set, then the reader shall set:
  • Contactless Reader Capabilities Byte 1 Bit 4 to 1b, ‘CVM Required’
  • Enhanced Contactless Reader Capabilities Byte 3 Bit 7 to 1b, ‘CVM Required’ If the reader is an offline-only reader (i.e. if the Terminal Type is 'x3' or 'x6') or the reader can determine that it is currently unable to go online for authorisation, (excluding mPOS-C, mPOS-CSP), then it will set Enhanced Contactless Reader Capabilities Byte 3 Bit 8 to 1b, ‘Terminal is offline only’. For Online Only Terminal (for example mPOS-C or mPOS-CSP terminal), if the terminal can determine that it is currently Unable to go Online for authorization, then the kernel returns control to Entry Point, passing a Final Outcome of End Transaction. v2.11 / 166 Requirements – Pre-PDOL Processing 4.3.1.1 The reader shall reset Contactless Reader Capabilities Byte 1 Bit 4 to 0b, ‘CVM Not Required’ and Enhanced Contactless Reader Capabilities Byte 3 to 00.

4.3.1.2 If the Reader CVM Required Limit Exceeded indicator is set then the reader shall set Contactless Reader Capabilities Byte 1 Bit 4 to 1b, ‘CVM Required’, and shall set Enhanced Contactless Reader Capabilities Byte 3 Bit 7 to 1b, ‘CVM Required’.

4.3.1.3 If the reader is an offline-only reader (Reader type 'x3' or 'x6') or the reader has determined that it is unable to go online, then the reader shall set Enhanced Contactless Reader Capabilities Byte 3 Bit 8 to 1b, ‘Reader is Offline Only’.

4.3.1.4 If the reader is an Online Only reader, (e.g. mPOS-C or mPOSCSP), and Unable to go Online then the terminal shall decline the transaction, returning control to Entry Point as defined in 13.3.

4.3.2 PDOL Processing The reader determines whether the optional PDOL was supplied by the card application in response to Application Selection. If the PDOL is not present, then the reader formats the GET PROCESSING OPTIONS command with the command data field of '8300'. Requirements – GPO Without PDOL Data 4.3.2.1 If the card did not specify a PDOL in the response to Application Selection, then the reader shall send the GET PROCESSING OPTIONS command with the command data field set to '8300'.

v2.11

/ 166 If the PDOL was received, the reader formats the GET PROCESSING OPTIONS command to include the data elements requested in the PDOL to be sent to the card with this command. The data elements for the PDOL must be formatted as defined by [EMV 4.3 Book 3], section 5.4. Requirements – PDOL Data in GPO 4.3.2.2 If the card specified a PDOL in response to Application Selection, then the reader shall send the GET PROCESSING OPTIONS command with the requested PDOL data, except as described in requirement 4.3.3.1.

v2.11

/ 166 4.3.3 Terminal Type – Modified If the PDOL requested Terminal Type (Tag '9F35') and does not contain the Enhanced Contactless Reader Capabilities (Tag ‘9F6E’), the reader returns Terminal Type – Modified (as shown in Table 4-3) instead of Terminal Type. These values are set by the reader based on the Terminal Type combined (OR’d) with a proprietary data element, Contactless Reader Capabilities (Tag '9F6D'), that is stored in the reader. See Table 4-1 and Table 4-2 for the values of these data elements. Note that the Terminal Type – Modified value is transient and valid only for the purpose of determining whether contactless EMV mode is supported by both the Terminal and the Card for the current transaction being processed. The value of the (unmodified) Terminal Type (Tag '9F35') as defined in the configuration data for the Terminal must remain unchanged and only this unmodified Terminal Type should be present in any authorisation and financial submission messages that are sent to the acquirer. For example: If Terminal Type (Tag '9F35') in Terminal Configuration data and Contactless Reader Capabilities (Tag '9F6D') then Terminal Type – Modified = '22', = 'C8', = 'EA'. In the above example, the value of the Terminal Type – Modified that is provided to the Card in the GET PROCESSING OPTIONS command would be 'EA', however the value of the Terminal Type (Tag '9F35') that would be sent in any authorisation or submission messages to an acquirer would remain as '22'.

v2.11

/ 166 Table 4-1: Terminal Type – EMV Tag '9F35' b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 1 Financial Institution 1 0 Merchant 1 1 Cardholder 0 0 1 Attended – Online Only 0 1 0 Attended – Offline with Online Capability 0 1 1 Attended – Offline Only 1 0 0 Unattended – Online Only 1 0 1 Unattended – Offline with Online Capability 1 1 0 Unattended – Offline Only Note: The Terminal Type for mPOS-C, mPOS-CSP shall be Merchant, Attended – Online only, which is XX10X001. Table 4-2: Contactless Reader Capabilities – Tag '9F6D' b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 0 Deprecated 0 0 1 Not Available for Use 0 1 0 Deprecated 0 1 1 Deprecated 1 0 0 Deprecated 1 0 1 Not Available for Use 1 1 0 1 1 1 Contactless: EMV

  • CVM Not Required (C-4 Version ≥ 2.2) Contactless: EMV
  • CVM Required (C-4 Version ≥ 2.2) Note: Bits 6 and 5 and Bits 3 to 1 are reserved and must be set to zero. In Terminal Type – Modified, these bits will correspond to the values defined in EMV Terminal Type, Tag '9F35'. Note: The Contactless Reader Capabilities for a Terminal implementing this specification shall be 11XX0XXX for CVM Not Required or 11XX1XXX for CVM Required.. Table 4-3 defines Terminal Type – Modified, which is returned from a contactless capable reader and consists of EMV Terminal Type, Tag '9F35' (Table 4-1) OR’d with Contactless Reader Capabilities, Tag '9F6D' (Table 4-2). v2.11 / 166 Table 4-3: Terminal Type – Modified b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 1 Financial Institution 1 0 Merchant 1 1 Cardholder 0 0 1 Attended – Online Only 0 1 0 Attended – Offline with Online Capability 0 1 1 Attended – Offline Only 1 0 0 Unattended – Online Only 1 0 1 Unattended – Offline with Online Capability 1 1 0 Unattended – Offline Only 0 0 0 Deprecated 0 0 1 Not Available for Use 0 1 0 Deprecated 0 1 1 Deprecated 1 0 0 Deprecated – Contactless: EMV and Mag-Stripe (C-4 Version 2.1) 1 0 1 Not Available for Use 1 1 0 Contactless: EMV
  • CVM Not Required (C-4 Version ≥ 2.2) 1 1 1 Contactless: EMV
  • CVM Required (C-4 Version ≥ 2.2) Deprecated values are for backward compatibility only and are not used/referred to in this version of the specification. The configuration of Terminal Type – Modified and Enhanced Contactless Reader Capabilities should not be set with conflicting values. Requirements – GPO Includes Modified Terminal Type 4.3.3.1 If the card requests Terminal Type, Tag '9F35' and does not request Enhanced Contactless Reader Capabilities, Tag '9F6E' in the PDOL, then the reader shall send the GET PROCESSING OPTIONS command with the modified Terminal Type value which is the Terminal Type (Tag '9F35') OR’d with the Contactless Reader Capabilities (Tag '9F6D'). v2.11 / 166 4.3.4

Shown in part. Read the original for the full text.