PCI Watch

Tracking changes across the Payment Card Industry

Book C-3 Kernel 3 Specification

v2.11 Specifications
Contactless Acceptance Device

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

150

Legal Notice

Unless the user has an applicable separate agreement with EMVCo or with the applicable payment system, any and all uses of these Specifications is subject to the terms and conditions of the EMVCo Terms of Use agreement available at www.emvco.com and the following supplemental terms and conditions. Except as otherwise may be expressly provided in a separate agreement with EMVCo, the license granted in the EMVCo Terms of Use specifically excludes (a) the right to disclose, distribute or publicly display these Specifications or otherwise make these Specifications available to any third party, and (b) the right to make, use, sell, offer for sale, or import any software or hardware that practices, in whole or in part, these Specifications. Further, EMVCo does not grant any right to use the Kernel Specifications to develop contactless payment applications designed for use on a Card (or components of such applications). As used in these supplemental terms and conditions, the term “Card” means a proximity integrated circuit card or other device containing an integrated circuit chip designed to facilitate contactless payment transactions. Additionally, a Card may include a contact interface and/or magnetic stripe used to facilitate payment transactions. To use the Specifications to develop contactless payment applications designed for use on a Card (or components of such applications), please contact the applicable payment system. To use the Specifications to develop or manufacture products, or in any other manner not provided in the EMVCo Terms of Use, please contact EMVCo. These 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 NONINFRINGEMENT, 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 these 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 these 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 these Specifications.

150 Revision Log This section outlines the notable updates that have been made to this specification since the publication of the EMV Contactless Specifications for Payment Systems Book C-3, version 2.10.

  • Updated references from EMV 4.3 to EMV 4.4. Change bars are used in the specification to denote the sections that have been updated. 1. 1. 1. 1. 1. 1.5. 1.5. 1.5. 1. 1. 1. 2. 2.2 2. 2.3. 2. 2.4. 2.4. 2.4. 2.4. 2.4. 2.4. 150 2.4. 2.4. 2. 2.5. 2.5. 2.5. 2.5. 2. 2.6. 3. 3. 3.2. 3.2.2 3. 3.3. 3.3.2 3.3.

3.3.4 Configuration Requirements for Special

Purpose

EMV Mode Readers.. 33 3. 3.4. 4. 4. 4. 4. 5.1 5. 5.2. 5.2.

150 5. 5.3. 5.3. 5. 5.4. 5.4.

5.4.3 EMV Mode Path Processing – Determine Card Transaction Disposition 50 5.4.4 5. 5.5. 5. 5.6. 5.6. 5. 5.7. 5. 5.8. 5. 5.9. 6. 6. 7. 7. 7.2. 7.2. A. A.1. A.1.

150 A.1. A.1. A. A. A. B. B.1. B.1. B.2 C. D. D. D. D. D.4. D.4. D.4. D.4. F. F.1. F.1. F. F.

150 1 General This chapter contains information that helps the reader understand and use this specification. 1.1

Scope

This document, the EMV Contactless Specifications for Payment Systems, Kernel 3 Specification, describes one of several kernels defined for use with Entry Point.

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 the Contactless Specifications This specification is part of a 12-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 D: Contactless Communication Protocol Book E: Security and Key Management Level 1 Specifications for Payment Systems, EMV Contactless Interface Specification

150 1.4 Reference Materials 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] EMV Integrated Circuit Card Specifications for Payment Systems, Version 4.4, October 2022, including: [EMV Book 1] EMV Integrated Circuit Card Specifications for Payment Systems, Book 1, Application Independent ICC to Terminal Interface Requirements [EMV Book 2] EMV Integrated Circuit Card Specifications for Payment Systems, Book 2, Security and Key Management [EMV Book 3] EMV Integrated Circuit Card Specifications for Payment Systems, Book 3, Application Specification [EMV Book 4] EMV Integrated Circuit Card Specifications for Payment Systems, Book 4, Cardholder, Attendant, and Acquirer Interface Requirements [EMV ASRPD] EMV Specification Update Bulletin No. 175. Application Selection Registered Proprietary Data. [EMV L1 Contactless] EMV Level 1 Specifications for Payment Systems, EMV Contactless Interface Specification, Version 3.0 [EMV Tokenisation] EMV Payment Tokenisation Specification; latest version available on EMVCo.com [ISO 639-1] Codes for the representation of names of languages – Part 1: Alpha-2 Code Note: This standard is updated continuously by ISO. Additions and changes are available on: http://www.loc.gov/standards/iso6392/php/code_changes.php

150 [ISO 3166] [ISO 4217] [ISO 7813] [ISO 7816-4] [ISO 7816-5] [ISO 8583:1987] [ISO 8859] [ISO 14443] 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 4: Organization, security and commands for interchange Identification cards – Integrated circuit cards – Part 5: Registration of application providers Bank card originated messages – Interchange message specifications – Content for financial transactions Information processing – 8-bit single-byte coded graphic characters sets Identification cards – Contactless integrated circuit cards – Proximity cards

150 1.5 Terminology This specification uses the following terminology.

1.5.1 Implementation and Support Terminology This specification uses the following terminology to describe the implementation and configuration requirements for kernel functionality: Implementation-Mandatory Kernel shall implement this functionality. Implementation-Conditional Kernel shall implement this functionality if the defined conditions are met. Conditions vary based on the functionality in question. Implementation-Optional Kernel may implement this functionality, at the discretion of the implementer. Acquirer-Merchant-Conditional Acquirer-merchant shall enable this functionality if the defined conditions are met. Conditions vary based on the functionality in question. Acquirer-Merchant-Optional Acquirer-merchant may enable this functionality, at their discretion. The reader functionality defined in this specification is Implementation-Mandatory, except where explicitly stated otherwise. This specification may also explicitly reiterate that specific functionality is Implementation-Mandatory to avoid potential ambiguity. When used to describe requirements and conditions for kernel functionality, the following terminology may be used: Implement(ed) Kernel is capable of performing the functionality. The phrase “implement support for” may also be used. Enable(d) Kernel functionality has been activated (i.e. turned on). Disable(d) Kernel functionality has been deactivated (i.e. turned off). Support(ed) Kernel functionality is both implemented and acquirer-merchant enabled.

150 1.5.2 “Else” with Parenthesized Text Parenthesized text following the word “Else” is provided as supplemental information, and does not denote a condition that must be satisfied. Ex. If Condition, then the kernel shall… Else (Text), the kernel shall… In the example above, the parenthesized “(Text)” is merely supplemental information, and does not constitute a condition that must be satisfied.

1.5.3 Legacy

References

Within requirements, italic numbers in square brackets are legacy references to an earlier version of this specification. Flowcharts are used to provide a high-level illustration of the processing. The flowcharts may be simplified to illustrate a concept, and may not include all the steps that are performed. Implementations are not required to strictly follow the flowcharts, and are instead required to comply with the requirements in the related text. In the case of a discrepancy between the flowchart and the related text, the text shall take precedence.

1.7 Format of Indicators Although the indicators used in this specification are explicitly assigned the values of 0 or 1, the format of these internal indicators within an implementation is at the discretion of the implementer. Performance and security considerations should both be weighed when deciding on the implementation of internal indicators.

1.8 Outcomes Kernel 3 concludes its processing via the Outcomes as defined in Book A. When an Outcome is provided – specified with the words “…provide a xxx Outcome with the following parameters:” – Kernel 3 executes no further processing except to hand over control to Entry Point, passing the Outcome and its parameters.

150 1.9 Overview This volume includes the following chapters and annexes: Chapter 1 contains general information that helps the reader understand and use this specification. Chapter 2 provides an overview of the Kernel 3 approach, including configuration for EMV mode, Kernel 3 processing overview, new transaction processing sequence, Integrated Data Storage processing sequence, and Issuer Update Processing. Chapter 3 defines general functionality and requirements in support of Kernel 3, including messaging requirements, reader configuration requirements, and processing requirements. Chapter 4 defines overall functionality and requirements for Kernel 3, culminating in the decision of whether to perform new transaction processing or Issuer Update Processing. Chapter 5 describes requirements for new transaction processing. Chapter 6 describes requirements for Issuer Update Processing. Chapter 7 describes requirements for Integrated Data Storage. Annex A defines the data elements used in this specification for financial transaction interchange. Annex B details the data elements required for online messages and clearing records. Annex C describes fast Dynamic Data Authentication (fDDA). Annex D lists supported commands. Annex F provides a description of an Integrated Data Storage implementation Annex G is a glossary of terms and abbreviations used in this specification.

EMV® Error! Unknown document property name. Error! Unknown document property name. vError! Unknown document property name.

/ 150 2 Overview of the Kernel 3 Approach The Kernel 3 approach supports a single configuration: EMV mode.

  • The EMV mode configuration supports the EMV minimum set of data elements for clearing messages and for authorisation messages, when used. See section B.1.1. This configuration is for both offline and online transactions with cardholder verification support. EMV mode readers may optionally support:
  • Integrated Data Storage (IDS). This provides a means of reading data from and writing data to cards that also support Integrated Data Storage. The Integrated Data Storage mechanism described in this specification is unique to Kernel 3 and is not interoperable with data storage solutions in other kernels.
  • Issuer Update Processing. This provides a means to deliver Issuer Authentication Data and/or Issuer Scripts to a card.

2.1 EMV Mode Configuration The EMV mode configuration uses EMV commands and constructs with usage adapted for speed and to allow cryptographic operations to be done at the heart of the transaction, rather than when the card might be leaving the field. It features:

  • An offline transaction flow for below floor limit transactions, with offline data authentication and a clearing cryptogram.
  • An online transaction flow with online card authentication and an option for a second re-presentment of the card for issuer updating of card parameters.
  • Cardholder verification support by means of online PIN or signature, when required by the transaction conditions.
  • Support for consumer device form factors (e.g. mobile phones) acting as card products, including support for the Consumer Device CVM. The Consumer Device CVM is a CVM performed on, and validated by, the consumer’s payment device, independent of the kernel. 150 The EMV mode configuration uses the output of Entry Point Pre-Processing and Combination Selection, resulting in the response to the SELECT command and the following data elements and indicators being available at the start of Kernel 3 processing:
  • Amount, Authorised
  • Unpredictable Number
  • Terminal Transaction Qualifiers (TTQ)
  • Copy of TTQ An accelerated offline data authentication method, fast Dynamic Data Authentication (fDDA), is provided through use of the GPO command to initiate the dynamic signature. A DDOL is not used and the results of the authentication are not provided online to the issuer within the TVR or protected by the online authorisation or clearing cryptograms. The EMV mode configuration uses the data elements defined in section A.2 and provides data for online messages and clearing records as defined in section B.1.1. 2.2 2.3 Kernel 3 Processing Overview A new transaction requires the contactless card to be presented once to complete a transaction that is authorised either offline or online. A new transaction can be of the following types:
  • purchase transaction,
  • cash withdrawal, or
  • refund. The new transactions will constitute the majority of transactions and will require no further card interaction. The new transaction processing flow is further outlined in section 2.4 However in some situations a secondary presentment may be beneficial in support of card parameter updates. This function – named issuer update processing – is applicable only for an EMV mode reader and it is optional for both card and reader. The issuer update processing is further outlined in section 2.5. A full overview of the processing flow is outlined in Figure 2-1. EMV® Contactless Specifications for Payment Systems Book C-3 v2.11 Figure 2-1: Sample Transaction Flow / 150 Note: Processing as defined by the shaded shapes is performed by Entry Point. 150 2.3.1 First or Second Presentment The cycling of a transaction for both a first and a second presentment is handled by Entry Point. If the first presentment results in an Online Request Outcome, the card indicates via the Outcome parameters whether a second presentment is supported. During a first presentment, either a new transaction or Integrated Data Storage processing will occur. During a second presentment, Issuer Update Processing will occur. When activated by Entry Point, Kernel 3 checks for the availability of an Integrated Data Storage Directory or Issuer Update Data:
  • If neither Issuer Update Data nor Integrated Data Storage Directory are present, Kernel 3 performs a standard new transaction (section 2.4).
  • If Issuer Update Data is present, Kernel 3 performs Issuer Update Processing (section 2.6). The Issuer Update Processing commands need to be delivered to the same card that was presented for the new transaction. Thus the expectation is that once a card is discovered, Entry Point will directly select the AID used in the previous new transaction in order to deliver the Issuer Update Processing commands to the correct card. If a card with a different AID is presented, then the selection will fail. If a different card is presented using the same AID, then the selection will succeed, but the updates will fail. In practice it is not expected that either situation will occur on a regular basis. Note: If Issuer Update Data is present, Kernel 3 performs Issuer Update Processing regardless of the presence of the Integrated Data Storage Directory.
  • If an Integrated Data Storage Directory is present, and Issuer Update Data is not present, Kernel 3 performs Integrated Data Storage processing (section 2.5). For new transactions, Integrated Data Storage and Issuer Update Processing, the reader in combination with the POS system has a time-out that abandons the transaction if no card is presented. 150 2.4 New Transaction Processing Sequence This section provides an overview of a Kernel 3 transaction, for which Integrated Data Storage processing is not required, showing the order in which functions are performed and the commands sent by the reader to the card. The transaction starts at the handover from Entry Point, which has performed: Pre-Processing, Protocol Activation, Combination Selection, and Kernel Activation.

2.4.1 Initiate Application Processing The status word from the response to the SELECT AID command has been evaluated by Entry Point, thus only a successful SELECT AID response including the Processing Options Data Object List (PDOL) be passed to Kernel 3. Kernel 3 processing for a transaction starts with sending a GET PROCESSING OPTIONS (GPO) command to the card. This includes the data elements requested by the card in the PDOL returned in the response to the SELECT command, which will include the Terminal Transaction Qualifiers. In the GPO response, the kernel is expected to receive data elements from the card that are appropriate to the conditions indicated in the Terminal Transaction Qualifiers:

  • a cryptogram with supporting/additional data, and for offline approved transactions, an Application File Locator (AFL) which points to additional data. Signatures and other data that would cause the response to exceed its size limit are not included, but are instead provided in a record which is indicated in the AFL. Note that the reader is expected to handle situations where the data elements – or some of them – are received during the Read Application Data function. If the conditions for usage of the card application have not been fulfilled, the reader must retry or end the transaction.

2.4.2 Read Application Data If an Application File Locator (AFL) was returned during Initiate Application Processing, the kernel reads card application data from the records indicated in the AFL. This may include the signature if placed in a record due to size limitations as above. After Read Application Data, the kernel is expected to be in possession of all the data elements necessary to complete the transaction – some data is obtained from the GPO response and if necessary (that is, if the AFL is present) some is obtained from records.

150 2.4.3 Card Read Complete During Card Read Complete, the kernel indicates to the cardholder that exchange of data between the reader and the card is complete, and the card may be removed from the field. The kernel makes the following checks on the available data and terminates the transaction if either check fails:

  • That all mandatory data elements were returned by the card.
  • That no primitive data element was returned more than once during Initiate Application Processing and Read Application Data. Subsequent transaction processing includes all the remaining functions in this chapter (section 2.4.4 thru section 2.5).

2.4.4 Processing Restrictions If supported by the kernel for EMV mode configurations, the kernel checks the application expiration date and application usage, and may need to check whether the card is on the Terminal Exception File.

2.4.5 Offline Data Authentication Offline Data Authentication is implemented for readers supporting offline transactions and is performed for card requested offline transactions. The kernel verifies the dynamic signature returned by the card and authenticates the data from the card. The success or failure is indicated by means of the appropriate Outcome during Completion. Special purpose readers may perform offline data authentication for online transactions.

2.4.6 Cardholder Verification Cardholder Verification is implemented for readers implementing EMV mode transactions. During Cardholder Verification, the kernel determines the Cardholder Verification Method to be performed (if any) and makes the necessary request by means of the Outcome and parameters. Kernel 3 is not involved with any CVM processing for ATM devices. This is determined solely by the terminal and acceptance conditions.

150 2.4.7 Online Processing Online Processing is implemented for EMV mode readers supporting online transactions. The kernel indicates the need for online processing by means of the Outcome and parameters. The data provided by the kernel for an online authorisation includes an Application Cryptogram – either an ARQC, or a TC if the card indicates that online processing is preferred if Offline Data Authentication fails.

2.4.8 Completion Completion concludes transaction processing and the kernel will indicate the Outcome of the transaction and the need for any further action to Entry Point. The available Outcomes to Entry Point and the expectations for further actions are as below:

  • Select Next – The kernel has determined that the selected Combination is unsuitable and the next Combination (if any) should be tried.
  • Try Again – The kernel requires that the device be presented again; this may be a result of an error, such as tearing, that could resolve if the transaction is attempted again.
  • Approved – The kernel is satisfied that the transaction is acceptable to the selected contactless card application and wants the transaction to be approved. This is the expected Outcome for a successful offline transaction, but could also occur following re-selection of a kernel after an online response.
  • Declined – The kernel has found that the transaction is not acceptable to the selected contactless card application and wants the transaction to be declined. This Outcome could also occur following re-selection of a kernel after an online response.
  • Online Request – The transaction requires an online authorisation to determine the approved or declined status.
  • Try Another Interface – The kernel is unable to complete the transaction with the selected contactless card application, but knows from the configuration data that another interface (e.g. contact or magnetic-stripe) is available. The kernel could indicate a preference for the alternate interface.
  • End Application – The kernel experienced an application error, such as missing data, that will not resolve if the transaction is attempted again with the same selected contactless card application. 150 2.5 Integrated Data Storage Processing Sequence Integrated Data Storage is an implementation and acquirer-merchant option for EMV Mode configurations. Integrated Data Storage Processing is performed during first presentment if the card application has been selected using Extended Selection and has responded with FCI containing the Integrated Data Storage Directory (IDSD, Tag 'D2'). Integrated Data Storage processing follows the sequence of New Transaction Processing, as described in section 2.4, with the following exceptions:
  • Prior to Initiate Application Processing the kernel may send one or more READ RECORDs to the card and there may be one or more Data Exchanges between the kernel and an IDS Operator Application; the IDS Operator Application implements the proprietary business logic of the IDS Operator.
  • If IDS updates on the card are needed then the EXTENDED GPO (EGPO) command is used in place of the standard Kernel 3 GPO command.

2.5.1 IDS Operator Application The IDS Operator Application implements the proprietary business logic of the IDS Operator. The IDS Operator Application is out of scope of this specification. The functions of the IDS Operator Application include:

  • Analysing the IDS Directory provided by the card in the SELECT response.
  • Determining whether the card contains IDS records for any IDS Operator(s) supported by the terminal. If so, instructing the kernel to read the relevant IDS Records.
  • Interpreting the content of any IDS Records read from the card.
  • Determining whether the card contains IDS records to be updated. If so, instructing the kernel to update IDS Records (using the EGPO command) and providing appropriate command data. For simplicity, this specification assumes:
  • The IDS Operator Application executes in the terminal. In practice the IDS Operator Application could be distributed between the terminal and kernel or located in other system components. For example, the kernel could potentially include proprietary configuration of supported IDS Operators, and ability to read appropriate records without needing to communicate with a separate application. 150
  • Data is communicated between the kernel and the IDS Operator Application using Data Exchange.
  • Instructions are communicated from the IDS Operator Application to the kernel using Data Exchange. The protocol for communicating instructions between an IDS Operator Application and the kernel is kernel implementation proprietary and is out of scope of this specification. Data Exchange with the IDS Operator Application is described in this specification for cases that directly affect kernel processing and kernel to card communications. Implementers may support additional interactions with IDS Operator Applications that are not described in this specification, for example to communicate:
  • Success of the transaction.
  • Error conditions, for example to inform the IDS Operator Application of Offline Data Authentication failures, to enable proprietary processing to manage such exception conditions. Figure 2-2. provides an overview of how Integrated Data Storage processing extends the standard kernel 3 transaction flow. Note that all IDS processing takes place while the card is in the field. Consequently, consideration should be given to the efficiency of the Data Exchange mechanism(s) supported by the kernel implementation in order to minimise the impact on overall performance. 150 Figure 2-2: Sample Integrated Data Storage Transaction Flow Reader Card 150 2.5.2 Analyze IDS Directory The kernel sends the IDS Directory (IDSD) to the IDS Operator Application using Data Exchange. The IDSD is analyzed by the IDS Operator Application to determine whether any IDS Records are to be read. If so, the IDS Operator Application sends (via Data Exchange) instructions to the kernel to issue READ RECORD commands, including parameters for READ RECORD. The analysis of the IDSD and the decision to read any IDS records is IDS Operator proprietary and is outside the scope of this specification.

2.5.3 Read IDS Records If instructed by the IDS Operator Application, the kernel sends READ RECORD commands to the card, and sends the responses to the IDS Operator Application using Data Exchange.

2.5.4 Initiate Application Processing for IDS As a result of analysing the Integrated Data Storage Directory and optionally any IDS Records read from the card, the IDS Operator Application determines whether any IDS Records are to be updated. The analysis of this data and the decision to update any IDS Records is IDS Operator proprietary and is outside the scope of this specification. If IDS Records are to be updated the IDS Operator Application sends the kernel an instruction to use the EXTENDED GET PROCESSING OPTIONS (EGPO) command, together with the IDS Record Update Template (tag 'BF60'). If no IDS Records are to be updated the IDS Operator Application sends to the kernel an instruction to continue with normal Initiate Application Processing, using the GET PROCESSING OPTIONS (GPO) command as described in section 2.4.1 above. The command data for EGPO contains the PDOL, as for GPO, plus additional data that instructs the card to update one or more IDS records. After receiving a successful EGPO response, the kernel continues with normal READ APPLICATION DATA processing, as described in 2.4.2 above.

150 2.6 Issuer Update Processing Issuer Update Processing is an optional feature within Kernel 3 for situations where the issuer utilizing a specific terminal environment wishes to manage the risk parameters within a card by means of issuer authentication and/or script processing over the contactless interface. If an online authorisation response following a new transaction includes Issuer Update Data and both reader and card support Issuer Update Processing, then the cardholder can be instructed to present their card for a second time. During the second presentment the reader can deliver the ARPC and/or forward the Issuer Scripts. This functionality is solely used for updates of card parameters and all new transaction processing will take place during the first presentment.

2.6.1 Issuer Update Processing (Optional for EMV Mode) Issuer Update Processing is an implementation and acquirer-merchant option for EMV mode configurations. If supported by both card and reader, Issuer Update Processing is performed when the authorisation response message contains Issuer Authentication Data and/or an Issuer Script Template. When the card is re-presented, Entry Point re-activates the kernel and the availability of Issuer Update Data indicates to the kernel that it should branch to this section. If Issuer Authentication Data is present in the Issuer Update Data, the kernel sends an EXTERNAL AUTHENTICATE command to the card, which performs issuer authentication and updates risk management parameters (e.g. counter reset) as configured in the card by the issuer. If an Issuer Script Template is present in the Issuer Update Data, the kernel extracts the Script Command(s) and forwards to the card for processing.

150 3 Requirements in Support of Kernel 3 This section defines general functionality and requirements in support of Kernel 3.

3.1 POS System Assumptions Requirements – Receipts 3.1.1.1 (Receipts) [5.4] Receipts are not detailed in this specification, however POS systems shall provide receipts as required by payment system rules (both international and regional). Information about POS systems supporting transactions over multiple interfaces are defined in Book A, Requirements – Multiple Interfaces (8.1.1.11). [5.5]

150 3.2 Messaging Requirements in Support of Kernel 3 3.2.1 EMV Mode Requirements Requirements – EMV Mode Requirements 3.2.1.1 (EMV mode Message Requirements) [5.6] The data for inclusion in EMV mode online messages and clearing records shall be as specified in section B.1. 3.2.1.2 (EMV mode – FFI and CED) [5.7] If the card application returns the Form Factor Indicator and/or Customer Exclusive Data, then the kernel shall make the returned data element(s) available for inclusion in messages to the acquirer. See also section B.1.1. Please check with your payment system representative regarding the required support for these data elements in acquirer messaging. 3.2.1.3 (EMV mode – Token Data) The kernel shall support output of the following data object (when returned by the card application), for possible use by the merchant and transmission to the acquirer:

  • Payment Account Reference (PAR, tag '9F24') Note: The above data object is not normally included in messages to the acquirer, but readers must be capable of outputting the data object when returned by the card application. 3.2.2 150 3.3 Reader Configuration Requirements This section defines some of the configuration requirements necessary for Kernel 3. Configuration of the reader shall conform to these requirements for AIDs supported by this kernel, but the reader or kernel need not enforce configuration requirements.

3.3.1 General Configuration Requirements Requirements – General Configuration Requirements 3.3.1.1 3.3.1.2 3.3.1.3 (Issuer Update Processing and Online Capability) [5.14] If a reader supports Issuer Update Processing, then the reader shall indicate support for Issuer Update Processing by setting TTQ byte 3 bit 8 to 1b and shall indicate online capability by setting TTQ byte 1 bit 4 to 0b. During Pre-Processing, Entry Point will use the reader risk parameters, configured in the EMV mode-enabled reader, to determine whether an EMV mode transaction with an amount of zero will result in an online transaction (if passed to this kernel) or will be conducted over another interface or passed to another kernel. [5.15] 3.3.2 3.3.3 Configuration Requirements for EMV Mode Readers Supporting Integrated Data Storage Following are additional requirements for EMV mode readers that support Integrated Data Storage. Requirements – EMV Mode and Integrated Data Storage 3.3.3.1 (EMV Mode Configuration: Integrated Data Storage) If an EMV mode reader supports Integrated Data Storage, then support for Integrated Data Storage shall be Acquirer-Merchant configurable.

150 3.3.4 Configuration Requirements for Special Purpose EMV Mode Readers Special purpose readers, such as transit system entry gates, may support the functionality in this section. Implementation-Optional: Features for Special Purpose EMV Mode readers are an implementation option. Acquirer-Merchant-Conditional: If implemented in the kernel, support for Special Purpose EMV Mode Reader features is acquirer-merchant-conditional. Refer to your payment system for conditions under which these features are enabled or disabled. Requirements – Configuration for Special Purpose EMV Mode Readers 3.3.4.1 (EMV Mode configuration: fDDA for Online) If an EMV mode reader supports fDDA for Online transactions, then support for fDDA for Online shall be Acquirer-Merchant configurable. 3.3.4.2 3.3.4.3 (EMV Mode configuration: Offline Data Authentication for Online) If an EMV mode reader supports Offline Data Authentication for Online transactions, and Offline Data Authentication for Online Transactions has been enabled by the Acquirer-Merchant, then the kernel shall indicate that Offline Data Authentication for Online is supported by setting TTQ byte 1 bit 1 to 1b.

150 3.4 Processing Requirements in Support of Kernel 3 3.4.1 Requirements for Different Types of Transaction Readers may support different type of transactions. Depending on the transaction type, certain parameters shall be set up accordingly as outlined in this section. Requirements – Transaction Type Requirements 3.4.1.1 (Purchase Transactions) [5.18] Implementation-Conditional: With the exception of ATMs, support for the purchase of goods and services is Implementation-Mandatory. However, cashback functionality described below is Implementation-Conditional on reader support for cashback. For transactions to purchase goods or services, with or without cashback, the EMV mode-enabled kernel shall use:

  • Transaction Type '00'.
  • Amount, Authorised shall be the sum of the purchase amount and the cashback amount (if present).
  • Amount, Other shall be the cashback amount (if present). Note: Acquirers-merchants may require a different Terminal Transaction Qualifiers (TTQ) value and different reader risk parameters for purchase transactions with cashback than is used for purchase transactions without cashback. The reader should allow the acquirer-merchant to configure the TTQ and reader risk parameters for purchase transactions with cashback independently from purchase transactions without cashback. 150 Requirements – Transaction Type Requirements (continued) 3.4.1.2 (Manual Cash Transactions) [5.19] Implementation-Conditional: If the reader supports manual cash transactions, then this functionality shall be implemented. For manual cash transactions, the EMV mode-enabled kernel shall use:
  • Transaction Type '01'.
  • Amount, Authorised shall be the transaction amount. Note: Acquirers-merchants may require a different Terminal Transaction Qualifiers (TTQ) value and different reader risk parameters for manual cash transactions than is used for purchase transactions (with or without cashback). The reader should allow the acquirer-merchant to configure the TTQ and reader risk parameters for manual cash transactions independently from purchase transactions. EMV mode transactions directly result in the purchase of goods or services and/or in the disbursement of cash. Refunds and credits are commonly employed to support the retail or cash disbursement environment, but do not directly result in the purchase of goods or services, nor in the disbursement of cash. Kernel 3 functionality can be used to support refunds and credits, and shall comply with the following requirement for the Transaction Type and Amount, Authorised values used. However, all other reader processing for refunds and credits is outside the scope of this specification. Note: An offline decline (CID indicates an AAC) returned by the card application for a refund or credit simply indicates completion of card action analysis, and should not be treated as a “decline” of the refund. Requirements – Transaction Type Requirements (continued) 3.4.1.3 (Refund Transactions) [5.20] Implementation-Conditional: If the reader supports refunds/credits, then this functionality shall be implemented. For refunds and credits, the EMV mode-enabled kernel shall use:
  • Transaction Type '20'
  • Amount, Authorised shall be the refunded/credited amount. 150 4 Overall Processing Requirements This section defines overall functionality and requirements for Kernel 3.

4.1 General Requirements Requirements – Overall Requirements 4.1.1.1 (Form Factor Indicator) [5.21] If EMV mode is enabled in the kernel, and the card application returns the Form Factor Indicator (FFI), then the kernel shall replace FFI byte 4 bits 4-1 with the value 0000b (indicating that the transaction was conducted using [ISO 14443]) prior to making the FFI available for inclusion in messages to the acquirer. 4.1.1.2 (Unrecoverable [EMV CL] Error) [5.23] If a Transmission, Protocol, or Timeout error as defined in [EMV L1 Contactless] is reported to the kernel, then the kernel shall discard the current transaction data and provide a Try Again Outcome with the following parameters: Try Again:

  • Start: B
  • Online Response Data: N/A
  • CVM: N/A
  • UI Request on Outcome Present: No
  • UI Request on Restart Present: No
  • Data Record Present: No
  • Discretionary Data Present: No
  • Alternate Interface Preference: N/A
  • Receipt: N/A
  • Field Off Request: N/A
  • Removal Timeout: Zero This will cause Entry Point to return to Protocol Activation. 150 Requirements – Overall Requirements (continued) 4.1.1.3 (Cardholder Messaging) [5.24] For contactless transactions, the reader (or terminal) shall clearly communicate to the cardholder and merchant:
  • Present the card
  • The progress of the transaction
  • The outcome of the transaction – approve, decline, or terminate Recommended cardholder messages and indications for various transaction status are defined in Book A. If the card provides the Available Offline Spending Amount, then the EMV mode-enabled reader may display this when it indicates a successful card read and may provide it on the transaction receipt. Note: This specification indicates when communication with the cardholder and merchant occurs, but does not specify the means of communication. User interface requirements are specified on a payment system, regional, or country basis. 4.1.1.4 (Erroneous Data) [5.25] It is the responsibility of the issuer to ensure that data in the card is formatted correctly, and no format checking other than that specifically defined is required on the part of the kernel. However, if in the course of normal processing the kernel recognizes that data is incorrectly formatted, then the kernel shall, unless otherwise specified, terminate the transaction by providing an End Application Outcome as defined in requirement 4.2.1.1. Incorrectly formatted data includes, but is not limited to, the bulleted list provided in [EMV Book 3], section 7.5. 39 4.2 End Application If the kernel wishes to terminate the transaction with an End Application Outcome, the following Outcome and parameters is returned to Entry Point. Requirements – End Application 4.2.1.1 (End Application) The kernel shall provide an End Application Outcome with the following parameters: End Application:
  • Start: N/A
  • Online Response Data: N/A
  • CVM: N/A
  • UI Request on Outcome Present: Yes
  • Message Identifier: '1C' (“Insert, swipe or try another card”)
  • Status: Processing Error
  • UI Request on Restart Present: No
  • Data Record Present: No
  • Discretionary Data Present: No
  • Alternate Interface Preference: N/A
  • Receipt: N/A
  • Field Off Request: N/A
  • Removal Timeout: Zero 40 4.3 Display Available Offline Spending Amount If, during a successful Outcome, the kernel wishes to have the Available Offline Spending Amount (AOSA) displayed or provided on a receipt, the UI Request parameters will be passed as part of the Outcome. Requirements – Display AOSA 4.3.1.1 (Display AOSA) If the card returns Available Offline Spending Amount (AOSA), and the reader supports displaying or providing the AOSA on a receipt, then:
  • The reader shall display or, if a receipt is provided, include the AOSA.
  • The kernel shall include the following UI Request parameters in the Outcome:
  • Value Qualifier: “Balance”
  • Value: AOSA (Tag '9F5D' from card)
  • Currency Code: Transaction Currency Code
  • The kernel shall set the Outcome parameter Discretionary Data Present to Yes and include AOSA in the kernel Discretionary Data. Else the kernel shall not include the UI Request parameters Value Qualifier, Value, and Currency Code in the Outcome 41 4.4 New Transaction, Integrated Data Storage or Issuer Upda

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