How Cloud Kernel Addresses Issues Payment Terminals Have Today

In the payment business today, EMV Level 2 kernel applications (contact and contactless) runs inside the POS device. In the initial times of POS devices and even after EMV devices were launched, the kernels worked pretty well on the device since there was not a heavy business logic on the terminal. However, with the increasing number of L2 kernels (i.e contactless and domestic kernels) and with the new requirements (like U.S Common Debit AID requirement), it started to be complex and costly to manage all these processes on the device.

Terminal vendors have been reluctant to the cloud kernel until recent times due to three main factors : network latency, security, and the uncertainty of the level 2 kernel certification process. However recently, many vendors started to think about this approach seriously. Payment schemes also support this idea and some of them work on some pilot projects to demonstrate how cloud kernel works well.

In this article, we will analyze five (5) main issues terminal vendors have today to manage the Level 2 kernel application on the device and how Cloud kernel addresses these issues :

1. High Cost of the EMV Level 2 Certification Process

L2 kernel certification is costly and time-consuming process which makes the ownership of a payment terminal costly too. In payment devices today, the L2 kernel certification is given restricted to the device hardware and operating system platform since the kernel completely runs on the device. The device hardware and operating system go to the certification process together with the kernel. When terminal vendor wants to have a new device with different hardware or operating system, then the vendor has to repeat the kernel certification process. This results in certification processes over and over again which burdens a big cost to terminal vendors.

2. Hardware Dependency

In the payment terminals today, Level 2 kernel application is strictly tied to the hardware and the operating system platform. The kernel runs only on the platforms where it is ported to. To run the kernel on another platform, the kernel should be ported to that platform as well and should go through all the L2 testing and certification process.

3. Difficulty of Managing Configuration Files

Although L2 kernels always remain the same in the device, configuration files change quite frequently due to changing payment regulations and rules and changing risk policies of acquirers and merchants. As every kernel must run with a configuration file, all payment terminals in the field should be upgraded with the new configuration file when configuration changes. Pushing configuration files to all the terminals at the same time has significant risks if configuration file is not tested well. Most of times full regression tests are required before pushing configuration files to the terminals. If there are significant changes in the configuration file, pushing process should be done gradually to reduce the risk. Generally, acquirers and terminal vendors define a ramp up strategy for the configuration file to be pushed to a certain set of terminals initially. After some period of monitoring and being sure that all goes well, the configuration file is pushed to remaining terminals.  These kinds of processes require pretty much time and effort for the terminal vendor.

4. Limited Transaction Data for Troubleshooting

Most of L2 kernel applications today don’t give enough details about the transaction to the outside of the kernel, which makes it difficult to figure out the problems in a payment transaction. Sometimes, a transaction may be rejected or terminated for some reason which might be related to a hardware, configuration, L2 kernel, payment application or another issue. It is very difficult to understand the reason of this until getting detailed transaction data such as APDUs and error information from the L2 kernel. Even though L2 kernel sends some of these data to the terminal application, this data must be sent to the cloud for storing, monitoring and reporting.

5. High Consumption of Secure Processor Memory

Today, payment devices in the United States generally have seven (7) L2 kernels running on the device : EMV contact, MasterCard contactless, Visa contactless, Amex contactless, Discover contactless, CUP contactless and JCB contactless. Every kernel comes with a bunch of configuration parameters which should be managed on the device too. These kernels and configuration files consume quite a lot of memory space in the secure processor. Unlike other applications, EMV level 2 kernel applications have to run on a secure processor, which is a different processor than main processor of the device. Secure processors have limited memory and processing abilities. Increasing the capacity of the secure processor means a new hardware design, new L1 and L2 certifications and higher cost of the secure processor. With the increasing number of contactless L2 kernels and additional requirements to store the data, POS vendors always need to seek new secure processors with more capacity.

Cloud Kernel

Cloud Kernel is the EMV and contactless L2 kernel applications running on the cloud rather than on the device. In the cloud architecture, payment device has a simple application only to manage user experience, to get user related transaction data (i.e transaction amount and PIN) and to read the user’s card data to process it in the cloud. The client application on the device communicates with the cloud securely to process a payment transaction. In the cloud architecture, more than 90% of the L2 kernel business logic is carried out in the cloud.

We will now discuss how Cloud Kernel addresses the five (5) issues explained in this document:

1. High Cost of EMV Level 2 Certification Process

In the cloud architecture, L2 certification is given to the L2 kernel application running on the cloud and the device together. On the device side, there is simple application managing mainly user experience (i.e amount entry, transaction type selection), secure PIN entry and secure card reading. Once the L2 kernel certification is given for the full cloud platform, certification of new devices is carried out only for the application running on the device. This is very simple certification process compared with the current process which requires full certification for new devices with new platform. This significantly speeds up the certification process and reduces the cost of the certification.

2. Hardware Dependency

It is very easy and cost effective to run the Cloud Kernel in a new hardware platform. In the cloud architecture more than 90% of L2 kernel operations are performed in the cloud and only remaining operations are device dependent. This gives the opportunity to the terminal vendor to easily port the kernel across different hardware and operating system platforms. Once the cloud L2 certification is given for a device, the same cloud can easily support different devices and even the mobile phones and tablets with a limited effort. Having a solution across hardware devices make it possible to manage and monitor all devices with the same platform.

3. Difficulty of Managing Configuration Files

In the cloud architecture, the configuration files are not pushed to terminals, but they are stored and managed on the cloud. When a parameter changes in the configuration file, it takes immediate effect for all or selected terminals. There is no need for additional processes like pushing files to terminals, monitoring terminals whether they work with the right configuration file and ramp up. Cloud architecture still requires regression tests and monitoring to make sure that the change in the configuration file doesn’t have any negative impact on payment transactions. However, it is very easy to scroll back to the previous configuration file in case of any unexpected situation.

4. Limited Transaction Data for Troubleshooting

In the cloud architecture, transaction data is processed in the cloud rather than the secure processor in the device. Secure processors have limited resources to store the transaction data and to take detailed logs about transaction errors. None of these limitations exist in the cloud architecture. Cloud architecture offers unlimited memory space and processing ability to perform these kinds of logics. The cloud kernel can provide detailed transaction data and detailed error logs for failing transactions. This data can be stored in the database for monitoring and reporting.

5. High Consumption of Secure Processor Memory

In the cloud architecture, secure processor is only needed for secure PIN entry processing and data encryption process if the device works with hardware-based security model. If the device works with software-based security model, then a secure processor is not needed at all, but a software method like White Box Cryptography or Trusted Execution Environment should be implemented on the device. Software-based security models are generally used in mobile phones or tablets where device doesn’t have a secure processor. As PIN processing and encryption process is pretty much the standard, there is no need to worry about replacing or increasing the capacity of the secure processor when new L2 kernels are required.

Challenges with Cloud Kernel

1. Transaction Latency

In Wi-fi environment, there is no need to worry about this since network is fast enough to process the transaction in the required time. In 3G network, there may be some transaction latency depending on the network speed.  However, with the 4G and 5G, this will not be an issue anymore. Terminal vendors need to have benchmark tests with cloud vendors to measure how much additional latency Cloud Kernel brings. The latency also highly depends on number of times the data goes back and forth between the client device and the cloud during a payment transaction. With a well-designed cloud architecture, this number would be reduced as much as possible.

2. Security

With the POS terminals having secure processor for PIN entry processing, and encryption of sensitive data, the security level remains the same for cloud kernel architecture. The data is sent from the device to the cloud as encrypted. With the HSM devices in the cloud, or with the software based encryption methods (i.e session keys), the data is decrypted in the cloud in a PCI environment, and the transaction is processed as per PCI and EMV rules.

For the mobile phones and tablets, White-Box-Cryptography or TEE (Trusted Execution Environment) provides the security requirements defined by PCI. PIN-On-Glass technology allows to accept the entry of the PIN of the user in a secure way. On the other side, solutions allow the cardholder to enter their PIN into the merchant’s own smartphone or tablet but also requires the merchant to have the hardware-based Secure Card Reader – PIN (SCRP) to capture the account data.

3. EMV Level 2 Certification Process

EMV Level 2 certification process has been another factor terminal vendors were worrying about because of the lack of kernel vendors having the cloud kernel certification. However, after the payment schemes started to support the cloud initiative now EMVCo and payment schemes have well-defined L2 kernel certification process for devices having different parts of the L2 kernel runs in different platforms (i.e some part of the kernel on the cloud and some part on the device).


With the all technological developments, better communication network speeds, well-defined certification processes and support of payment schemes, it might be right time for terminal vendors to define their cloud strategy. After the cloud-computing was launched by Amazon and Google in 2006, now it became part of our daily life for most of things. Now a new era might be starting where payment technologies go to cloud where payment devices become only a dumb device. The companies who adapt faster to the new era will have better chance to take the leadership in the market.