Why APIs Matter in EMV: The Missing Level 2 API

EMV is one of the most thoroughly specified technologies in payments. Thousands of pages define how a card and a terminal talk, how a kernel makes decisions and how both are tested. Yet two interfaces that every payment terminal depends on are not standardised at all: the programming interface between the payment application and the Level 2 kernel, and the interface between the kernel and the terminal's own services. That gap shapes the cost, speed and flexibility of every EMV project.

What EMV standardises, and what it does not

The contactless books describe how the kernel, the Entry Point and the reader interact, but as abstract signals and data exchanges. They stop short of a concrete interface with defined functions, data types, calling conventions and error handling. Every kernel vendor fills that gap with its own design.

Why an API matters

An API is a contract. It says what one piece of software offers and how another piece may use it, without exposing how the work is done. Good contracts let teams work independently, swap components, test in isolation and reuse what has already been proven. In payments, where every change can mean new certification, that reuse is worth a great deal.

Without a standard API, each payment application is written against one vendor's kernel interface. The application ends up knowing that vendor's function names, configuration format, error codes and callback model. Moving to another kernel, another terminal or another kernel version means rewriting that integration and testing it again.

The missing Level 2 API

Every kernel exposes roughly the same functions to the payment application:

• Load configuration: AIDs, action codes, limits, capabilities and CA public keys.
• Start a transaction with an amount, currency and transaction type.
• Report progress and messages to show the cardholder.
• Ask the application to go online and accept the issuer's response.
• Return an outcome with the data needed for authorisation, clearing and receipts.

Because none of this is standardised, every vendor names, orders and structures these steps differently. Some use a single call with callbacks; others use a state machine driven step by step. Configuration may be TLV, XML, JSON or a proprietary binary format. Even the outcome model differs, although the contactless books already define a common set of outcomes such as approved, declined, online request, try again and try another interface.

The consequence is lock-in. The payment application, often the largest and most valuable piece of terminal software, becomes tied to the kernel it was first written for.

The missing hardware abstraction layer

The kernel itself depends on services that only the terminal can provide:

• Card interfaces: sending commands to the contact chip and the contactless reader, detecting cards, controlling the field and detecting collisions.
• Cryptography: RSA, ECC, hashing and AES for offline authentication and, in Kernel 8, for the secure channel.
• Random numbers: the unpredictable number and the entropy for relay resistance.
• Time: transaction date and time, timeouts and precise timing for relay resistance.
• Secure storage: CA public keys, revocation lists, configuration and torn transaction logs.
• Cardholder interaction: display, LEDs, sounds and PIN entry through a secure PIN pad.

There is no standard hardware abstraction layer for these services. Each kernel vendor defines its own porting layer, and each terminal maker implements it again for every kernel it hosts. The same random number generator or contactless driver may be wrapped five times on one device, once per kernel, each wrapper with its own quirks and its own bugs.

What this costs

• Porting effort. Bringing a kernel to new hardware, or a payment application to a new kernel, is a project in itself.
• Repeated certification. Integration changes often trigger new Level 3 testing even when the Level 2 kernel is unchanged.
• Slower adoption of new kernels. Adding Kernel 8, or a new version of a scheme kernel, means a new integration rather than a drop-in replacement.
• Fewer choices. Terminal makers and payment application developers are tied to the kernel vendors they already integrated.
• Harder testing. Test tools and automation must adapt to each vendor's interface, so each scheme and vendor tends to develop its own approach.

Standards exist around EMV, but not here

The payments and retail industries have standardised interfaces next to this gap. PC/SC defines how a computer talks to a smart card reader. UnifiedPOS defines interfaces for point-of-sale peripherals such as printers and scanners. The nexo standards define how a cash register talks to a payment terminal and how a terminal talks to an acquirer. None of them defines the interface between a payment application and an EMV Level 2 kernel, or the services a kernel needs from the terminal.

What a good Level 2 API would look like

• A single transaction lifecycle that works for contact and contactless, with kernel-specific steps handled inside.
• A common outcome model based on the outcomes already defined for contactless kernels.
• Configuration and data as TLV, using the tags EMV already defines, with room for kernel-specific tags.
• Events and callbacks for messages, PIN entry and online authorisation, so the application controls the user experience.
• Versioning, so applications and kernels can evolve without breaking each other.
• A matching hardware abstraction layer with defined services and behaviour, so a kernel certified on one platform can move to another with predictable effort.

Until such a standard exists, the practical answer is to build an abstraction layer yourself: one stable interface for your payment application, with adapters for each kernel and each terminal platform. Our upcoming EMV Level 2 Abstraction guidance covers how to design one.

Frequently asked questions

Doesn't EMVCo define how the kernel talks to the terminal?

It defines what information is exchanged and when, as logical signals and data. It does not define a programming interface that two vendors could implement identically.

Does Kernel 8 solve the problem?

Kernel 8 reduces the number of contactless kernels a terminal may need over time. It does not define an application API or a hardware abstraction layer, so each Kernel 8 implementation still comes with its own interface.

Would a standard API need to be certified?

The kernel behind it would still need Level 2 approval and the complete solution Level 3 testing. A standard interface would make those approvals easier to reuse, because the integration around the kernel would change less.

Who would benefit most?

Payment application developers, who could support more terminals with one integration; terminal makers, who could host kernels with less porting; and acquirers and merchants, who would get new kernels and features faster.