EMVCo Type Approval – Book A & Book B – Test Cases

EMV® Terminal Type Approval Books A & B Test Cases Version 2.11c.r September 2025

Legal Notice

This document is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or non-infringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. 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 THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document 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 this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document 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 this document 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 this document.

Version History Version Date Revision

Description

Versioning policy of the present document: This current version 2.11c.r follows the current Entry Point Specification revision number, where.c is incremented (a, b, c, …) for each new revision of the present document issued to correct any issues, or to incorporate Type Approval Bulletins.

Table of Contents

1. 2. 3. 4. 5. 6. 6.1. 6.2. 6.3. 6.4. 7. 7.1. 7.2. 7.3. 8. 8.1. 8.2. 8.3. 9. 9.1. 2EA.004. 2EA.004. 2EA.005. 2EA.006. 2EA.006. 2EA.007. 2EA.007. 2EA.011. 2EA.012. 2EA.013. 2EA.013. 2EA.014. 2EA.014. 2EA.014. 2EA.014. 2EA.014. 2EA.016. 2EA.017. 2EA.017. 2EA.017.

2EA.018. 2EA.019. 2EA.019. 2EA.020. 2EA.021. 9.2. 2EB.001. 2EB.001. 2EB.002. 2EB.003. 2EB.003. 2EB.003. 2EB.004. 2EB.004. 2EB.004. 2EB.005. 2EB.005. 2EB.006. 2EB.006.01 Status Check present and set, Amount different from 1 with Transaction Type ‘Purchase’.99 2EB.007. 2EB.007. 2EB.008. 2EB.008. 2EB.008. 2EB.008. 2EB.008. 2EB.009. 2EB.009. 2EB.009. 2EB.010. 2EB.010. 2EB.011. 2EB.011. 2EB.011. 2EB.012. 2EB.012. 2EB.013. 2EB.013. 2EB.013. 2EB.014. 2EB.014. 2EB.014. 2EB.015. 2EB.015.

2EB.015. 2EB.016. 2EB.016. 2EB.016. 2EB.017. 2EB.017. 2EB.017. 2EB.018. 2EB.018. 2EB.018. 2EB.019. 2EB.019. 2EB.019. 2EB.020. 2EB.020. 2EB.021. 2EB.022. 9.3. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.001. 2EC.002. 2EC.003. 2EC.004. 2EC.004. 2EC.005.

2EC.005. 2EC.006. 2EC.006. 2EC.007. 2EC.007. 9.4. 2ED.001. 2ED.001. 2ED.001. 2ED.001. 2ED.003. 2ED.003. 2ED.003. 2ED.003. 2ED.003. 2ED.004. 2ED.004. 2ED.005. 2ED.005. 2ED.007. 2ED.007. 2ED.007. 2ED.007. 2ED.008. 2ED.008. 2ED.009. 2ED.009. 2ED.009. 2ED.009. 2ED.009. 2ED.009. 2ED.009. 2ED.009. 2ED.009.

2ED.009. 2ED.009. 2ED.009. 2ED.009. 2ED.009. 2ED.009. 2ED.009.31 PPSE select response having a Directory Entry with Kernel AID not Present or = 0 (1).227 2ED.009.32 PPSE select response having a Directory Entry with Kernel AID not Present or = 0 (2).228 2ED.010. 2ED.010. 2ED.011. 2ED.011. 2ED.012. 2ED.012. 2ED.012. 2ED.012. 2ED.012. 2ED.012. 2ED.012. 2ED.012. 2ED.012. 2ED.012. 2ED.013. 2ED.013. 2ED.014. 2ED.014. 2ED.015. 2ED.015. 2ED.015. 2ED.016. 2ED.017.

2ED.017. 2ED.017. 2ED.017. 2ED.018. 2ED.018. 2ED.018. 2ED.018. 2ED.019. 2ED.019. 2ED.019. 2ED.019. 2ED.021. 2ED.021. 2ED.022. 2ED.023. 2ED.023. 2ED.024. 2ED.024. 2ED.024. 2ED.025. 2ED.026. 2ED.026. 2ED.027. 2ED.028. 2ED.029. 2ED.030. 2ED.031. 2ED.032. 2ED.033. 2ED.034. 2ED.035. 9.5. 2EE.001. 2EE.001. 2EE.002. 2EE.002. 2EE.003. 2EE.003.01 Kernel Activation of the Selected Combination after a SPI command (Autorun= ‘Yes’)...305 2EE.004. 2EE.005. 2EE.006.

2EE.007. 2EE.008. 2EE.009. 9.6. 2EF.001. 2EF.001. 2EF.001. 2EF.002. 2EF.003. 2EF.003. 9.7. 2EA.006. 2EA.006. 2EA.006. 2EA.006. 2EA.010. 2EA.010. 2EA.010.02 Contactless interface powered down when contact interface activated (Autorun= ‘Yes’).341 2EA.015. 2EA.022. TERMINAL SETTING 5.X [TERMSETTING5.X] DETAILS ON [TERMSETTING5.

TERMINAL SETTING 19.X [TERMSETTING19.X] DETAILS ON [TERMSETTING19. [LTSETTING1. [LTSETTING2. [LTSETTING3. [LTSETTING4. [LTSETTING5. [LTSETTING6. [LTSETTING7. [LTSETTING8. [LTSETTING9. [LTSETTING10. [LTSETTING11.

1.

Scope

EMV Contactless Specifications for Payment Systems – Book A and Book B, define the terminal requirements necessary to select an EMV Contactless Application in an international interchange environment and provides for backward compatibility with already existing Contactless Applications. The present document, 'EMVCo Type Approval – Books A & Book B - Test Cases’, includes 3 main sections:

• Terminal Test Environment: describes the requirements of the Terminal in order to submit the EMV Contactless Type Approval testing,
• LT (Card) Test Environment: defines the requirements for the test card in order to perform the tests defined in this document
• Test Cases: A set of test cases which when applied to the terminals, are designed to determine whether the terminal meets the requirements stated in [Book A] and [Book B]. Test cases are defined for unitary tests and functional tests. If any special conditions are required for a specific test case, these conditions are described in the test case. The intended audiences for this document are EMVCo recognised laboratories, Entry Point and Contactless application providers, acquiring members or merchants. Although acquiring members and merchants may reference this document, type approval testing oriented toward Entry Point and Contactless application providers. 2. Reference documents [N1] [N2] [N3] [N4] [Book A] [Book B] [Book C-n] [ICS] [Symb] [ModInd] [Perf] [MAPP] EMV Integrated Circuit Card Specification for Payment Systems – Book 1 – Application Independent ICC to Terminal Interface Requirements Version 4.4 – October 2022 EMV Integrated Circuit Card Application Specification for Payment Systems – Book 2 – Security and Key Management Version 4.4 – October 2022 EMV Integrated Circuit Card Terminal Specification for Version 4.4 – Payment Systems – Book 3 – Application Specification October 2022 EMV Integrated Circuit Card Terminal Specification for Payment Systems – Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements Version 4.4 – October 2022 EMV Contactless Specifications for Payment Systems Latest version – Book A – Architecture and General Requirements available EMV Contactless Specifications for Payment Systems Latest version – Book B – Entry Point Specification available EMV Contactless Specifications for Payment Systems – Book C-n – kernel Specification, where n refers to Kernel 2 to 8 Latest version available EMVCo Type Approval Contactless Product Implementation Conformance Statement Latest version available Contactless Symbol Reproduction Guidelines Latest version available EMV Terminal Type Approval - Modular & Independency Test Cases Latest version available EMV Terminal Type Approval - Performance Test Cases Latest version available EMV Terminal Type Approval – Book C-8 – Mobile Test Application Guidelines Latest available 3. Abbreviations and Notations ADF Application Definition File AID Application Identifier CVM Cardholder verification Method EP Entry Point (refers to Book B Specifications) FCI File Control Information GPO GET PROCESSING OPTIONS ICC Integrated Circuit Card ID Identifier LT Lower tester (Card Simulator) MSG Message NA Not Applicable (or specific value assigned) PDOL Processing Options Data Object List PPSE Proximity Payment System Environment POS Point Of Sale RFU Reserved for Future Use SFI Short File Identifier TLV Tag Length Value TTQ Terminal Transaction Qualifier UI User Interface 4. Global Glossary Implementation conformance statement (ICS) - A form completed by the product provider. The written statement lists all optional functions as specified in the reference specification implemented [Book A] & [Book B]. Kernel: A software Module that may refer to
• a (Payment System) Kernel: the kernel complies with one of the [Book C-n] specifications (so EMVCo C-n Kernel only). By default a ‘kernel’ refers to a ‘Payment System Kernel’.
• a Test Kernel: a software module simulating a Kernel C-n that must be present in the product under test for testing reason. The Test Kernel shall be in accordance with the section ‘6.1. Test Kernel definition’.
• a Kernel C-REGX: a proprietary kernel software present in the Contactless Product where x is a Kernel ID which has been registered following EMVCo kernel ID registration process. C-REGX does not refer to the Payment System Kernels. Laboratory - A facility that performs type approval testing. Lower Tester – Card simulator of the test tool that communicates with the product under test. The LT shall be in accordance with section 7 of the present document. POS System - a POS System is the physical architecture of the Product under test. It is the device that communicates with contactless cards, processes contactless transactions, and may support other payment functionalities such as magnetic stripe or contact chip transactions. The physical architecture can be any of the following:
• Fully integrated terminal: all elements included in a single device.
• Intelligent card reader: The reader handles most of the contactless transaction processing, passing the results for completion by the terminal.
• Combination of terminal and transparent card reader: The reader provides communication with the card, whilst kernels and other processes are in the terminal. Test Kernel – see ‘Kernel’ definition above. Test Payment Application – Software simulating a Payment Application that must be present in the product under test for testing reason. The test payment application shall be in accordance with the section 7 of the present document. 5. Document Overview The document is organized in four chapters, completed by annexes:
• Section 6 specifies the Terminal Test Environment; it includes the Test Kernel specification and a high level of the Terminal Data Configuration, which is detailed in Annex A.
• Section 7 specifies the LT (Card) Test Environment; it includes the LT Test kernel and a high level of the LT Data Configuration, which is detailed in Annexes B and C.
• Section 8 specifies the Test Structure and the Test Categories.
• Section 9 contains all the Test Cases definition. This section is divided into 6 subsections to cover all requirements of [Book A] & [Book B]. 1. General Requirements 2. Pre-Processing 3. Protocol Activation 4. AID and Kernel Selection 5. Kernel Activation 6. Outcome Processing 6. Terminal Test Environment 6.1. Test Kernel definition This section describes the functional requirements of the Terminal Test Kernel ‘TK’ to be loaded in a device in order to perform [Book A] & [Book B] Type Approval Level 2.

6.1.1 General requirements This Terminal Test kernel must be provided by the device vendors and must be capable of meeting the minimum functionality described below: ¨ Simulating 7 (or more) vendor developed test kernels, each being fully independent from the others, having their own unique checksum and Kernel ID ¨ The test kernel shall be able to record and present all flags and data elements listed in the [Book A] and [Book B] specifications. ¨ The test kernel shall be able to verify the PDOL and build a GPO command accordingly using Kernel or Entry Point data to report those data to the LT. ¨ The test kernel shall be able to generate User Interface Request ¨ The test kernel shall be able to generate Outcome and be restarted after online processing ¨ The test kernel shall be able to provide the outcome to Entry Point including: l The Outcome parameter l The Associated Data form the Kernel: ² The User Interface Request Data (if any in LTsetting) ² The Data Record (if any in LT setting), ² The Discretionary Data (if any in LTsetting) ¨ The test kernels are wholly independent from the payment system kernels ¨ Each kernel may be independently loaded into the terminal or all applications can be loaded into the terminal at one time. The below figure shows the Test kernel in the POS System environment:

LT Test Kernel:

• Send GPO to LT according to PDOL
• Receive data for Outcome and UI GPO Response Data Prepare Outcome and UI request

6.1.2 EP data recording The test kernel must be capable of reflecting the result of the pre-processing and kernel activation process by the Entry Point application. This means that the activated test kernel shall record and output when requested, the following data:

• Entry Point Pre-Processing Indicators,
• Amount Authorised,
• Unpredictable Number
• Restart flag For the purpose of verifying data listed above, the test kernel shall support a proprietary Tag ‘D1’, called ‘Test flags’ in the test environment and capable of mapping above listed data onto Tag ‘D1’ according to the bit setting in Table 1. The Test Flags data element has the following format: b8 B7 b6 b5 b4 b3 b2 b1 Meaning 0 Reader Contactless Floor Limit Not Exceeded 1 Reader Contactless Floor Limit Exceeded RFU 0 Reader CVM Required Limit Not Exceeded 1 Reader CVM Required Limit Exceeded 0 Status Check Not Requested 1 Status Check Requested 0 Not Zero Amount 1 Zero Amount 0 Contactless Application Allowed 1 Contactless Application Not Allowed RFU Table 1: Tag ’D1’, Test Flags data format – Byte 1 b8 B7 b6 b5 b4 B3 b2 b1 Meaning 0 Restart Flag is 0 1 Restart Flag is 1 RFU Table 2: Tag ‘D1’, Test Flags data format – Byte 2 Where:
• Terminal Contactless Floor Limit exceeded or not: the bit 8 reflects the setting of the Entry Point Pre-Processing Indicator ‘Reader Contactless Floor Limit Exceeded’ of the Entry Point Software as described in [Book B].
• Terminal CVM Required Limit exceeded or not: the bit 6 reflects the setting of the Entry Point Pre-Processing Indicator ‘Reader CVM Required Limit Exceeded’ of the Entry Point Software as described in [Book B].
• Status Check requested or not: the bit 5 reflects the setting of the Entry Point PreProcessing Indicator ‘Status Check Requested’ of the Entry Point Software as described in [Book B].
• Zero Amount or not Zero Amount: the bit 4 reflects the setting of the Entry Point Pre-Processing Indicator ‘Zero Amount’ of the Entry Point Software as described in [Book B].
• Contactless Application not Allowed the bit 3 reflects the setting of the Entry Point Pre-Processing Indicator ‘Contactless Application Not Allowed’ of the Entry Point Software as described in [Book B].
• Restart Flag reflects the setting of the ‘restart flag’ 6.1.3 Test data reporting Upon kernel activation when the control is handed over from Entry Point to the selected test kernel, the test kernel must be able to provide all Test data out through a Get Processing Option Command. Following data must be retrievable from the selected Test kernel:
• Test Flags data, with Terminal Transaction Qualifier when provided by EP,
• Amount Authorised,
• Unpredictable Number,
• Kernel ID of the selected Test kernel by EP,
• FCI of the AID selected (this is against EMV and is for testing purposes only) The Get Processing Option Command of the test kernels shall be coded as follows Code Value CLA ‘80’ INS ‘A8’ P1 ‘00’ P2 ‘00’ Lc Var. Data PDOL Related Data Le ‘00’ Table 3: Get Processing Command Format for the Test kernels Data field in the command message: The data field of the command message is a data object coded according to the PDOL provided by the LT (Card), as defined in EMV section 5.4, and is introduced by the tag '83'. The minimum data to be supported in PDOL are defined in Annex B; it includes the following: - Tag ‘D1’: 2 bytes of Test Flags data according to Table 1, - Tag ‘9F66’: 4 bytes - TTQ (this tag is not returned when data not present, to be filled with zeroes), - Tag ‘9F02’: 6 bytes – Amount Authorised, - Tag ‘9F37’: 4 bytes – Unpredictable Number, - Tag ’96’ with variable length in Binary format - Kernel Identifier–Terminal, indicates the Kernel ID of the selected test kernel - Tag ‘6F’ FCI Template with variable length of the Selected AID. - Tag ‘91’: Authorisation Response, with variable length, in case that previous transaction has required a restart. - Tag ‘71’: issuer Script, with variable length, in case that previous transaction has required a restart. - Tag ‘72’: issuer Script, with variable length, in case that previous transaction has required a restart. The length in the PDOL returned in the FCI for the Kernel ID data and FCI template must be set in the LT in such a way that it corresponds to the length supported by the terminal to be tested.

6.1.4 Terminal Test kernel process This section specifies the Terminal Test kernel process. 1. The Terminal Test kernel is activated according to [Book B], section kernel activation. 2. The Terminal Test kernel shall get the FCI Select Response, the Status Word, and also all Entry Point data at activation, and shall record these data. 3. The Terminal Test kernel shall generate a GPO command using the PDOL retrieved in FCI (if present) and send the command to the LT according to the PDOL setting. The data objects supported in PDOL are defined in Annex B. 4. The Terminal Test kernel waits for the LT (card) response which can answer one of the following responses:

• Case 1: the card response specifies an Outcome without any User Interface Request
• Case 2: the card response specifies an Outcome with a User Interface Request (on Outcome)
• Case 3: the card response specifies an Outcome with a User Interface Request (on Restart)
• Case 4: the card response specifies an Outcome with a User Interface Request on Outcome and a User Interface Request on Restart
• Case 5: no card response, or no outcome or wrong response format 4.1. When a User Interface Request on Outcome is present, the following parameters specific to User Interface Request on Outcome shall be present:
• Message Identifier
• Status
• Hold Time (integer multiple of 100ms)
• Language Preference o (as per EMV tag '5F2D' according to ISO 639)
• Value Qualifier
• Value
• Currency Code (numeric value as per ISO 4217). The Terminal Test kernel shall process this User Interface Request and continue. © 2011-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicabl