What the EMV kernel does
Everything in that flow has to be driven by something, and that something is the EMV kernel. In EMV kernel development, the kernel is the software component that runs the transaction logic at the point of interaction and sits between the terminal application and the acquirer. When EMVCo describes Level 2 testing, it's evaluating exactly this: the kernel that performs EMV processing for compliance with the chip specifications.
The structure is where teams get surprised. A common Level 2 stack has a shared entry point plus one kernel per scheme. Historically, each card network maintained its own contactless kernel, which is why one industry breakdown lists separate Level 2 certifications for Mastercard and Visa contactless; American Express has its own path as well. Supporting several card brands has meant integrating and certifying several kernels, each with its own quirks.
That picture is changing, and it changes your options. In October 2022, EMVCo published the C-8 Contactless Kernel Specification, a single unified kernel meant to eventually replace the scheme-specific ones so a terminal can be certified once and meet requirements across brands. The C-8 kernel also supports cloud operations, so processing can be split across locations for mobile point-of-sale and TapToMobile setups. Ingenico obtained the first EMVCo C-8 approval on its AXIUM DX8000 device, and the new kernel runs on existing hardware, so it coexists with older kernels during the transition. When you decide whether to license a kernel or build your own during emv kernel development, this is the map you're navigating.
Certifying your EMV POS software
Building EMV POS software is only half the job. Before you go live, you clear a certification path, and the levels matter because they test different things. EMV Level 1 covers the physical and electrical interface between the reader and the card. Level 2 evaluates the kernel and its transaction logic. Level 3, the brand or scheme certification, validates the whole thing end to end against a specific acquirer and host.
Level 3 is what trips teams up. It confirms your terminal configuration works with a particular acquirer and gateway, with the required host message formats covered through real scenarios like approvals and declines. It does not test whether your product is well designed or whether it handles every card in the field gracefully. Certification proves conformance to a defined set of test cases, while edge cases outside those cases are still your problem.
The cost and timeline surprise comes from multiplication. Because each acquirer has its own configuration requirements, multiple networks require repeated certification cycles. And the process is slow by nature. The U.S. Payments Forum notes that "end-to-end testing currently can take weeks"; scheduling and acquirer reviews add calendar time on top of the test cases themselves, and network and receipt reviews add more. One consultancy estimates the full Level 3 effort will take up to two years or more when specialists design and run tests for each terminal and region, with each business handled separately. Worse, even minor software changes can trigger partial recertification, because an update can introduce issues that require retesting. If you're building a plan you've never scoped before, this is the line item that decides whether your launch date is real.
Where EMV projects go wrong
The failure points in EMV kernel development are consistent, and they compound. The first is the certification queue itself. Test labs handling Level 3 face backlogs from high demand, and those scheduling delays push project deadlines back regardless of how clean your code is. You can be ready and still wait.
The second is inconsistent requirements across networks. What passes for one acquirer fails for another, so you end up adjusting configurations and writing additional test cases per network. The third is interoperability. A terminal that reads one card or works with one issuer can fail on another, because EMV has enough optional behavior and edge cases that real-world cards expose gaps a lab script missed. Teams new to payments underestimate all three because none of them look like software bugs. They look like process, and process doesn't show up in a code review.
Here's why this is more than a scheduling headache. Correct implementation is a fraud and liability question. Since the October 1, 2015 liability shift, responsibility for counterfeit card-present fraud falls on whichever party isn't EMV-compliant. Deploy an uncertified or flawed terminal running EMV POS software and you push fraud liability onto the merchant using your product. The stakes are real because the technology works when it's done right. Merchants using chip-enabled terminals saw an 80% drop in counterfeit fraud between 2015 and 2018, and roughly 95% of card-present transactions globally now use EMV chip technology, according to EMVCo's data as of December 2023. A terminal that flunks its checks exposes your customers.
Getting it right with a partner
Correct EMV POS software implementation is what stands between your product and fraud exposure, while failed certifications keep the launch date moving. Everything above points to one honest conclusion: the EMV flow and the certification gauntlet demand expertise that's scarce and slow to grow. Building a team that knows EMV kernel development and chip card processing from the inside is expensive, and hiring for certification expertise is hard.
So weigh the build-versus-partner decision on real terms. If your core product isn't payments, spending a year and a half learning certification the hard way is a steep price. EGS has done this EMV kernel development work before, across flow design and kernel integration, with scheme certification cycles that stall most teams. If you want to pressure-test your project scope against people who've shipped EMV POS software, book a call with EGS and get an honest read before you commit the timeline.
