January 28, 2025

Key Considerations for Selecting an EMV Level 2 Stack

Key Considerations for Selecting an EMV Level 2 Stack

In-store payment software architectures integrate a crucial component needed to process the most secure payment cards currently issued by financial institutions: the EMV1 Level 2 stack. The introduction of Commercial Off-The-Shelf (COTS2) devices has led to a proliferation of EMV Level 2 options, posing various challenges across the industry.

Historically, payment terminal manufacturers have developed, or acquired, EMV Level 2 stacks to integrate into their physically secured PCI-PTS3 products. Recently, some of these manufacturers expanded their offerings with COTS solutions that integrate an EMV Level 2 stack through specific APIs, often as part of strategic acquisitions or adaptations to evolving market demands. This evolution resulted in product complexities, additional costs and risks for organizations, alongside the duplication of software or maintenance tools. On their side, start-ups, in their drive to innovate, crafted SoftPOS solutions for COTS with limited EMV expertise, frequently opting for free EMV Level 2 Kernels (SDKs) from some payment networks, yet restricted stacks to accelerate their projects. While this approach aligns with immediate timelines, it poses long-term challenges concerning scalability, especially under the growth-driven aims of venture capital investments. Finally, Original Equipment Manufacturers (OEMs) have recognized the SoftPOS opportunity, seeing potential in EMV Level 2 cloud solutions, particularly because PCI-PTS & EMV Level 1 certifications are not needed for COTS devices. Nonetheless, recent deployments of SoftPOS solutions on consumer smartphones highlight the negative user experiences (maturity, NFC performance, tap experience), suggesting that this niche market is in its early stages with ample room for enhancement and innovation. 

In the evolving landscape of in-store payment systems, developing a robust software architecture is crucial to maintain competitiveness and functionality over the next decade or more. Central to this architecture is the strategic decision regarding the implementation, outsourcing, or maintenance of an EMV Level 2 stack - a critical component in payment processing. This paper outlines the essential questions on a modern EMV Level 2 stack to guide organizations in making informed decisions. 

What is an EMV Level 2 stack? 

An EMV Level 2 stack refers to the software responsible for accepting chip/NFC card transactions, and lies between the payment terminal and the bank's systems, usually running at the Point Of Interaction4 (POI). It is composed of a common Entry Point module and multiple kernels (one per payment network or scheme). You need as many kernels as schemes you wish to support for card acceptance. Typically, 5 or 6. It is paramount to accept transactions that adhere to the global payment card standard: EMVCo, and regional schemes. 

What is the expertise required to develop or integrate an EMV Level 2 stack?

It requires staff between 5 and 10 people, and up to 12 months to realize a first certifiable version, including 2 kernels and a testing tool. Today, there are around 20 Level 2 kernel specifications that can be certified. All are not mandatory, depending on the markets you target... If you choose to outsource that component, different providers propose agnostic solutions, some are free, provided by the payment networks, but careful due diligence should be led. An EMV Level 2 stack must ensure seamless extensions with various kernels as needed for international deployments, without necessitating substantial efforts, and risks. Also, the complexity inherent to EMV Level 2 stack integration onto your payment application should be sufficiently abstracted so that your team doesn’t have to delve deeply into Level 2 specifications to understand the necessary configurations and flow implementations. By design, a stack should support all kernels (international and regional) so it is not required to tweak card detection (to avoid compromising performance of kernel activation), and a single EMV data model should be used to simplify its integration with a payment application. Depending on your strategy, you may also consider purchasing official tools used by the labs to run actual certification sessions. 

What are your test and certification strategies? 

EMV Level 2 testing is both time-intensive and costly. Ideally, all EMV Level 2 stacks should support automated testing, independent of hardware constraints. While certification tools are crucial for obtaining accreditations, they are unadapted for fully automating a kernel implementation during the development phase. A well-designed stack prioritizes testability as much as certifiability. Consequently, development teams can focus more on qualification rather than certification. Moreover, top-tier stacks in the market come with comprehensive tools, examples, and documentation, enabling integrators to develop payment applications with complete autonomy. 

How to assess an EMV Level 2 stack security? 

The EMVCo and payment network terminal Level 2 specifications do not cover security requirements beyond Offline Data Authentication (ODA). EMV transactions performed at a POI can rely on a secure token from the issuing counterpart, such as a card or mobile phone. Hence, an EMV Level 2 stack is not subject to PCI scrutiny in contrast to its operating environment. Nonetheless, the stack does handle sensitive information from the issuing counterpart to perform ODA or other processes as per the specifications. These requirements indirectly would subject any EMV Level 2 stack to PCI scope. Since most EMV Level 2 implementations operate on PCI-PTS devices, the associated risk is minimal.

However, with the rise of COTS architectures, it becomes crucial to evaluate how an EMV Level 2 stack manages this situation. In particular, for 2 reasons: a) PCI-MPoC security mainly focuses on attestation and monitoring - the back office side, with mitigation measures being limited in this context; b) Many existing EMV Level 2 stacks used in COTS devices have been designed for PCI-PTS terminals. 

What are the use cases you target? 

EMV Level 2 stacks can be certified with various options via an Implementation Conformance Statement (ICS) to align with merchants' specific needs. However, selecting more options isn't always advantageous, as it can increase the overall costs associated with development, maintenance, and certification when unnecessary features are included. Performance should also be a key consideration, particularly for use cases requiring rapid card detection, seamless kernel activation, and swift processing of PAN/token captures, such as in open payment systems. Hence, an ideal stack should support both cloud and embedded architectures, providing customers the flexibility to select the optimal physical architecture based on their operational constraints. Essentially, the logical architecture of an EMV Level 2 stack should efficiently accommodate diverse use cases with minimal effort needed for adapting physical interfaces. 

What is the scale of your market? 

Scalability is arguably one of the most challenging aspects to address in a software project. It is essential to consider scalability from the project's inception. An EMV Level 2 stack should inherently be designed to accommodate various regional EMV Level 2 specifications (such as Interac in Canada, Girocard in Germany, and eftpos in Australia), as well as meet diverse acquirer security requirements and application architectures (client/server, thin client, standalone), thereby enabling global deployment. The EMV Level 2 stack should utilize a standardized API and a unified Entry Point for all kernels, which will streamline scalability and ensure compatibility with regional payment acceptance markets. 

How does your timeline impact your choice? 

In the short term, some startups have opted for off-the-shelf EMV Level 2 stacks to quickly incorporate a minimal set of kernels for developing MVPs. However, for a project to succeed in the long term, it is crucial to consider the EMV stack's ability to evolve and be maintained. Historically, our industry's technologies tend to span approximately a decade. The 2000s witnessed the advent of EMV contact, and in the 2010s, the rise of contactless technologies challenged existing stacks. We are likely entering a new phase characterized by cloud infrastructures, enhanced software security, and EMVCo-C8 specifications. That’s why EMV Level 2 stacks must be versatile enough to adapt their structures and data models along the time without compromising your investments for the next 10 years. 

Which EMV Level 2 stack fits your project?

Over the past decade, the EMV card acceptance industry has undergone significant innovation, with developments such as EMV contactless, mobile point-of-sale (mPOS) solutions, Customer Off-The-Shelf (COTS) solutions, EMV kernels in the cloud, ... Existing EMV Level 2 stacks have been adapted, or new solutions released, to seize regional and vertical market opportunities. Despite these changes, the EMV standard has remained global and interoperable, independent of the specific businesses, geographical locations, and hardware platforms in use. But surprisingly, no standard EMV API has emerged to normalize how card processing is integrated across different hardware architectures. A modern EMV Level 2 stack should propose the same encapsulation between PCI-PTS and COTS systems, embedded and cloud architectures, in order to accommodate various business scenarios, supporting the dynamic nature of the in-store payment marketplace.

1 See https://www.emvco.com/

2 See https://listings.pcisecuritystandards.org/assessors_and_solutions/cpoc_solutions?agree=true 3 See 

https://listings.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices?agree=true 4 See https://www.nexo-standards.org/standards/nexo-fast-specification