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?