PCI Watch

Tracking changes across the Payment Card Industry

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

v1.3 Test Cases & Test Environments
Contactless Acceptance Device

countries. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements Version 1.3 July 2026 EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 Page i

countries.

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 NON - INFRINGEMENT, 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

countries. Revision Log – 1.3 The following changes have been done since release of version 1.2:

  • Picture updates.
  • Clarification on System tests.
  • Editorial updates EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 countries. 1. 1. 1. 1. 1. 1. 1. 2. 2.1. 2.1. 2.1. 2.1. 2.1. 2.1. 2.1. 2.1. 2.1. 3.

3.2 Requirements for Communication Interfaces

3. 3. 3.4. 3.4. 3.4. 4. 4.1. 4.1. 4.1. 4.1. 4.1. 4.1. 4.1. 4.1. 4.1. 4.1. 4.1. 4.1. 4.1. 4. 4.2. 4.2. 4.2. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

countries. 4.2. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 Page v

countries. Figures Figure 2. Figure 2. Figure 2. Figure 3. Figure 3. Figure 4. Figure 4. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

countries. Tables Table 1. Table 1. Table 3. Table 3. Table 3. Table 3. Table 4. Table 4. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries. 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 Document Version Issue Date EMV Terminal Type Approval Contactless Product – Administrative Process latest applicable version [C-8] EMV Contactless Specifications for Payment Systems – Book C-8 - Kernel 8 Specification Version 1.2, June 2026, or later version [Book A] EMV Contactless Specifications for Payment Systems – Book A – Architecture and General Requirements Latest available 30[Book B] EMV Contactless Specifications for Payment Systems – Book B – Entry Point Specification Latest available [Book E] EMV Contactless Specifications for Payment Systems – Book E – Security and Key Management Latest available Any applicable Specification Bulletins as published on the EMVCo website EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries. Reference Document Version Issue Date [ReaderCo nf] ReaderConfs.xmd latest applicable version 1.4 Abbreviations Table 1.2: Abbreviations Abbreviation

Description

DE/DS Data Exchange and Data Storage EMV® A trademark owned by EMVCo, referring to the technical specifications published by EMVCo. PCD Proximity Coupling Device RRP Relay resistance protocol TEI 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. Automation is used in functional tests (except System tests). Automation is not used during the execution of the System tests.

  • Performance.
  • Module Integration.
  • Relay Resistance Protocol Accuracy. 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: EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries. 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 if the product is submitted without PCD (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 Read DEDS 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:
  • Transaction related data must be either provided by the Product Provider (recommended) or entered manually by the test operator.
  • The product shall answer with ACT_ACK ‘NOTSUPPORTED’. Please refer to sections 4.1.1 and 4.1.2.
  • 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries. 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

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.
  • PCD. 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.
  • PCD is not mandatory if the Product follows the EMVCo standalone process and none of Performance and RRP Accuracy test is performed.

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 EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.
  • Permits to transmit the transaction outcomes to the Test Tool during the tests run in automation mode using TEI interface.
  • 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries. 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries. 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.

3.1 Requirements for Application Selection module Table 3.1: Application Selection module Requirements ASR-01 Application Selection method Common 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 30[Book B]. ASR-02 Kernel Activation Common 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. ASR-03 Pre- Processing Common If the product implements the Pre-Processing defined in 30[Book B] Section 3.1, the Configuration Data shall be such that none of the pre-processing indicators (if any) are set. ASR-04 Start B Common 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 30[Book B]). The product must not expect the Test Tool to send a second ACT signal before starting the protocol activation - Start B. ASR-05 Start C Common 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 30[Book B]). ASR-06 Pre- Processing Auto Application Selection module must not block empty/missing amount. ASR-07 Pre- Processing Auto Application Selection module must not block a SELECT (AID) response with status words ‘9000’ whenever the ‘6F’ template is absent or wrongly formatted. ASR-08 Pre- Processing Auto 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 30[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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.

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 TEI communication interface Auto The product must meet the requirements defined in Section 4.1. CIR-02 TEI connection protocol Auto The connection between the Test Tool Environment Interface and the product is done using TCP/IP. This protocol is following a client/server mode. CIR-03 PCD-bypass communication interface Auto If the product supports PCD-bypass, it must meet the requirements defined in Section 4.1. CIR-04 PCD-bypass connection protocol Auto 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. CIR-05 NFC Probe Common The product must support APDU exchanges using Contactless Interface (Test Tool NFC Probe or Cardholder devices). Note: If the Product follows the EMVCo standalone process and Performance and RRP Accuracy tests are not performed, requirement CIR-05 is not mandatory. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

3.3 Requirements for the Product Test Application Table 3.3: Product Test Application Requirements PTA-01 Loading configuration Manual 1 The Product Test Application shall permit to load the configuration without using the TEI Interface. PTA-02 Configuration data set Common The Product Provider shall build the configuration data set that include all the configurations defined in the [ReaderConf] file provided by EMVCo. PTA-03 Symbolic values Manual 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”. PTA-04 Cut & paste Manual 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). PTA-05 MSG signal Manual 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’. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries. PTA-06 OUT signal Manual 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’. PTA-07 Transaction related data objects Manual 2 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries. PTA-08 Updating the transaction related data objects Manual 2 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). PTA-09 Autorun Common If supported, the Autorun parameter value must be “No”. PTA-10 OUT vs Select Next Common 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 PTA-11 OUT vs Start B Common 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. PTA-12 OUT vs Process S Common 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries. PTA-13 Date & Time Common If the product under test manages its own clock, then any date and time passed to it must overwrite the internal date and time. PTA-14 Default configuration Common It is expected that a default configuration is loaded when the product is powered on. During test session, the default configuration is ‘C8_prof00’. PTA-15 Transaction log Common 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. PTA-16 Outcome Parameter Set Manual [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 EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries. PTA-17 Processing of the transaction data through ACT signal not supported Auto 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.

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 <ReaderConf>. Each configuration <ReaderConf> is defined by 3 attributes: EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.
  • ‘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 <ReaderConf> element has 1 child: <KernelConf> that has one attribute ‘KernelID’. For C-8 testing the ‘KernelID’ value is “08”. <KernelConf> has two children:
  • <ConfData>: This element lists the C-8 specification tags that shall be implemented.
  • <PropTags>: 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 <TagDetails> elements. Each tag to be implemented is defined with the <TagDetails> 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 <TagDetails> includes the following additional attributes when it is a child of <PropTags>:
  • ‘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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.

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 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’). CNF-02 Zero length Common 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()”’ CNF-03 Additional objects Common 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries. 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 if the Product contains a PCD. 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. EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries. Table 4.1: TEI Product Automation Interface Signal ID From/To Purpose of the message Usage ACT TEI → product Request from TEI to product Amount, Transaction type… ACT_ACK TEI  product Confirmation from product to TEI Confirmation of the Activate reception CONFIG (optional) TEI → product Request from TEI to product Sharing configuration data CONFIG_ACK (optional) TEI  product Confirmation from product to TEI Confirmation of the configuration loading DEK DEDS TEI  product Request from product to TEI Data exchange from reader to TEI DET DEDS TEI → product Information from TEI to product 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 Message from product to TEI Permits to request the Test Tool to run a specific test. RUNTEST_RESULT (optional) TEI → product Message from TEI to product The Test Tool returns the test result. TEST_INFO (Conditional) TEI → product Message from TEI to product Permits to send test specific data TEST_INFO_ACK (Conditional) TEI  product Confirmation from product to TEI Confirmation of TEST_INFO EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.

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 Values/comments “signalType” “ACT” “signalData” Array containing the data to be passed “id” Tag ID “value” 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”} ]} EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

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 Values/comments “signalType” “ACT_ACK” “signalData” Array containing the data to be passed “id” - “ResponseCode” (mandatory) - “Description” (optional) “value” 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”} ]} EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.

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 Values/comments “signalType” “CONFIG” “signalData” Array containing the data to be passed “id” - ‘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 “value” 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 Values/comments "signalType" "CONFIG_ACK" "signalData" Array containing the data to be passed "id" - "ResponseCode" (mandatory) - "Description" (optional) "value" 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 EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries. 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 Values/comments "signalType" "DEK" "signalData" Array containing the data to be passed "id" "DEK" "value" 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 Values/comments "signalType" "DET" "signalData" Array containing the data to be passed "id" "DET" "value" DET value Example {"signalType":"DET", "signalData":[ {"id":"DET","value":"DF81120182"} ]} EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

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 Values/comments "signalType" "MSG" "signalData" Array containing the data to be passed "id" "UIRD1" "value" Value to be passed. Should always be 22 bytes long. May be full zeroes. Example {"signalType":"MSG", "signalData":[ {"id":"UIRD1", "value":"1E040000000000000000000000000000000000000000"} ]} EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

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 Values/comments "signalType" "OUT" "signalData" Array containing the data to be passed "id" - "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" 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} ]} EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

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 Values/comments "signalType" "RUNTEST" "signalData" Array containing the data to be passed "id" "TestId" "value" 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 Values/comments "signalType" "RUNTEST_RESULT" "signalData" Array containing the data to be passed "id" "TestResult" "value" ‘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"} ]} EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

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 Values/comments "signalType" "TEST_INFO" "signalData" Array containing the data to be passed "id" - "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" 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"}, ]} EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

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 Values/comments "signalType" "TEST_INFO_ACK" "signalData" Array containing the data to be passed "id" - "ResponseCode" (mandatory) - "Description" (optional) "value" 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"} ]} EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

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) Idle Configured Transaction on-going CONFIG_ACK Yes ACT_ACK Yes or notsupported ELSE OUT

  • Start B
  • Start C OUT
  • Start N/A ELSE ELSE EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries. Figure 4.2: Automation product state machine (TEST_INFO supported) Idle Configured Test on-going Transaction on-going CONFIG_ACK Yes TEST_INFO_ACK Yes ACT_ACK Yes or notsupported ELSE OUT
  • Start B
  • Start C OUT
  • Start N/A ELSE CONFIG_ACK Yes ELSE ELSE EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.

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 if product contains a PCD. 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 Data Exchange tests. 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 From/To Purpose of the message Usage APDU_ACTIVATE product → virtual card Activation signal sent by the product to the virtual card Card activation APDU_CMD product → virtual card C-APDU sent by the product to the virtual card Sending CAPDUs APDU_RESP virtual card → product R-APDU sent by the virtual card to the product Managing responses EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.

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 Values/comments "signalType" "APDU_ACTIVATE" "signalData" Array containing the data to be passed "id" "ACTIVATE" "value" - "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. Example {"signalType":"APDU_CMD", "signalData":[ {"id":"CAPDU", "value":"80EA0000044D81036700"} ]} Parameters Values/comments "signalType" "APDU_CMD" "signalData" Array containing the data to be passed "id" "CAPDU" "value" Contains the CAPDU value EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries.

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 Values/comments "signalType" "APDU_RESP" "signalData" Array containing the data to be passed "id" - "RAPDU" - "L1RSP" "value"

  • 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"} ]} EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3 / 36 countries.

4.2.4 Exchange scenarios Scenario #1: transaction initialization Action NFC equivalence Reader connects to the 'PCD-bypass’ socket PCD power on Reader sends APDU_ACTIVATE:YES Polling Probe returns APDU_RESP:L1RSP:OK [ATR] Card present Reader sends APDU_CMD:CAPDU [PPSE] PPSE CAPDU Scenario #2: transaction closure Action NFC equivalence Reader sends APDU_ACTIVATE:NO Card removal requested Probe returns APDU_RESP:L1RSP:OK CardRemoved Card removed Reader disconnects the 'PCD-bypass’ socket PCD power off Scenario #3: StartB (following L1RSP) Action NFC equivalence Reader sends APDU_CMD:CAPDU [GenAC] GenAC CAPDU Probe returns APDU_RESP:L1RSP:ERROR MuteCard Mute card Reader sends APDU_ACTIVATE:NO Card removal requested Probe returns APDU_RESP:L1RSP:OK CardRemoved Card removed Reader disconnects the 'PCD-bypass’ socket PCD power off Reader waits for tPOWEROFF > 15 ms Level1 spec, section 3.2.9.1 Reader connects to the 'PCD-bypass’ socket PCD power on Reader sends APDU_ACTIVATE:YES Polling Probe returns APDU_RESP:L1RSP:OK [ATR] Card present Reader sends APDU_CMD:CAPDU [PPSE] PPSE CAPDU Reader sends APDU_ACTIVATE:NO Card removal requested Reader disconnects the 'PCD-bypass’ socket PCD power off EMV® Terminal Type Approval Book C-8 Testing Environment Requirements v1.3

/ 36

countries. *** END OF DOCUMENT ***