EMV® Terminal Type Approval – Book C-8 – Testing Environment Requirements

EMV® Terminal Type Approval Book C-8 Testing Environment Requirements Version 1.2 July 2025 © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.2 Page i 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. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.2 Revision Log – 1.2 Page ii The following changes have been done since release of version 1.1: • Clarification on System Test Cases. • Clarification on requirements ASR-04. • Various corrections and improvements. • Addition of Application Selection module requirements for tests performed with Automation (ASR-06 to ASR-08). • Clarification of Application Selection module requirements. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.2 Page iii Contents 1 Using this Manual ................................................................................................. 1 1.1 Purpose .................................................................................................. 1 1.2 Audience ................................................................................................ 1 1.3 Reference Documents ............................................................................ 1 1.4 Abbreviations .......................................................................................... 2 1.5 Terminology ............................................................................................ 2 1.6 Implementation Options .......................................................................... 3 1.7 Testing Options ...................................................................................... 3 2 Architecture details............................................................................................... 5 2.1 Preamble ................................................................................................ 5 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 2.1.9 Application Selection .............................................................................. 5 C-8 kernel ............................................................................................... 5 Card simulator ........................................................................................ 5 Configuration data set............................................................................. 5 Product Test Environment ...................................................................... 6 Product Test Application ......................................................................... 6 Test Tool Environment............................................................................ 7 Test Tool Environment Interface ............................................................. 7 Transaction related data ......................................................................... 7 3 Requirements for the Product Test Environment............................................... 8 3.1 Requirements for Application Selection module...................................... 9 3.2 Requirements for Communication Interfaces. ....................................... 10 3.3 Requirements for the Product Test Application..................................... 11 3.4 Requirements for the configuration data set ......................................... 15 3.4.1 3.4.2 3.4.3 Readerconfs ......................................................................................... 15 CAkeys ................................................................................................. 17 Configuration Data Sets Requirements................................................. 17 4 TCP/IP communication interfaces ..................................................................... 18 4.1 TEI automation interface....................................................................... 18 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.1.8 4.1.9 4.1.10 4.1.11 4.1.12 4.1.13 ACT ...................................................................................................... 20 ACT_ACK ............................................................................................. 21 CONFIG (optional)................................................................................ 22 CONFIG_ACK (optional) ...................................................................... 22 DEK ...................................................................................................... 23 DET ...................................................................................................... 23 MSG ..................................................................................................... 24 OUT ...................................................................................................... 25 RUNTEST (optional) ............................................................................. 26 RUNTEST_RESULT (optional) ............................................................. 26 TEST_INFO (Conditional)..................................................................... 27 TEST_INFO_ACK (Conditional) ........................................................... 28 State machines ..................................................................................... 29 4.2 PCD-bypass interface ........................................................................... 31 4.2.1 4.2.2 4.2.3 APDU_ACTIVATE ................................................................................ 32 APDU_CMD ......................................................................................... 32 APDU_RESP ........................................................................................ 33 © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.2 Page iv 4.2.4 Exchange scenarios ............................................................................. 34 © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.2 Page v Figures Figure 2.1: Overall Testing Environment Architecture ........................................................... 5 Figure 2.2: Product Test Environment................................................................................... 6 Figure 2.3: Test Tool Environment ........................................................................................ 7 Figure 3.1: Configuration Data Sets Format ........................................................................ 15 Figure 3.2: Configuration Data Sets Architecture ................................................................ 15 Figure 4.1: Automation product state machine (TEST_INFO not supported) ...................... 29 Figure 4.2: Automation product state machine (TEST_INFO supported) ............................ 30 © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.2 Page vi Tables Table 1.1: Reference Documents ......................................................................................... 1 Table 1.2: Abbreviations ....................................................................................................... 2 Table 3.1: Application Selection module Requirements ......................................................... 9 Table 3.2: Communication Interface Requirements ............................................................. 10 Table 3.3: Product Test Application Requirements ............................................................. 11 Table 3.4: Configuration Data Sets Requirements .............................................................. 17 Table 4.1: TEI Product Automation Interface ...................................................................... 19 Table 4.2: Card Product Automation Interface .................................................................... 31 © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 1 / 35 1 Using this Manual 1.1 Purpose EMVCo requires that products implementing [C-8] and submitted for Terminal Contactless Products Type Approval are to be tested against the relevant specification. To test the compliance of the product implementation to [C-8], the contactless product must be tested in a determined Testing Environment that is composed of two parts: • The Product Test Environment that includes the product to be tested. • The Test Tool Environment: includes either a card simulator (and the Test tool Environment Interface) or physical devices loaded with an application developed by EMVCo. The purpose of this document is to describe the requirements of the C-8 Kernel Testing Environment. 1.2 Audience This document is intended for use by Product Providers, that is, by manufacturers and suppliers of C-8 products. 1.3 Reference Documents Table 1.1: Reference Documents Reference [C-8] [Book A] [Book B] [Book E] Document EMV Terminal Type Approval Contactless Product – Administrative Process EMV Contactless Specifications for Payment Systems – Book C-8 - Kernel 8 Specification EMV Contactless Specifications for Payment Systems – Book A – Architecture and General Requirements EMV Contactless Specifications for Payment Systems – Book B – Entry Point Specification EMV Contactless Specifications for Payment Systems – Book E – Security and Key Management Any applicable Specification Bulletins as published on the EMVCo website Version Issue Date latest applicable version Version 1.1, June 2023, or later version Latest available Latest available Latest available © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Reference Document [ReaderCo ReaderConfs.xmd nf] Page 2 / 35 Version Issue Date latest applicable version 1.4 Abbreviations Table 1.2: Abbreviations DE/DS EMV® Abbreviation PCD RRP RRPrAccuracyThreshold RRPrExpectedCAPDU RRPrExpectedRAPDU RRPrMaxGrace RRPrMeasuredTime RRPrMinGrace RRPrMismatchThreshold TAL1 TAL2 TEI Description Data Exchange and Data Storage A trademark owned by EMVCo, referring to the technical specifications published by EMVCo. Proximity Coupling Device Relay resistance protocol RRP Accuracy Threshold Terminal Expected Transmission Time for RRP C-APDU Terminal Expected Transmission Time for RRP R-APDU Maximum RRP Grace Period Measured RRP Time Minimum RRP Grace Period RRP Transmission Time Mismatch Threshold Type Approval Level 1 Type Approval Level 2 Test Tool Environment Interface 1.5 Terminology Automation: Automation allows the Test Tool to automatically launch tests and verify the transaction output. The term ‘automation’ refers to the TEI automation interface, where ‘TEI’ stands for ‘Test tool Environment Interface’. Implementing the TEI automation interface is mandatory. Refer to section 4.1. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 3 / 35 Automation is used in functional tests (except System tests). Automation is not used during the execution of the following tests: o Performance o Independency o Relay Resistance Protocol Accuracy o System tests C-8 Kernel: The kernel as defined in [C-8]. Type Approval process considers that the Crypto module defined in [C-8] is part of the Kernel module. C-8 Product: A product or combination of products incorporating C-8 Kernel. PCD-bypass Interface: This interface permits the exchange of APDUs between the product and the Test Tool without using the PCD. The APDUs are exchanged using TCP/IP connection. This interface is optional (Refer to section 4.2). System tests This documents sometimes refers to system tests. For these tests none of the TEI (Test tool Environment Interface) and PCD-bypass interfaces are used. 1.6 Implementation Options When needed, this document includes implementation options mentioned in superscript like in the example below: Tags To ReadDEDS DF8112 Var. Today, only one mnemonic exists: • DEDS: the item only applies when DE/DS is supported 1.7 Testing Options The following testing options are available: • Transaction data processing through the ACT signal: When product does not support the processing of the transaction data through the ACT signal: o Transaction related data must be either provided by the Product Provider (recommended) or entered manually by the test operator. o The product shall answer with ACT_ACK ‘NOTSUPPORTED’. Please refer to sections 4.1.1 and 4.1.2. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 4 / 35 • TEST_INFO signal: TEST_INFO signal is mandatory to implement when the product supports the processing of the transaction data through the ACT signal. Please refer to sections 4.1.11 and 4.1.12. • CONFIG signal: CONFIG signal is recommended when the processing of the transaction data through the ACT signal is supported. Please refer to sections 4.1.3 and 4.1.4. • RUNTEST signal: Please refer to sections 4.1.9 and 4.1.10. • PCD-bypass interface: EMVCo recommends implementing it so the APDU exchanges are made with timing close to the field one. Please refer to section 4.2. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 5 / 35 2 Architecture details The overall Testing Environment architecture can be represented as described in Figure 2.1. It is split into the Product Test Environment and the Test Tool Environment. Figure 2.1: Overall Testing Environment Architecture This section first introduces the main components of the Testing Environment. It then details the Testing Environment architecture. 2.1 Preamble This section gives some details about the components included in the Product Test Environment and the Test Tool Environment. 2.1.1 Application Selection This is a module that implement the Application selection mechanism. 2.1.2 C-8 kernel This is a module that implements [C-8]. 2.1.3 Card simulator The card simulator simulates different card profiles to check whether the submitted product supports all the mandatory features defined in [C-8]. 2.1.4 Configuration data set EMVCo provides a definition of the test configurations in an XML format file [ReaderConf]. Those test configurations include for instance the AIDs, Terminal Action Codes…The Product Provider must build the configuration data set that include all the test configurations listed in [ReaderConf]. See section 3.4 of this document for further details about the [ReaderConf] file structure. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 6 / 35 2.1.5 Product Test Environment The Product Test Environment may be represented as described in Figure 2.2: Product Test EnvironmentFigure 2.2. Figure 2.2: Product Test Environment The Product Test Environment includes: • The Operating System • The C-8 Kernel • The Application Selection module • The test configuration data set • The Product Test Application • The Communication Interfaces There is no requirement to match the architecture described above. For instance: • The test configuration data set might reside in the Product Test Application • The C-8 Kernel might partially reside in a remote kernel • The Product Test Application may partially reside in a PC software. 2.1.6 Product Test Application The Product Test Application drives the transactions during the test sessions. For the purpose of this document, it is considered that the Product Test Application: • Includes the Process M defined in [C-8]. • Permits to receive the transaction data from the Test Tool during the tests run in automation mode using TEI interface • Permits to transmit the transaction outcomes to the Test Tool during the tests run in automation mode using TEI interface. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 7 / 35 • Permits to manually input the transaction data during the system tests execution or when the product does not support processing of the transaction related data through the ACT signal. • Permits to visually verify the transaction outcomes and outcome parameter set during the system tests execution. 2.1.7 Test Tool Environment Figure 2.3: Test Tool Environment The Test Tool Environment is made of the Test Tool Environment Interface, the card simulator and the executable tests. Notes: • The Test Tool includes ‘Undisclosed’ executable tests that are available to the Testing Laboratories but not to the Product Providers. • For some tests (i.e Performance, Independency and Relay Resistance Protocol Accuracy tests), the Test Tool Environment consists of cardholder devices loaded with test applications developed by EMVCo. Test Applications and cardholder devices cannot be disclosed to Product Providers. 2.1.8 Test Tool Environment Interface This interface permits to drive the Test Tool. When the tests are run with the automation feature, the Test Tool Environment Interface (also known as ‘TEI’) permits to automate most actions. 2.1.9 Transaction related data Transaction related data include for instance the amount and the currency. When the processing of the transaction data through the ACT signal is supported, transaction related data is provided by the Test Tool to the product, through the ACT signal. When the product does not support processing of the transaction related data through the ACT signal, the Test Tool will make available a list of the expected transaction related data for each test, based on the data provided by EMVCo. The product vendor may use this list to prepare a batch of transaction related data to be used during the test session. Otherwise, the test operator will need to enter the transaction related data manually for each test. When running the system tests, the TEI must not be used so the transaction data must be provided manually. Most system tests use the default transaction data provided in the Test Cases document. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 8 / 35 3 Requirements for the Product Test Environment This chapter details the requirements the Product Test Environment must meet when a product is submitted for Terminal Contactless Product Type Approval. These requirements are classified into 3 categories: • Manual: Requirements apply when tests are not run in automation mode. • Auto: Requirements apply when tests are run in automation mode. • Common: Requirements apply to all tests. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 9 / 35 3.1 Requirements for Application Selection module Table 3.1: Application Selection module Requirements ASR-01 ASR-02 Application Selection method Kernel Activation Common Common ASR-03 Pre- Common Processing ASR-04 Start B Common ASR-05 Start C Common ASR-06 ASR-07 PreProcessing PreProcessing Auto Auto ASR-08 Pre- Auto Processing The first APDU must be the SELECT (PPSE), followed by the SELECT (AID) as specified in sections 3.3.2 and 3.3.3 of [Book B]. Application Selection module shall activate the Kernel identified in the selected Combination. Application Selection module shall make available the FCI and the Status Words SW1 SW2 (both received from the Test Tool in the SELECT (AID) response) to Kernel. If the product implements the Pre-Processing defined in [Book B] Section 3.1, the Configuration Data shall be such that none of the pre-processing indicators (if any) are set. If the Outcome Parameter Set received from the Kernel indicates ‘Start B’, then Application Selection module shall return to Start B (Protocol Activation, section 3.2.1 of [Book B]). The product must not expect the Test Tool to send a second ACT signal before starting the protocol activation - Start B. If the Outcome Parameter Set received from the Kernel indicates ‘Start C’, then Application Selection module shall remove the selected Combination from the Candidate List and shall return to Start C (Step 3 of Combination Selection (requirement 3.3.2.6) of [Book B]). Application Selection module must not block empty/missing amount. Application Selection module must not block a SELECT (AID) response with status words ‘9000’ whenever the ‘6F’ template is absent or wrongly formatted. Application Selection module must not block any AID mismatch in SELECT (AID) response. Note: • • If the Product does not follow the EMVCo standalone process then the tests performed without automation feature must be run with the final Entry Point module compliant with [Book B] requirements (i.e requirements ASR-06 to ASR-08 may not be supported). If the Product follows the EMVCo standalone process, then all tests may be performed using the Application Selection module defined for tests performed with automation. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 10 / 35 3.2 Requirements for Communication Interfaces. This section aims at defining the requirements for the product so it can interface properly with the Test Tool. Table 3.2: Communication Interface Requirements CIR-01 CIR-02 TEI communication interface TEI connection protocol CIR-03 CIR-04 PCD-bypass communication interface PCD-bypass connection protocol CIR-05 NFC Probe Auto Auto Auto Auto Common The product must meet the requirements defined in Section 4.1. The connection between the Test Tool Environment Interface and the product is done using TCP/IP. This protocol is following a client/server mode. If the product supports PCD-bypass, it must meet the requirements defined in Section 4.1. If the product supports PCD-bypass, the connection between the Test Tool card simulator and the product is done using TCP/IP. This protocol is following a client/server mode. The product must support APDU exchanges using Contactless Interface (Test Tool NFC Probe or Cardholder devices). © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 11 / 35 3.3 Requirements for the Product Test Application Table 3.3: Product Test Application Requirements PTA-01 Loading configuration Manual1 PTA-02 Configuration data Common set PTA-03 Symbolic values Manual PTA-04 Cut & paste PTA-05 MSG signal Manual Manual The Product Test Application shall permit to load the configuration without using the TEI Interface. The Product Provider shall build the configuration data set that include all the configurations defined in the [ReaderConf] file provided by EMVCo. The Product Test Application shall permit to observe the symbolic values (e.g., “CAM FAILED”) in addition of the hexadecimal values (e.g.: ‘02') for the below transaction data outputs: • Outcome Parameter Set • Error Indication • User Interface Request Data The displayed symbolic values shall be the ones given in [C-8] section 'Data Dictionary'. This will allow the test operator to easily verify test pass criteria like: ’In Outcome Parameter Set’, ‘Status’ shall indicate “Online Request”. Means shall be provided so that the Transaction data output can be cut & paste into a document (e.g., using CTRL C on screen capture). The Product Test Application must permit to observe the MSG signal output as returned by the kernel. During the kernel tests, the product must not provide/display the MSG signals returned by the other modules (Select, EntryPoint, Main…). 1 This requirement applies to automation mode when the product does not support the CONFIG signal defined in section ‘TEI automation interface’. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 12 / 35 PTA-06 OUT signal Manual PTA-07 Transaction related data objects Manual2 The Product Test Application must permit to observe the OUT signal as defined in [C-8] (e.g.: section “Lists of Data Objects in OUT”): • Outcome Parameter Set • Data Record – if any • Discretionary Data (includes Error Indication, …) • Error Indication. • User Interface Request Data 1 – if any • User Interface Request Data 2 – if any Note1: the User Interface Request Data may be part of the OUT signal or/and the MSG signal. Note2: in some cases, the DataRecord, UIRD1, UIRD2 may be absent. If so, those items may either be absent from the OUT signal or be present with the value ‘null’. The Product Test Application shall permit the sending of the transaction related data objects as defined in [C-8], that is: • Account Type • Amount, Authorized (Numeric) • Amount, Other (Numeric) • Transaction Currency Code • Transaction Currency Exponent • Transaction Date • Transaction Time • Transaction Type • Data Exchange data objects Additionally, the Product Test Application shall permit the sending of Proprietary data objects as part of the transaction related data objects. 2 This requirement also applies to automation mode when the product does not support processing the transaction related data through the ACT signal. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 13 / 35 PTA-08 Updating the transaction related data objects Manual2 PTA-09 Autorun PTA-10 OUT vs Select Next Common Common PTA-11 OUT vs Start B Common PTA-12 OUT vs Process S Common PTA-13 Date & Time Common The Product Test Application shall permit to easily edit the list and value of the transaction related data objects. It shall permit to add and remove transaction related data objects from the list defined in requirements PTA-07 It shall also permit to configure transaction related data objects without any value (i.e.: zero length). If supported, the Autorun parameter value must be “No”. The Product Test Application must also provide the Outcome Parameter Set and the Error Indication as provided by the kernel to the Application Selection module when the kernel detects an issue leading to a ‘Select Next’ outcome. Please see the example below: • AID#1 is selected • the kernel detects an issue leading to a ‘Select Next’ outcome ➔ the product must return the Outcome Parameter Set and the Error Indication data • Select Next: AID#2 is selected • the kernel completes the transaction successfully In some circumstances the product may require a second tap to complete the transaction. In such case the field/deployed product will return a Start B (indicating that the terminal will not ask the amount again) and should NOT provide the OUT signal until the second tap is performed (or the Cancel key is pressed). During the test session, the Product Test Application must provide the OUT signal when the transaction results in a Start B even if the second tap is not performed. If the Product follows the architecture defined in [C-8] then the Process S may send OUT signals to the Process M. During the Test those OUT signals must not be provided by the Product Test Application. The Product Test Application must not provide any Process S intermediate OUT signal. If the product under test manages its own clock, then any date and time passed to it must overwrite the internal date and time. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 14 / 35 PTA-14 Default configuration Common PTA-15 Transaction log Common PTA-16 Outcome Parameter Set Manual PTA-17 Processing of the transaction data through ACT signal not supported Auto It is expected that a default configuration is loaded when the product is powered on. During test session, the default configuration is ‘C8_prof00’. The product must generate a transaction log including: • C-APDUs • R-APDUs • DEKs • DETs • OUT • MSG The transaction log must list the APDU/DEK/DET/OUT/MSG signals in the order they have been treated by the product. Especially the log must show when a DEK was sent. [C-8] lists the relevant information from the Outcome Parameter Set to be passed to the terminal in the transaction output data. For testing needs, the Product Test Application must provide all Outcome Parameter Set information and their values, that is: • Status • Start • Online Response Data • CVM • UI Request on Outcome Present • UI Request on Restart Present • Data Record Present • Discretionary Data Present • Receipt • Alternate Interface Preference • Field Off Request Removal Timeout If the product does not support the processing of the transaction data through the ACT signal, the tag ‘9F21’ (transaction time) shall have the value ‘112233’ by default. That is, this default value ‘112233’ shall be used by both the test tool and the product. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 15 / 35 3.4 Requirements for the configuration data set The kernel database shall be configurable with any of the permitted data items specified in [C-8]. The Product Test Environment shall be able to store these data objects so they can be easily re-used from one transaction to another. This section defines the testing configuration requirements the submitted C-8 product shall meet when testing the Contactless Application. The configuration data sets are defined in the xml format file [ReaderConf]. An example is provided in Figure 3.1: Figure 3.1: Configuration Data Sets Format The [ReaderConf] file is divided in two main parts: • ReaderConfs: lists all the configurations. • CAKeys: lists the Certification Authority public keys that shall be implemented. Figure 3.2: Configuration Data Sets Architecture 3.4.1 Readerconfs This section lists several configurations that are defined in the elements . Each configuration is defined by 3 attributes: © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 16 / 35 • ‘confID’: defines the configuration name. • ‘basedOn’ (optional): defines the father configuration to inherit from. If so, all data are inherited from the ‘basedOn’ configuration. The actual configuration shall overwrite the data defined in the father one. • ‘Options’ (optional): If the attribute is present and lists options that are not supported by the product under test, then the related configuration may not be implemented. The element has 1 child: that has one attribute ‘KernelID’. For C-8 testing the ‘KernelID’ value is “08”. has two children: • : This element lists the C-8 specification tags that shall be implemented. • : This element lists all the Proprietary tags that shall be implemented. This element is not present when no proprietary tag is present in the configuration. These two elements include one or several elements. Each tag to be implemented is defined with the element that has the following attributes: • ‘trxType’: defines the transaction type this test detail applies to. When empty “” it applies to all transaction types (The list of transaction types to be supported is provided is requirement CNF-01 and in the [ReaderConf] file). • ‘aid’: defines the aid this test detail applies to. When empty “” it applies to all AIDs (the list of AIDs to be implemented is provided in the [ReaderConf] file) . • ‘tagID’: defines the Tag (hexadecimal). Cannot be empty. • ‘tagMnemo’: defines the Tag mnemonic (string). Cannot be empty. • ‘tagValue’: defines the value of the Tag to be configured. It can be: o a hexadecimal value (e.g: “HEX(1234)”) o an empty value: “HEX()” o “NULL”: the item must not be present The element includes the following additional attributes when it is a child of : • ‘updateConditions’: defines the update condition of the Proprietary tag. It can be; o "K” o “K/RA” o “K/ACT” o “K/DET” o “K/ACT/DET” o “K/ACT/DET/RA”. o "K/ACT/RA" o “K/DET/RA” • ‘minLength’: defines proprietary tag minimum length. Value is a non negative integer. • ‘maxLength’: defines proprietary tag Maximum length. Value is a non negative integer. • ‘format’: defines the proprietary tag format. It can be: o “b” : Binary. o “n x”: Numeric, x represents the number of digits. o “cn x”: Compressed numeric. o “an”: Alphanumeric, x represents the number of digits. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 17 / 35 3.4.2 CAkeys This element defines the Certification Authority public keys to be loaded into the reader. The keys are grouped by RID. Each key is identified by a Key Index, and has the following attributes: • ‘keyAlgorithmIndicator’: defines the Key Algorithm Indicator. • ‘modulus’: defines the modulus of the CA Key. • ‘exponent’: defines the exponent of the CA Key. Empty for ECC keys. • ‘RevokedCSNs’ (optional): lists the serial number of the revoked certificates (CSN). 3.4.3 Configuration Data Sets Requirements Table 3.4: Configuration Data Sets Requirements CNF-01 Transaction Type Common CNF-02 Zero length Common CNF-03 Additional objects Common The following Transaction Types shall be supported for all AIDs: • Payment (‘00’) • Cash (‘01’) • Purchase with Cashback (‘09’) • Cash disbursement (‘17’) • Refund (‘20’) • Contactless ATM transaction (‘93’). The Product Test Environment shall permit to configure data objects without any value (i.e.: zero length). This will be noted like this in the [ReaderConf] file: ‘tagValue=”HEX()”’ The Product Test Environment shall also permit to configure additional configuration data objects not listed in the specifications Note: For better readability, the Transaction Type (Tag ‘9C’) is not defined in the element ‘ConfData’. However, it is assumed to be present and valued with the transaction type value used during the transaction. The Transaction Types that shall be supported are listed in CNF-01. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 18 / 35 4 TCP/IP communication interfaces This section details the TCP/IP communication interfaces and the related signals. There are two distinct TCP/IP communication interfaces: • The interface between the product and the Test Tool Environment, further named ‘TEI interface’. The TEI interface is mandatory. All TEI interface signals are mandatory except from CONFIG, RUNTEST and TEST_INFO. • The ‘PCD-bypass interface’. The PCD-bypass interface is optional. When implemented, all related signals are mandatory. When the PCD-bypass interface is not implemented, the tests are run using the Test Tool NFC probe. Notes: • Some json definitions below include comments formatted like in java: ‘// comment’, even though this is not a correct format in json. • The product shall not provide additional data elements in the signals. • The product may support additional signals. Such signals must occur either before ACT signal or after OUT signal. • End of the test: after the last expected signal is sent by the product (e.g.: OUT signal) the Test Tool will wait a short time before closing the test. This will ensure the product does not send additional wrong signals. • Some signal definitions below include an ACK signal. Those ACK signals may optionally return “No” in case the product does not understand the input signal. • In some signals below, items may be absent (e.g.: the ‘Amount Other’ might not be provided in the ACT signal). Such absent items should be declared explicitly, that is, the item should be provided with a value set to ‘null’. This means that the interface differentiates the values: o ‘null’: the item is not present o ‘’: the item is empty (so the tag length is ‘00’) 4.1 TEI automation interface Table 4.1 gives an overview of the TEI interface signals. A signal indicated as ‘optional’ means that the Product Provider need not implement the related signal. The TEI is client and the product is server. © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 19 / 35 Table 4.1: TEI Product Automation Interface Signal ID ACT ACT_ACK From/To TEI → product TEI  product Purpose of the message Request from TEI to product Confirmation from product to TEI Usage Amount, Transaction type… Confirmation of the Activate reception CONFIG (optional) CONFIG_ACK (optional) TEI → product TEI  product Request from TEI to product Confirmation from product to TEI Sharing configuration data Confirmation of the configuration loading DEKDEDS DETDEDS TEI  product TEI → product Request from product to TEI Information from TEI to product Data exchange from reader to TEI Data exchange from TEI to product MSG TEI  product Message from product to TEI Message signal OUT TEI  product Information from product to TEI Output messages RUNTEST (optional) TEI  product RUNTEST_RESULT TEI → product (optional) Message from product to TEI Message from TEI to product Permits to request the Test Tool to run a specific test. The Test Tool returns the test result. TEST_INFO (Conditional) TEST_INFO_ACK (Conditional) TEI → product TEI  product Message from TEI to product Confirmation from product to TEI Permits to send test specific data Confirmation of TEST_INFO © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 20 / 35 4.1.1 ACT Signal from TEI to the product to activate the reader and initialize the internal parameters with the transaction data. The product need not support the transaction data processing through this signal, see details in the section 4.1.2. Parameters “signalType” “signalData” “id” “value” Values/comments “ACT” Array containing the data to be passed Tag ID Data value: - any value (e.g.: “010203”) - “” (tag is empty, so length is ‘00’) - null (tag is NOT present) Example {“signalType”:”ACT”, “signalData”:[ // value may be empty: {“id”:”5F57”, “value”:””}, {“id”:”9F02”, “value”:”000000000010”}, {“id”:”9F03”, “value”:null}, // value may be null: {“id”:”DF8104”, “value”:null}, {“id”:”DF8105”, “value”:null}, {“id”:”9F7C”, “value”:”0102030405060708091011121314151617181920”}, {“id”:”9F53”, “value”:”01”}, {“id”:”5F2A”, “value”:”0978”}, {“id”:”5F36”, “value”:”02”}, {“id”:”9A”, “value”:”170303”}, {“id”:”9F21”, “value”:”133333”}, {“id”:”9C”, “value”:”00”}, // proprietary tags may be sent: {“id”:”DF9901”, “value”:”010203”} ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 21 / 35 4.1.2 ACT_ACK Acknowledgement from the product to the TEI. The product shall send the ACT_ACK signal right after the ACT one. When the Product does not support the transaction data processing through the ACT signal: • The product shall answer with ACT_ACK ‘NOTSUPPORTED’. • The transaction related data will be displayed in the Test Tool. • The transaction related data shall be entered manually in the product or by other mean provided by the Product Provider. • By default, the product will use the transaction time value ‘112233’ (tag ‘9F21’) Parameters “signalType” “signalData” “id” “value” Values/comments “ACT_ACK” Array containing the data to be passed - “ResponseCode” (mandatory) - “Description” (optional) When the “id” is “ResponseCode”: - “YES”: the ‘ACT’ signal has been received and understood, all required parameters are present and correct - “NO” (optional): the ‘ACT’ signal was recognized but contained invalid data or it failed - “NOTSUPPORTED” : the ‘ACT’ signal was recognized but it is not supported by the product When the “id” is “Description”: any value Example #1 {“signalType”:”ACT_ACK”, “signalData”:[ {“id”:”ResponseCode”,”value”:”YES”} ]} Example #2 {“signalType”:”ACT_ACK”, “signalData”:[ {“id”:”ResponseCode”,”value”:”No”} {“id”:”Description”,”value”:”error”} ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 22 / 35 4.1.3 CONFIG (optional) Signal from TEI to the product to set the test configuration. CONFIG signal is recommended when the transaction data processing through ACT is supported. Parameters “signalType” “signalData” “id” “value” Values/comments “CONFIG” Array containing the data to be passed - ‘CONF_NAME’: the ‘value’ field contains the configuration name as defined earlier in this document, e.g.: ‘C8_prof00’. This assumes the product itself is able to access a library containing all the configurations Contains the configuration name. The product should not rely on the case. In other words, this field must not be case-sensitive. Example {"signalType":"CONFIG", "signalData":[ {"id":"CONF_NAME", "value":"C8_prof00"} ]} 4.1.4 CONFIG_ACK (optional) Acknowledgement from the product to the TEI. This signal only applies when the product implements the CONFIG signal. Parameters "signalType" "signalData" "id" "value" Values/comments "CONFIG_ACK" Array containing the data to be passed - "ResponseCode" (mandatory) - "Description" (optional) When the “id” is “ResponseCode”: - "YES": the ‘CONFIG’ signal has been received and understood, all required parameters are present and correct - "NO" (optional): the ‘CONFIG’ signal was recognized but contained invalid data or it failed When the “id” is “Description”: any value © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 23 / 35 Example {"signalType":"CONFIG_ACK", "signalData":[ {"id":"ResponseCode","value":"YES"} ]} 4.1.5 DEK DEDS This signal applies when the product implements DE/DS. Signal is sent by the product to the TEI. Parameters "signalType" "signalData" "id" "value" Values/comments "DEK" Array containing the data to be passed "DEK" DEK value Example {"signalType":"DEK", "signalData":[ {"id":"DEK", "value":"FF8104069F5E009F5D00DF8106025F57"} ]} 4.1.6 DET DEDS This signal applies when the product implements DE/DS. Signal is sent by TEI to the product. Note: the TEI may send several DETs in response to a DEK. Parameters "signalType" "signalData" "id" "value" Values/comments "DET" Array containing the data to be passed "DET" DET value Example {"signalType":"DET", "signalData":[ {"id":"DET","value":"DF81120182"} ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 24 / 35 4.1.7 MSG Signal is sent by the product to the TEI. Note: there could be several MSG signals for a single ACT signal, in case of dual tap for instance. Parameters "signalType" "signalData" "id" "value" Values/comments "MSG" Array containing the data to be passed "UIRD1" Value to be passed. Should always be 22 bytes long. May be full zeroes. Example {"signalType":"MSG", "signalData":[ {"id":"UIRD1", "value":"1E040000000000000000000000000000000000000000"} ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 25 / 35 4.1.8 OUT Signal sent by the product to provide outcome details for a processing initiated by an ACT signal. Note1: There could be several OUT signals for a single ACT signal. Note2: As per the requirements PTA-10 and PTA-11 the product shall be able to return OUT signals from the Process K Note3: The OUT signals shall be sent as soon as they occur. Parameters "signalType" "signalData" "id" "value" Values/comments "OUT" Array containing the data to be passed - "OPS": must always be present - "DataRecord": As per CreateEMVDataRecord (), the DataRecord must not contain data items that are not present in the TLV Database. May be absent if no DataRecord is provided (or it may be present with value ‘null’). - "DiscData": Must be present. Must not contain data items that are not present in the TLV Database - "UIRD1": may be absent if no UIRD1 is provided (or it may be present with value ‘null’). - "UIRD2": may be absent if no UIRD2 is provided (or it may be present with value ‘null’). Value to be passed. May be ‘null’ in case of DataRecord, UIRD1/2. Example#1 {"signalType":"OUT", "signalData":[ {"id":"OPS", "value":"30F0F01038F0FF00"}, {"id":"DiscData", "value":"DF81150600000000000F"} ]} Example#2 {"signalType":"OUT", "signalData":[ {"id":"OPS", "value":"30F0F01038F0FF00"}, {"id":"DataRecord", "value":"9F0206000000000010"}, {"id":"DiscData", "value":"DF81150600000000000F"}, {"id":"UIRD1", "value":"1E040000000000000000000000"}, {"id":"UIRD2", "value":null} ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 26 / 35 4.1.9 RUNTEST (optional) This signal is optional. It allows the Product Test Environment to request the Test Tool to run a specific test. Parameters "signalType" "signalData" "id" "value" Values/comments "RUNTEST" Array containing the data to be passed "TestId" Test ID to be run. The “TestId” format must follow the overview test list defined in Annex A of C-8 Test Cases. Example {"signalType":"RUNTEST", "signalData":[ {"id":"TestId","value":"3M23-1111 | A | 01"} ]} 4.1.10 RUNTEST_RESULT (optional) This signal is optional. It permits the Test Tool to return the test result to the Product Test Environment when the test was triggered by the RUNTEST signal. Parameters "signalType" "signalData" "id" "value" Values/comments "RUNTEST_RESULT" Array containing the data to be passed "TestResult" ‘PASS’ or ‘FAIL’ Note: when the Test Tool does not recognize the ‘Test ID’ provided in the RUNTEST signal, it must return "RUNTEST_RESULT" with ‘TestResult’=’FAIL’. Example {"signalType":"RUNTEST_ RESULT", "signalData":[ {"id":"TestResult", "value":"PASS"} ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 27 / 35 4.1.11 TEST_INFO (Conditional) Signal is sent by the TEI to the product. The product need not implement this signal. However, this signal is mandatory when the product supports the processing of the transaction data through the ACT signal. This signal is not defined in [C-8] specifications but may be useful during the test sessions to identify/trace the test details. For compatibility reasons, the product must accept additional values in the id field when provided by TEI.. If implemented, the TEI will send this signal prior to the ACT signal. Parameters "signalType" "signalData" "id" "value" Values/comments "TEST_INFO" Array containing the data to be passed - "InterfaceVersion": the interface version - "SessionId": session details - "TestId": Test name. The “TestId” format must follow the overview test list defined in Annex A of C-8 Test Cases e.g.: 4M23-1111 | A | 01 or 4M23-1111 | A | or 4M23-2222 | | 01 or 4M23-3333 | | or 4M23-1203 | A | 01 | ToolVendorDetails Value to be passed (may be ‘null’ if an item is absent) Example {"signalType":"TEST_INFO", "signalData":[ {"id":"InterfaceVersion", "value":"20220303"}, {"id":"SessionId", "value":"Session_20230105_093731"}, {"id":"TestId", "value":"4MX2-1600 | A | 03"}, ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 28 / 35 4.1.12 TEST_INFO_ACK (Conditional) Acknowledgement from the product to TEI upon reception of TEST_INFO signal. This signal only applies when the product implements the TEST_INFO signal. Parameters "signalType" "signalData" "id" "value" Values/comments "TEST_INFO_ACK" Array containing the data to be passed - "ResponseCode" (mandatory) - "Description" (optional) When the “id” is “ResponseCode”: - "YES": the ‘TEST_INFO’ signal has been received and understood, all required parameters are present and correct - "NO" (optional): the ‘TEST_INFO’ signal was recognized but contained invalid data or it failed When the “id” is “Description”: any value Example {"signalType":"TEST_INFO_ACK", "signalData":[ {"id":"ResponseCode","value":"YES"} ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 29 / 35 4.1.13 State machines This section gives two expected state machines for the product implementing the automation interface: 1. State machine when the TEST_INFO signal is not supported (Figure 4.1). Such product has no knowledge of the test being run, so it does not make any difference between a test and a transaction. 2. State machine when the TEST_INFO signal is supported (Figure 4.2) A state ‘Test initiated’ is added. If a test includes several transactions, the TEI will send a single TEST_INFO signal and several ACT signals. Note: The product does not leave the ‘Test initiated’ state at the end of a transaction (unless a CONFIG_ACK ‘Yes’ signal occurs). This is due to the fact that a test may include several transactions. So the product cannot figure out if the end of a transaction corresponds to the end of the test or if another transaction is coming for the same test. Figure 4.1: Automation product state machine (TEST_INFO not supported) ELSE Idle CONFIG_ACK Yes ELSE Configured ACT_ACK Yes or notsupported OUT - Start N/A OUT - Start B - Start C ELSE Transaction on-going © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 30 / 35 Figure 4.2: Automation product state machine (TEST_INFO supported) ELSE Idle CONFIG_ACK Yes ELSE Configured CONFIG_ACK Yes TEST_INFO_ACK Yes ELSE Test on-going ACT_ACK Yes or notsupported ELSE Transaction on-going OUT - Start B - Start C OUT - Start N/A © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 31 / 35 4.2 PCD-bypass interface This interface permits to run the tests without using the PCD. APDU exchanges are made using a TCP/IP connection. This protocol is following a client/server mode This interface is optional. However, EMVCo recommends implementing it so the APDU exchanges are made with timing close to the field one. Indeed, when the Test Tool NFC probes are used, the APDU exchanges last between 200 to 400ms with significant impact on RRP and DataExchange tests. Note : Product Provider choosing to implement ‘PCD-bypass’ must also implement Test Tool NFC probe mechanism (Refer to CIR-05). If we consider that the product implements an architecture close to the one defined in [C-8] then the Process P manages the interaction with the card. When the PCD-bypass feature is used, the Process P must interact with the Test Tool instead of the card. In other words, the Process P: • Activates the field and looks for a (virtual) card. • Receives C-APDUs from Process K and Process S and passes them to the Test Tool’s virtual card • Receives the R-APDUs (or Level1 error messages) from the virtual card for further processing Table 4.2 gives an overview of the PCD-bypass interface signals. The Test Tool is server and the product is client. Table 4.2: Card Product Automation Interface Signal ID APDU_ACTIVATE APDU_CMD APDU_RESP From/To product → virtual card product → virtual card virtual card → product Purpose of the message Activation signal sent by the product to the virtual card C-APDU sent by the product to the virtual card R-APDU sent by the virtual card to the product Usage Card activation Sending CAPDUs Managing responses © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 32 / 35 4.2.1 APDU_ACTIVATE Signal from product to the virtual card to activate the (virtual) card. This signal is mandatory when implementing the PCD-bypass interface. Parameters "signalType" "signalData" "id" "value" Values/comments "APDU_ACTIVATE" Array containing the data to be passed "ACTIVATE" - "Yes": card activation requested - "No": card de-activation requested Example {"signalType":"APDU_ACTIVATE", "signalData":[ {"id":"ACTIVATE", "value":"Yes"} ]} 4.2.2 APDU_CMD Signal from product to the virtual card containing a C-APDU. This signal is mandatory when implementing the PCD-bypass interface. Parameters "signalType" "signalData" "id" "value" Values/comments "APDU_CMD" Array containing the data to be passed "CAPDU" Contains the CAPDU value Example {"signalType":"APDU_CMD", "signalData":[ {"id":"CAPDU", "value":"80EA0000044D81036700"} ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 Page 33 / 35 4.2.3 APDU_RESP Signal from virtual card to the product containing a R-APDU. This signal is mandatory when implementing the PCD-bypass interface. Parameters "signalType" "signalData" "id" "value" Values/comments "APDU_RESP" Array containing the data to be passed - "RAPDU" - "L1RSP" - If "id"="RAPDU", value contains the RAPDU value plus the SW - If "id"="L1RSP", value contains either: o "OK [ATR value]" in response to "APDU_ACTIVATE:Yes" o “OK [any details]” in response to "APDU_ACTIVATE:No" o "ERROR [error details]" Example #1 – response to RRP command {"signalType":"APDU_RESP", "signalData":[ {"id":"RAPDU", "value":"800A9A8B7C6E00AA0FA000289000"} ]} Example #2 – response to ‘APDU_ACTIVATE:Yes’ {"signalType": "APDU_RESP", "signalData":[ {"id": "L1RSP", "value":"OK 3B8880010073C8400000900062"} ]} Example #3 – card error / mute card / card withdrawn {"signalType": "APDU_RESP", "signalData":[ {"id": "L1RSP", "value":"ERROR blabla"} ]} Example #4 – response to ‘APDU_ACTIVATE:No’ (card de-activation requested) {"signalType": "APDU_RESP", "signalData":[ {"id": "L1RSP", "value":"OK CardRemoved"} ]} © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 4.2.4 Exchange scenarios Scenario #1: transaction initialization Action Reader connects to the 'PCD-bypass’ socket Reader sends APDU_ACTIVATE:YES Probe returns APDU_RESP:L1RSP:OK [ATR] Reader sends APDU_CMD:CAPDU [PPSE] Scenario #2: transaction closure Action Reader sends APDU_ACTIVATE:NO Probe returns APDU_RESP:L1RSP:OK CardRemoved Reader disconnects the 'PCD-bypass’ socket Scenario #3: StartB (following L1RSP) Action Reader sends APDU_CMD:CAPDU [GenAC] Probe returns APDU_RESP:L1RSP:ERROR MuteCard Reader sends APDU_ACTIVATE:NO Probe returns APDU_RESP:L1RSP:OK CardRemoved Reader disconnects the 'PCD-bypass’ socket Reader waits for tPOWEROFF > 15 ms Reader connects to the 'PCD-bypass’ socket Reader sends APDU_ACTIVATE:YES Probe returns APDU_RESP:L1RSP:OK [ATR] Reader sends APDU_CMD:CAPDU [PPSE] Reader sends APDU_ACTIVATE:NO Reader disconnects the 'PCD-bypass’ socket Page 34 / 35 NFC equivalence PCD power on Polling Card present PPSE CAPDU NFC equivalence Card removal requested Card removed PCD power off NFC equivalence GenAC CAPDU Mute card Card removal requested Card removed PCD power off Level1 spec, section 3.2.9.1 PCD power on Polling Card present PPSE CAPDU Card removal requested PCD power off © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Book C-8Testing Environment Requirements v1.2 *** END OF DOCUMENT *** Page 35 / 35 © 2023-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.