Over the years, EMVCo has developed a process for the management of multiple operating systems (O/S), which allows an EMV Level 2 Kernel to be approved for use with multiple different O/S provided the change of O/S does not require re-compilation of the Kernel.

This process requires that the EMV Kernel is submitted for certification testing with each O/S, and a considerable number of the EMVCo test cases are repeated for each of the O/S, increasing the time and cost of the approval process. In contrast, Kernels written in Java are exempt from that process, as EMVCo considers that Java provides a fully platform-independent abstraction that can therefore be guaranteed to run identically on each O/S.

This leads to the strange situation that an EMV Level 2 Kernel, developed to run in Windows XP and Windows 7, is required to follow the EMVCo multi-O/S process if it uses the standard Windows API but does not need to do so if it uses Java – even though both solutions are running on the same combinations of O/S and are using standard interfaces!

This seems even stranger when considering that the parts of an EMV transaction that are more platform-dependent – such as the host connections, user interfaces and payment application – are all outside the scope of EMV level 2. Existing acquirer and card scheme processes already require additional integration testing to be performed prior to the final deployment of any EMV solution, and those should be sufficient to validate that any change of O/S has not had an adverse effect on the operation of that system.

Based on this knowledge, it would be easy to conclude that the existing requirements of the EMVCo multi-O/S process are arbitrary, unnecessary and unfair – maybe in the future EMVCo will re-assess this and adapt a more consistent approach?

Traditionally, most card payment terminals have used purpose-built hardware and software, running an embedded operating system for reasons of cost and performance. Over the years however the market has gradually evolved and many payment terminals now use general purpose platforms that support Java.

When developing EmvJ – the platform-independent EMV Level 2 Kernel that runs on any Java Virtual Machine – CreditCall wanted to harness the full potential of Java. Thus EmvJ is not only a very powerful and versatile kernel but has also been highly optimised for both performance and size, making it ideal for use on any payment device – whether it’s an ATM, an unattended kiosk or an EFT PoS (Point-of-Sale) terminal.

A major focus during the development of EmvJ was to provide an EMV Kernel that could easily be integrated into a card payment application. This enables EMV novices to quickly achieve an EMV-compliant transaction using EmvJ with only a few lines of code, and also provides advanced features to customise the kernel to support specific EMV Level 2 or card scheme-specific functionality appropriate to a particular solution.

The EmvJ Kernel was also designed to allow any PIN-pad and card reader components to be added without recompilation of the Kernel, by providing the drivers for those in separate Java packages. This can provide significant savings when undertaking the EMVCo Level 2 approval processes if multiple configurations and PIN Pads need to be supported. Drivers are already available for popular PIN Pads and EMV Level 1 approved card readers, including those from Ingenico, Verifone, Gemalto, Magtek and Sankyo.

CreditCall’s family of EMV Kernels are maintained to the very latest EMV Level 2 and industry standards, so you can be certain that they provide the best EMV solutions both now and in the future. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.