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.

Handling Interac Payments in Canada

With this article we continue the series of articles related to EMV standard and EMV certifications. The purpose of this particular article is to describe the peculiarities of integrations with Canadian payment service providers.

Any integration with a payment processing partner in Canada requires integration with Interac Association, which is a non-profit inter-bank debit network, connecting multiple financial entities in Canada. In principle, the process of integration with Interac is similar to integrations with other associations, such as Visa and MasterCard (or integrations with debit networks in the US). However, there are certain requirements, which distinguish integrations with Interac from those done with other associations. The difference lies in the supplemental mechanisms imposed by Interac Association members on processing of card-present and card-not-present transactions.

Let us outline these additional requirements.

Processing of card present transactions by Interac Association

When it comes to processing of card-present payments (both EMV and swipe) by Interac merchants, the distinguishing feature is the transaction validation mechanism. This mechanism involves additional data protection level. To provide this protection, an additional block of data is generated during transaction verification. This block is called message authentication code or MAC.

MAC block of data represents an encrypted line of values. These values are: transaction ID, transaction amount, merchant ID, and terminal ID. For encryption of the data block, including these values, a special key is used, called the session key. It should be stressed, that the session key is a separate value, unrelated to card PINs or P2PE keys. The session key is stored in the terminal memory and has to be updated (rotated) after a fixed number of transactions is processed. MAC values cannot be calculated at POS/gateway level, as they depend on particular terminal hardware.

Encrypted MAC block is used as a kind of digital signature/seal, which is used by the payment processor to ensure that the rest of the message arrived unaltered. When the message is received by the processor, it uses MAC block as well as values provided in the message to verify the integrity of the message. The response, generated by the processor and sent to the terminal, also includes an additional encrypted MAC block of data, which has to be decrypted and validated by the terminal. The terminal must send back confirmation of receipt of unaltered response message.

As we see, MAC ensures the control of transaction integrity. We should remind that MAC is a mechanism, specific for Interac, and intended only for protection of debit (both EMV and swiped) card data.

Processing of card-not-present transactions by Interac Association

When it comes to processing of card-not-present transactions, some (but not all) Interac Association members use an additional data protection mechanism, which is, in a way, similar to 3D secure capabilities, used by Visa and MasterCard.

More or less detailed information on how 3D secure works can be found in the respective Paylosophy article. Here we’d like to remind, that 3D secure protection mechanism redirects the cardholder from the shopping cart application to the bank’s web-site, where he is required to input some additional confirmation of his identity (usually, some confirmation code or password).

Some Canadian providers are using a special online service, similar to 3D secure. A cardholder, paying for products or services online with his debit card, is automatically redirected to the web-site of the aforementioned online service, where he is required to input additional information, confirming his identity.


If you are planning your first integration in Canada, it is important to understand, that, even if you have the experience of conducting integrations in the US, in Canada your integrations will be a bit more complicated, due to additional Interac logic. Particularly, this means that an EMV payment application, developed in the US, would still require quite significant adjustments to be able to support Interac in Canada, because Interac, in its turn, requires the special logic, depending on specific terminal hardware. If you are ordering test terminals to do your integrations, make sure, that they are injected not only with a PIN key, but with the MAC key, needed for integration with Interac.

EMV payment terminal cloud demystified

In our previous articles we mentioned embedded payment terminal solutions, however the concept of payment terminal cloud is still an innovative one. The purpose of this article is to describe a new conceptual approach for embedded solutions, a technology called NIO (non-blocking input/output or non-blocking i/o). The technology allows to create a kind of a payment terminal cloud, that can be manipulated.

The majority of traditional non-embedded solutions, and many embedded solutions as well, are based on the assumption that the POS communicates directly with the terminal (i.e. sends all the messages directly to the terminal).

As we explained in the respective article this communication can be organized through a serial/USB port, or through the local IP of the terminal (using Ethernet cable). However, with the emergence and development of NIO technology, it became possible to use an alternative approach, where the POS does not actually have to ever communicate directly to the terminal.

The concept is very similar to many chat programs. When two people want to chat with each other, their chat client software (remote clients) subscribes to the centralized chat server. When the first person types a message, it is sent to the server and delivered to the chat client of the second person, subscribed to receive messages. The response is delivered back to the first person in the same way.

A similar mechanism can be used to control the work of a terminal. Particularly, a terminal, when initialized, can open a channel for communication with the server and keep it open (persistent connection), so that it can receive any notifications, which are addressed to it. On the other hand, a POS system can also get connected to the server and send commands to the terminal, which is already connected to this server. When multiple terminals get connected to the server in the way described above, a so-called “terminal cloud” is formed. Many terminals are maintaining connection with the server. Once the POS gets connected to the cloud, it can send messages to any connected terminal through the channel, maintained by this terminal.

Formerly, the solution was hard to implement, especially for large number of terminals, as support of multiple persistent TCP connections required too many resources. Presently, NIO technology, which can be built into a terminal and initialized on a server, allows this server to support thousands of open connections without requiring significant resources from the server.

The advantage of the approach is that it allows for usage of the same integration concept for card present and card-not-present transactions. In both cases a POS system sends messages to the server (or payment gateway) in the same way, while in traditional systems card-present and card-not-present transactions represent two different data flows (card-present transactions are, traditionally, handled through integration with the terminal, while card-not-present ones are sent to the gateway).

Another advantage concerns simplification in terms of PCI compliance. The terminal communicates with the gateway, and thus, POS remains completely out of scope, because it neither touches card data, nor communicates directly with the terminal.


If you are a provider of a web-application, or a mobile application, which needs to manage terminals without any local footprint (.dll libraries), or if you use OS, for which there are no available terminal adapters of terminal integration libraries, you need to search for a terminal solution, which is based on payment terminal cloud approach.
If you are a developer of payment terminal solutions, you can utilize payment terminal cloud concept. It makes your solution more promising, as it becomes acceptable for a broader spectrum of potential customers.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic

Contactless Payments Demystified

There is a certain confusion regarding such concepts as EMV contactless payments and magnetic stripe contactless payments (sometimes called proximity payments). Both these concepts denote contactless payments (also called near-field contact or NFC payments), allowing to process card data once the card is placed within the magnetic field of the terminal. Similar NFC technologies are used in both cases.

General info on contactless payments

Contactless technology originally started emerging in the United States with MasterCard PayPass, Visa payWave. Initially, contactless payment technology was an extension of ordinary card-swipe technology. When a card touches the payment terminal, slightly altered track data is communicated to the terminal.

Contactless magnetic stripe payments have approximately the same security level as ordinary card swipes. The only difference is the construction of the card itself, which has to include the necessary components for NFC.

Examples of magnetic stripe contactless payment systems include Google Wallet and Apple Pay. In these systems card data (replaced by a token due to security and PCI compliance considerations) is injected into a mobile device. At some point during processing, the token, which is read off the phone, is detokenized through Apple/Google servers and converted into the actual account number for subsequent processing.

EMV (in contrast to magnetic stripe) contactless payment is an EMV transaction, during which a group of EMV tags is communicated to the terminal (similarly to the case of EMV contact transactions).

Limitations of EMV contactless payments

Due to the nature of contactless payments, there are certain limitations, which distinguish contactless payments from contact payments. These limitations are related to security and technology related issues. Let us take a closer look at the specified limitations.

Amount limitation

EMV contactless cards and payments are often used in scenarios, which require swift completion of the transaction. Consequently, contactless payments are often conducted without verification of either signatures or PINs (although both options are possible in contactless transactions). That is why, when application parameters for EMV are configured, a maximum amount of a contactless transaction is established (according to the needs of the business).

No issuer script processing

In some instances issuer may want to send some information back to the chip on the card (a common feature in the contact EMV). While EMV contactless standard does make provision for the second “tap” (or touch), it is often assumed that there is going to be just one tap. Consequently, in most cases, it will be impossible to send the issuer script back to the card as part of contactless transaction.

Automated application selection

We should remind that an ordinary magnetic stripe contains only the information about the card, its expiration date, and the cardholder’s name, which can be read by the terminal and used at some further stage of the process. In contrast to a magnetic stripe, an EMV chip contains special applications. Through these applications the card interacts with the payment terminal (in contrast to magnetic stripe card). In some cases there might be several specialized applications, recorded on a chip (for instance, applications for debit networks, for Visa processing in the US, or for processing of Visa International). Depending on transaction type and merchant type, the terminal chooses the most suitable application, the application is activated and used for information exchange between the terminal and the card. In some cases there can be several applications suitable for specific situations. In case of contact EMV the selection can be made by the cardholder. However, in contactless situation the selection very often happens automatically by default.

Some applications can be intended for card payments at petrol stations, while others can be intended for card usage in specific countries of the world. Common debit application IDs (AIDs) are intended for working through PIN-less debit networks. MasterCard brand AIDs are intended for international payment processing (for cases when a debit network cannot be accessed).

In case of contact payment the cardholder can select an application, which is most suitable for him. In case of a contactless card payment the cardholder might not have such an opportunity. As application selection is performed automatically, it becomes of great importance for merchant to properly configure automated selection process to choose the application, which is most suitable for a particular business context in terms of eventual processing cost.


Contactless technology provides convenient means of payment, allowing cardholders and merchants to save time. However, this technology often complicates the process of certification. As a result, before you decide, whether you want to accept contactless payment cards or not, you have to verify whether the limitations of the technology will have any negative consequences for your business, and whether it will be problematic to invest time and efforts, needed for implementation of contactless technology in addition to contact payment processing. Also remember, that for some businesses (and, possibly, for your business as well) it might be appropriate to completely switch to contactless payments and give up contact EMV payments, and there are numerous models of terminals that can only accept contactless payments, and they are cheaper than terminals which can do both; if you switch to contactless payments only, certification process will, again, become simpler for you.

Terminal Solution Components

This year support of EMV standard becomes a mandatory component of payment systems of US-based businesses. Consequently, more and more merchants ask themselves how they are going to implement their terminal solutions in view of the need EMV support.

The purpose of this article is to describe the components of a modern terminal solution in order to help those who are trying to define their strategy of payment terminal usage. The subject is especially relevant for large-size merchants and payment facilitators, who have to deal with a large number of terminal deployments.

A modern terminal solution has to incorporate three key modules, which will address three aspects:

  • Fulfillment management – for ordering, injection, and operation of terminals
  • Terminal application – for transaction processing
  • Terminal support and management system (TMS) – for configuration and updates of terminal applications

Let us address each of these aspects in detail.

Payment Terminal Fulfillment

During fulfillment process the merchant orders a certain number of terminals of specific models with specific injection keys, while the respective fulfillment center (which works directly with the manufacturer) handles the order and supplies the terminals to specific locations (points of sale).

In many cases large payment facilitators and gateways have to work with more than one terminal fulfillment center. The reasons are as follows. First, a fulfillment center may be out of stock for a particular terminal model, so you have to order this model from some other supplier. Second, not every fulfillment center can inject every processor’s key (usually, fulfillment centers have agreements with limited numbers of processors). This is particularly difficult when processing crosses borders, because fulfillment centers tend to specialize within a specific country of operation. Consequently, companies, dealing with merchants in different countries, or doing international processing, may require special tools to manage the entire process and ensure that proper terminals with appropriate keys are ordered from appropriate suppliers.

Another important fulfillment-related issue is injection of third-party keys. It should be noted that lately implementation of end-to-end encryption solutions has become a common practice. In these solutions, PAN data is encrypted with a key. Most payment facilitators and payment gateways prefer to use their own encryption keys. However, not all providers of fulfillment services are equipped to handle the third-party key injection. In order to have the right to inject third-party keys, a company needs to be equipped with special procedures and have special certifications. Beside that, a special agreement is needed by a company to be authorized to inject encryption keys on behalf of a specific third party.

When you consider your terminal solution, all these issues need to be taken into account (even if not all of them are will be handled by your in-house system).

Terminal application

There are several terminal manufacturers and numerous terminal models. Similarly, there are many different terminal solutions. However, from a global perspective, all terminal solutions can be divided into two categories.

  • Terminal applications which have local footprint
  • Terminal applications with no local footprint

A terminal application “with a local footprint” requires installation of some special components on a workstation it is connected to. Usually, these components are DLL libraries, which represent one of the most common approaches nowadays.

A terminal application “with no local footprint” does not require installation of any native libraries or drivers on a workstation that is going to manage the terminal.

The second solution is, naturally, the preferable one, as it allows you to access the terminal and work with it in a unified manner from different web or desktop applications, under different operating systems, using different mobile devices (such as smart-phones and tablets\pads).

Terminal management system

Once the terminals are deployed, they need to be supported and maintained. In this regard several issues need to be addressed.

First, a terminal may break. Some plan of action must be developed for a case when something goes wrong with a terminal (i.e. how the malfunctioning terminal is going to be replaced).

Second, from time to time the terminal logic might need to be updated. Both embedded terminal content and DLL applications have to be updated from time to time.

Finally, the advertisement content of the terminal needs to be updated as well.

A terminal management system must be capable of supporting all the listed functions and updates.


We’ve presented a brief overview of a terminal solution at the high level. In our subsequent installments we are going to address specific terminal solution components and aspects in greater detail. We encourage you to study the topic carefully before making decisions about your preferred terminal solution strategies. In our future articles we will cover more related topics.

EMV Certification in a Nutshell

The purpose of this article is to familiarize integrators with EMV processing, help merchants understand the process of EMV certification and estimate its cost.

The relevance of EMV certification

EMV stands for Europay, Mastercard and Visa, and denotes a worldwide transaction authentication standard. The standard is based on usage of integrated circuit cards, which increases the security of EMV card transactions in comparison to magnetic stripe cards. More information on EMV standards can be found here.

From January 1, 2005, merchants in EU area are held liable for all fraud resulting from transactions processed in the systems, which do not support EMV. In the US, EMV certification also became an extremely relevant issue after the associations declared that the liability will be placed on merchants at the end of 2015, i.e. if a person wants to make a purchase from a merchant, using the EMV card, but the merchant doesn’t have an EMV terminal, and the transaction ends up being part of fraudulent activity, it is the merchant who is going to be held financially responsible for the incident’s consequences.

Although many merchants can purchase EMV terminals from the acquirers and do not necessarily need to conduct the in-depth analysis of EMV certification process, gateways, payment facilitators, as well as companies, that maintain their own proprietary payments ecosystems, have to face the question of how to undergo EMV certification, i.e., how to add EMV support into feature sets of their products.

Let us move on and review the EMV certification process in greater detail.

EMV certification phases

Before starting an EMV certification, a company needs to make a decision about the three key components of the process:

  • Terminal(s) (hardware device) that will be used to read EMV cards. Some information on payment terminals can be found in our respective article
  • Payment gateway software or some form of software package that will deliver transactions to the acquirer
  • Acquirer(s), that will process the transactions

After these decisions are made, the company can proceed with the EMV certification, that is, generally, comprised of two sub-certification processes (phases): host integration and EMV certification.

Payment processing host integration

Generally, there are no certification fees involved in this phase, and the main cost is the cost of development of the integration code. It involves integration on the message level between your system and the acquirer. As part of this integration, a proper message format is implemented to enable a payment gateway to submit EMV fields to acquirer’s system in a format that it can “understand”. In a sense, the process is similar to classical integration, described in the respective article.

EMV certification

It is a process, in which an EMV terminal (a terminal, supporting EMV card processing) and a so-called EMV toolkit are used. Special test scripts, certified by the acquirer for every association, have to be executed with the help of the EMV toolkit. The results of execution of the test scripts are submitted to the acquirer to be considered for review. The acquirer forwards the results to the associations for their final approval.
Usually, EMV certification involves an administrative fee (charged by acquirers), ranging between $2,000 and $3,000 for every formal test script run. Re-certification process has to be initiated every time when a new hardware device, using a different EMV kernel is added to the previously certified EMV-processing pad.

For example if any VeriFone mx9 series device has been previously certified, any other device of a kind is automatically covered by that certification. But in order to use some Ingenico device, you would have to initiate another EMV certification (even if you are going to utilize the existing host integration and the same back end).
The most popular EMV toolkits include ICC and B2 toolkits. Particularly, these toolkits are quite popular among acquirers in the US.

Selecting a device

The list of all desired devices to be supported needs to be compiled in advance and included into the initial certification. While selecting the devices, one should understand that only terminals and readers, which have EMV level 1 and level 2 certified kernels, can be used.

An EMV toolkit works as both card reader and card writer: it both reads data from the chip and writes new data on it to be read during subsequent transactions.

Developing terminal application

As we’ve mentioned above, firstly, a business wanting to process EMV transactions, needs to select payment terminal, supporting EMV and certified by the acquirer.
Secondly, the integration needs to understand that most terminal manufacturers will not provide a stock payment processing application with the terminal. In this sense, a terminal is similar to a PC with just an operating system installed, without any applications. It is the integrator’s responsibility to procure (develop or license) a terminal payment application, compatible with the hardware and the operating systems of the models of the terminals that it wants to support.

There are various ways to simplify the development process: it can be outsourced, or some existing applications can be purchased; but, generally, it has to be accounted for in the budget for the project.

For deployment and management of the terminals, software updates, remote configuration management a separate software package is used, which is, generally, called, terminal management software.

This terminal application has to be able to utilize required peripheral devices, such as card readers, signature capture etc., and accommodate whatever types of transactions that are going to be required (credit cards, debit cards, gift cards, EBT, etc.).

Most large terminal manufacturers (such as VeryFone) maintain their own payment gateways. A business can purchase a terminal with the manufacturer’s application on it, which is, generally, “tied” to the manufacturer’s gateway. Therefore, if a business wants to connect such EMV terminal to a different gateway, it, generally, has to undertake some software development.

Selecting acquirers to partner with

A business, planning to integrate with several acquirers, needs to understand that each acquirer requires a separate EMV certification for each country, in which the business is going to process.

An average cost of EMV toolkit (which is used in every EMV certification) ranges from $10,000 to $30,000 per user license. That is why, when the acquirer is selected, it is advised to consider the models of the toolkit that the acquirer supports, so that potential cost savings can be realized by going with specific acquirers and toolkit vendors (by using a single toolkit for two or more certifications across different acquirers). And if you are already in possession of a certain toolkit, it never hurts to ask the acquirer explicitly, whether they would accept the tests using your version of the toolkit.


If you are a business considering the idea of going through EMV certification process, you need to select the devices you are going to use, payment gateway and acquirers you are going to partner with; also you need to decide how to get or develop terminal applications. And, of course, you need to carefully plan respective budgets.