The challenges of mobile EMV solutions

The purpose of this article is to familiarize the readers with the challenges of implementation of mobile EMV solutions. The article is primarily targeted at software companies, which are looking for effective approaches to integration of card-present solutions into their mobile applications. The article might also be of interest to payment gateway providers, trying to solve the problem of mobile EMV solutions for their clients.

Lately a lot of new mobile POS systems emerged, which were based on various kinds of card readers for smart phones and other mobile devices. For example, Square Readers represented one of the first available solutions, which allowed merchants to turn their cell phones into mobile POS systems.

We should stress, that the first mobile payment card readers scanned the data in an unencrypted format. In order to manipulate the reader, a native app has to be installed on the mobile device (i.e., the card reader cannot be controlled by a web-application from the web page). Consequently, a mobile card reader, that “touches” the unencrypted card data and communicates it to the mobile device, puts the whole mobile POS system within the PCI scope.

In order to better protect cardholder data and get the POS app out of PCI scope, several solutions are available. However, when EMV is involved, some of the solutions work better than the others.

Similarly to payment terminal solutions, mobile card-present solutions can be conceptually divided into three groups: integrated solutions, standalone solutions, and semi-integrated solutions. Let us address these solution types one by one.

Fully integrated solutions: EMV certification required

In pre-EMV world most companies used encrypted card readers, which encrypted card data at the moment of swipe and, thus, got the app out of PCI scope. If you apply the same methodology with EMV, there still remains a problem with EMV regulations.

The mobile POS app needs to be integrated with the payment gateway or payment processor, which is going to handle the payments. At the same time, it needs to be integrated with the EMV reader, which is going to scan the card data. If you integrate with the EMV reader, you have to go through EMV certification (using the EMV toolkit), because in this case, transaction path will go through the mobile application. Consequently, the mobile application is included into the EMV path, and it has to be re-certified every time when some change is introduced either by the gateway or by you (the POS app developer), as required by EMV regulations.

You also have to remember, that, in order to do initial certification, you have to understand the EMV certification process, buy an EMV toolkit, pay the developers, and spend a lot of time and money to complete the task. The whole EMV certification process might take three to six months.

In order to get the POS system out of the scope of EMV regulations, and, at the same time, protect the integrity of both EMV card and EMV kernel of the POS app, you can use either a standalone solution, or a semi-integrated one.

Standalone mobile EMV solutions

This solution implies the use a separate, “isolated” application for handling of payments (EMV payments included). For example, a software package, obtained from the payment gateway provider, can be installed on the merchant’s mobile device. This package is capable of performing basic payment operations. This solution is equivalent to a standalone payment terminal. The point is that the software package provided by the payment gateway is independent from the mobile POS system or app, and, at the same time, it is already EMV certified by the payment gateway.

In order to accept a payment, the merchant switches to the EMV-certified payment app, provided by the gateway, completes the payment, and then switches back to the POS app (mobile POS system), provided by the software vendor, to confirm this payment.

As we see, the POS app remains out of the EMV path.

Semi-integrated mobile EMV solutions

Another EMV mobile solution is a semi-integrated one. It is more flexible and provides somewhat greater control of the business logic than the standalone solution. However, this solution is more complicated, than the standalone one, because in order to implement its particular architecture, you need to get approvals from processors and associations.

In case of semi-integrated solution, you have to create an independent, autonomous component. SDK of this component should give your mobile POS system the opportunity to control the overall flow of business logic, but does not allow any interaction with the EMV kernel, or any control over payment processing workflow. The component itself is responsible for the transmission of the data to the payment gateway. It is also EMV certified on its own as embeddable solution. Therefore, other software packages that integrate this component into themselves, can rely on its EMV payment processing functionality, but remain out of EMV path (and out of PCI scope).

This solution is, in some way, a “gray area”. It imposes particular requirements on the architecture of the component. Architectural solution, allowing the component to keep the software package, that integrates with it, out of EMV regulations scope, will depend on the particular processor that you work with.


When you consider implementing your own mobile EMV solution, you need to keep in mind the needs of your existing (and, possibly, potential) customer base. Will you be able to get away with the standalone solution? Will it be better for you to offer your clients an integrated solution? If you want to go with a semi-integrated solution, be sure to approve your overall design with the EMV certification team of the underlying processor, before you embark on the actual implementation.

EMV Fallback Transaction

This article continues the series dedicated to EMV standard and EMV payment card processing. In it we are going to describe transaction fallback mechanism, its purpose, and types of EMV fallback transactions.

As we know, the general purpose of EMV technology is to increase the level of security and protection of cardholder data during the transaction. That is why it is always preferable to perform transactions when the card is equipped with a chip which is properly functioning. However, in some cases EMV transaction is impossible, in spite of the fact that the EMV chip is available.

For example, the payment terminal does not support chipped cards at all, or the slot, intended for reading of card chips is temporarily out of order.

Sometimes a chip cannot be read because it is damaged and the terminal cannot read the data from this chip.

For situations like these EMV standard provides the concept of EMV fallback transaction. If the data cannot be read from the chip, one can try to swipe the EMV card like an ordinary magnetic stripe card (swiped EMV fallback transaction). If the swipe doesn’t work either, it is possible to input the card number into the terminal manually (manual EMV fallback transaction).

It should be stressed, that EMV transaction fallback is an independent concept, and EMV card swipe cannot be viewed as an ordinary swipe transaction. This approach allows to prevent EMV terminals from being used for unintended purposes. That is, in theory, a fraudster could use a stolen EMV card with the terminal and try to swipe it or input its number manually (instead of scanning the chip, which might lead to detection of the fraudulent activity). However, EMV terminals are programmed in such a way that EMV card swipe cannot be attempted unless and attempt of reading the chip has already been made (although, technically, manual input of card number can still be attempted before the chip). This is implemented using a special service code, present in the track data. When a swipe is performed, the terminal analyzes that service code, it can block the swipe and display the message, requiring to insert the EMV card. If an attempt to insert an EMV chip has been detected, the terminal allows the operator to subsequently perform EMV fallback transaction. In this case, when the transaction is processed, a special flag is raised, indicating that it is a fallback, and that the initial attempt to read the chip was unsuccessful.


When implementing your EMV application, you need to take fallback mechanism into account. Although there are no strict requirements as to the order of fallbacks, it is recommended to develop protection mechanism, preventing the card from being swiped before the chip has been attempted. If the chip cannot be read, it is recommended to perform the swipe, and after that (if the swipe is unsuccessful) – try manual fallback.

If the payment terminal supports both contactless and contact EMV payments, these payment types should be “interchangeable” (if contact transaction is unsuccessful, conactless payment can be attempted and vice versa). If neither contact nor contacless payment comes through, swipe and manual fallback can be attempted.