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.
Conclusion
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.
Recommended to you
