EMV chip and contactless testing requirements
EMV is the EMVCo specification set for chip and contactless card payments. EMV requirements apply to terminal vendors, POS software teams, and acquirer hosts. EMV testing verifies offline decisions, reversals, and acquirer messages against EMV Books 3 and 4. FintechAssuranceLabs delivers test logs, APDU traces, host message traces, and a defect log that cites the broken clause.
- Jurisdiction
- Global (EMVCo specifications; Level 3 rules set by each payment system)
- Primary source
- emvco.com
Engineering interpretation of testing requirements, not compliance advice.
What the EMV specifications require
EMV contact acceptance is defined by the EMV Integrated Circuit Card Specifications for Payment Systems, version 4.4, October 2022. EMVCo publishes the specifications and the approval processes on its EMV Contact Chip page (checked on 2026-09-16). The contact specification has four books:
- Book 1, Application Independent ICC to Terminal Interface Requirements.
- Book 2, Security and Key Management.
- Book 3, Application Specification. Section 10 defines the transaction functions: 10.3 offline data authentication, 10.5 cardholder verification, 10.6 terminal risk management, 10.7 terminal action analysis, 10.9 online processing, and 10.10 issuer-to-card script processing.
- Book 4, Cardholder, Attendant, and Acquirer Interface Requirements. Section 12 defines the acquirer interface: authorisation requests, batch data capture, reconciliation, reversals, and exception handling when the terminal cannot go online.
EMV contactless acceptance adds Book A (architecture and general requirements), Book B (Entry Point), and one Book C-x kernel specification per payment system. EMVCo published Version 1 of the EMV Contactless Kernel Specification, Book C-8, on 5 October 2022.
Approval has three levels. Level 1 tests the reader against the mechanical and electrical protocols. Level 2 tests the kernel firmware. Level 3 tests that the terminal works end to end with merchant and acquirer systems, and each payment system defines its own Level 3 rules. EMVCo runs an EMV Level 3 Testing Framework and qualifies Level 3 test tools. A contact kernel receives a 4-year Letter of Approval. A contactless product receives a 3-year Letter of Approval after the laboratory validates the reader, Entry Point, and at least one kernel. EMVCo launched the EMV Contactless Kernel testing process on 16 October 2024, including standalone kernel testing.
What testing verifies
EMVCo-recognised laboratories run Level 1 and Level 2 approval tests. The rows below are the terminal, POS software, and acquirer host behaviours that functional and Level 3 testing verifies after the kernel is approved.
| Requirement | What we test | Evidence produced |
|---|---|---|
| Book 3 section 10.6.1, floor limits | Offline amounts below, at, and above the terminal floor limit, with and without a log entry for the same PAN. | TVR "Transaction exceeds floor limit" bit value for each test case. |
| Book 3 section 10.7, terminal action analysis | TAC and IAC Denial, Online, and Default values against each TVR bit that the test cards set. | APDU trace with the cryptogram type (AAC, ARQC, or TC) that the terminal requests in each case. |
| Book 3 section 10.5, cardholder verification | CVM list processing for offline PIN, online PIN, signature, and no CVM at each amount condition. | CVM Results value and receipt image for each test case. |
| Book 3 section 10.9, online processing | Authorisation responses with and without Issuer Authentication Data (tag 91), and a card that rejects EXTERNAL AUTHENTICATE. | TVR "Issuer authentication failed" bit value and host message trace for each case. |
| Book 4 section 12.2.1, unable to go online | Acquirer host unavailable, followed by the TAC Default and IAC Default decision. | Capture record with the Authorisation Response Code "Unable to go online, offline accepted" or "Unable to go online, offline declined". |
| Book 4 section 12.2.3, authorisation response incidents | Response timeout, late response, malformed response, and lost request. | Acquirer trace that shows a reversal for each incident when the acquirer performs online data capture. |
| Book 4 section 12.1.5, batch data capture | ICC data elements in the financial record for each offline approval. | Batch file field check against Book 4 Table 17 and Table 18. |
| Book 4 section 6.5.4, transaction forced acceptance | Attendant override after the card returns an AAC. | Advice or batch record with the forced acceptance indicator set. |
| Book 4 section 6.5.5, transaction sequence counter | Counter value after a reboot, after a firmware update, and at the maximum value. | Counter sequence from the terminal log with no zero value and no repeated value. |
| Book B Entry Point, contactless pre-processing | Reader Contactless Transaction Limit, Reader Contactless Floor Limit, and Reader CVM Required Limit per AID and kernel. | Kernel ID and outcome for each amount step and each test card. |
Chip test cases use the test card sets of each payment system. Online sandbox tests without a physical card use published test card numbers, described in the test card numbers guide.
Artifacts an acquirer or payment system requests
- Letter of Approval numbers for the Level 1 reader and the Level 2 contact or contactless kernel, with validity dates.
- Implementation Conformance Statement that matches the terminal configuration in the field.
- Terminal configuration per AID: TAC values, floor limits, CVM limits, contactless limits, and certification authority public keys.
- Level 3 test tool logs and results for each payment system test plan, from a qualified Level 3 test tool.
- Host message traces for authorisation, reversal, advice, and batch capture messages.
- Receipt samples for approved, declined, and offline transactions. Book 4 section 11.4 requires the AID in hexadecimal on every receipt.
- Release record that links each firmware and kernel version to its Letter of Approval.
Terminals and acquirer hosts that store, process, or transmit account data are in PCI DSS scope. The PCI DSS testing requirements page covers that evidence.
Common findings
- No reversal after a timeout. The terminal approves offline after the host times out but sends no reversal. If the host approved the lost request, the cardholder carries an authorisation hold and an offline financial record for the same purchase. This breaks Book 4 section 12.2.3.
- Split sales pass the floor limit. The floor limit check compares only the current amount and ignores earlier approvals for the same PAN in the transaction log. This breaks Book 3 section 10.6.1.
- Wrong action codes when offline. After a failed connection, the terminal applies TAC Online instead of TAC Default and IAC Default. Transactions that the issuer would decline get approved offline. This breaks Book 4 section 12.2.1 and Book 3 section 10.7.
- Issuer authentication result lost. The card rejects EXTERNAL AUTHENTICATE, and the terminal does not set the "Issuer authentication failed" bit in the TVR. This breaks Book 3 section 10.9.
- Offline approvals without ICC data. The batch record for an offline approval drops the application cryptogram, so the acquirer cannot clear the transaction with chip data. This breaks Book 4 section 12.1.5.
- Forced acceptance not flagged. The attendant overrides an AAC, and the capture record has no forced acceptance indicator. This breaks Book 4 section 6.5.4.
- Counter reset to zero. A firmware update resets the transaction sequence counter to zero. This breaks Book 4 section 6.5.5.
How we cover EMV
The POS and payment device testing service delivers the EMV and contactless transaction test suite, offline mode and store-and-forward scenarios, the device and firmware compatibility matrix, and end-of-day batch reconciliation checks. These deliverables produce the evidence files listed in the table. The service fits POS and merchant services teams before a Level 3 submission and before each firmware release.
Acquirer host behaviour after the terminal decision belongs to payment flow testing. That service delivers the payment flow map and the defect log with financial impact per defect, including reversal and batch capture defects. Payment acquiring platforms use it for timeout, reversal, and settlement file checks.
Issuers see EMV from the other side, through ARQC validation and Issuer Authentication Data in the authorisation response. Card issuing and processing testing delivers the spend control and authorisation rule test matrix for BaaS, neobank, and corporate card programmes, including chip transactions.
Related
Segments
Adjacent standards
Questions
What is EMV chip?
What is an EMV chip card?
Scope your testing
Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.
Scope your testing