EMV StackCertification · Level 2 · Level 3
EMV Level 2 vs Level 3: What Each Certification Covers
Anyone who builds or deploys an EMV terminal runs into the words Level 1, Level 2 and Level 3. They are not stages of the same test. They are three separate certifications, run by different organisations, that check different layers of the payment stack. This guide focuses on the difference between Level 2 and Level 3, the two that software teams deal with most.
The three levels at a glance
| Level 1 | Level 2 | Level 3 | |
|---|---|---|---|
| What is tested | The physical card interface: contact reader electrics and contactless radio | The EMV kernel software that runs the transaction | The complete solution: terminal, payment application, configuration and host connection |
| Who approves it | EMVCo | EMVCo or the payment schemes | The payment schemes, through the acquirer or processor |
| Who usually runs it | Hardware vendor, with an accredited lab | Kernel or terminal vendor, with an accredited lab | Acquirer, processor or integrator, often with the merchant's solution provider |
| Result | Letter of Approval | Letter of Approval for a kernel and its configurations | Scheme approval or certification letter for a specific deployment |
| Done once per | Hardware design | Kernel version and configuration set | Terminal, application and acquirer combination |
What Level 2 covers
Level 2 tests the kernel: the software that talks to the card and follows the EMV rules. For a contact kernel this means application selection, reading data, offline data authentication, processing restrictions, cardholder verification, terminal risk management, terminal action analysis and the GENERATE AC flow. For contactless kernels, each kernel specification, such as Book C-2 for Mastercard or Book C-8 for EMVCo's Kernel 8, defines its own flow.
The lab runs a defined set of test cases with simulated cards and checks every command and every decision. The kernel is tested in the configurations the vendor declares, for example which CVMs, offline authentication methods and terminal types it supports. These choices are recorded in an Implementation Conformance Statement, and the Letter of Approval lists the approved configurations.
Level 2 does not care which acquirer you connect to, what your receipt looks like or how your host builds an authorisation message. It only checks that the kernel behaves exactly as the specification says.
What Level 3 covers
Level 3 tests the whole solution as it will be deployed. It checks that the approved kernel is integrated correctly and that the payment application, the terminal configuration and the host connection produce correct transactions end to end. Typical areas include:
- Configuration: AIDs, terminal action codes, floor limits, contactless limits, CVM capabilities and CA public keys for each scheme.
- Message content: the chip data in ISO 8583 field 55, the POS entry mode, terminal capabilities and the other fields the scheme requires.
- Online processing: approvals, declines, issuer authentication data, issuer scripts, reversals and timeouts.
- Cardholder experience: prompts, PIN entry, receipts and fallback rules.
Each scheme runs its own programme with its own test cards and tools. Well-known examples are Mastercard's Terminal Integration Process (M-TIP) and Visa's device validation toolkits for contact and contactless acceptance. Other schemes have their own programmes. EMVCo also publishes a Level 3 testing framework that standardises how test card images and tools are described, so the same test material can be used across tools.
Why both are needed
A kernel can pass Level 2 and still produce bad transactions in the field. Level 2 proves the kernel is correct; Level 3 proves that the way you configured and connected it is correct. The two most common reasons a Level 2 approved kernel fails Level 3 are wrong configuration, such as action codes or limits that differ from the acquirer's requirements, and wrong data in the authorisation message, such as missing or altered field 55 tags.
What triggers new testing
| Change | Level 2 | Level 3 |
|---|---|---|
| New kernel version | New approval | Usually a new test |
| New terminal hardware with the same kernel | Check the approval covers the new device | Usually a new test |
| New configuration values, such as action codes or limits | Not if within the approved configurations | Usually a new or partial test |
| New acquirer or processor | No | Yes |
| Payment application or host message changes | No | Often, depending on the change |
Rules differ by scheme and acquirer, so always confirm with your acquirer before you ship a change.
Common Level 3 failures
- Field 55 is missing tags the scheme requires, or contains values that differ from the ones sent to the card.
- Terminal capabilities (
9F33) or terminal type (9F35) do not match what the device really does. - Action codes or contactless limits do not match the acquirer's published values.
- Issuer authentication data or scripts from the host are not passed to the card.
- Reversals are not sent when the card declines after an online approval.
- Expired or missing CA public keys, so offline authentication fails.
How to keep Level 3 manageable
The more of your payment application that depends directly on one kernel's interface, the more you have to retest when anything changes. Teams that support several terminals or kernels often put an abstraction layer between the payment application and the Level 2 kernels, so configuration and message building stay in one place. We cover that approach in our upcoming EMV Level 2 Abstraction guidance.
Frequently asked questions
Can I skip Level 2 if I buy a certified terminal?
Yes, in the sense that you do not repeat it: you rely on the vendor's Level 2 approval. Check that the approval covers the exact kernel version and configuration you use. You still need Level 3.
Do Level 2 approvals expire?
EMVCo approvals have a defined validity period, after which new deployments generally need a renewed approval. Check EMVCo's current type approval policy for the exact rules.
Who pays for Level 3?
It depends on the commercial agreement. Often the solution provider or merchant pays for the testing and tools, and the acquirer manages the submission to the schemes.
Is Level 3 the same in every country?
The core is similar, but schemes and acquirers add regional rules, for example for domestic schemes, PIN requirements or contactless limits.
Try it. When a Level 3 test fails, paste the field 55 data into the TLV parser and check the TVR and action codes in the TVR decoder. Most failures show up there first.