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.

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.

HSM, Tokenization Appliance, or Both?

As new encryption methods and technologies emerge and evolve, many companies and individuals have questions about specific features of different encryption solutions. In this article, we are going to explain the differences between hardware security modules (HSM) and tokenization appliances. There appears to be confusion in this topic, so we decided to explain what each of the two solutions is and clarify the situation.

An HSM is a physical computing device that safeguards and manages digital keys for strong authentication and provides crypto-processing.

In essence, the device stores the keys and implements certain algorithms for encryption and hashing. It can be used for these functions by external applications, such as payment gateway software.
Particularly, an HSM can be used for:

  • encryption and decryption of card numbers
  • decryption of card PINs
  • verification of card security code (at the back of the card)
  • verification of EMV cryptogram
  • other functions

As an HSM is capable of performing data encryption, particularly (using AES algorithm), many people assume that an HSM is equivalent to a tokenization appliance. However, it is not exactly so. Any tokenization appliance does use an HSM of some sort, but it implements some additional logic on top of it.

For instance, an HSM can encrypt a card number, and generate a token based on one way hashing algorithm. It only stores the encryption key and does not store the token and the encrypted value. Consequently, if a card needs to be processed later, and only the token is available, an HSM is unable to provide corresponding card data, because it doesn’t store all the necessary values within itself.

Another difference between an HSM and a tokenization appliance is that although an HSM stores the keys within itself, it does not control, which key is used to encrypt each value (generate an encrypted value) at a specific moment. Consequently, an HSM does not provide a complete mechanism for rotation of keys, which is required by PCI.

As for tokenization appliances, they can, generally, handle the following tasks.

  • A tokenization appliance has an API for interaction with an HSM.
  • It receives the card number, encrypts it using the HSM, and generate the token
  • It keeps track of the keys which are used for encryption and can rotate them with time
  • It stores the encrypted values and tokens
  • It can decrypt any value from the token (as it “knows” which key has been used to generate the value)

As we see, a tokenization appliance implements the so-called vault functionality, and uses an HSM for data encryption and decryption only. The correspondence between the token, encrypted value, and the key (or, to be exact, the key number), is the vault function, implemented in the tokenization appliance itself, and not in the HSM.

It should be understood, that just an HSM is not an immediate solution of tokenization requirement. If you need tokenization functionality, you need a tokenization appliance. If you need to implement such functions as P2PE, PIN processing, or card issuance, you need to use an HSM. If you need both categories of functions, you have several options to choose from.

  • You can purchase both a tokenization appliance and HSM if your budget allows
  • You can also purchase an HSM and license tokenization software that works with it
  • You can purchase an HSM and develop your own vault software on top of the HSM


Before you make an investment in either tokenization or HSM, be sure to understand your needs and based on the totality of your requirements, make an intelligent and informed decision.

EMV, P2PE, or both?

There is a lot of confusion on how EMV and point-to-point encryption (P2PE) work together and whether one can replace the other, and whether both technologies are necessary. While point-to-point encryption becomes more and more popular and EMV-related liability shift in the US is approaching, more and more questions, regarding both these payment processing aspects, arise.

The purpose of this particular article is to explain the benefits of each option taken separately.

In our previous post on point-to-point encryption we described P2PE as an additional security measure “on top of” EMV standard. However, in some cases, people and companies use point-to-point encryption as an alternative to EMV (which, as we explained here, is much more secure than a magnetic stripe).

Of course, if you want to feel more secure and support different card types, you’re better off incorporating both technologies within your solution.

Usage of EMV without point-to-point encryption is not recommended. Some modern businesses choose not to EMV standard and use P2PE only, in spite of the approaching liability shift deadline.

Let us illustrate the essence of the liability shift with a simple example.


A fraudulent transaction took place, during which EMV card was used. The transaction itself, however, was not an EMV transaction, as the merchant did not support EMV standard (did not have an EMV terminal). Consequently the card had to be swiped, and, as a result, the fraud occurred. According to the current rules, an examination would take place before the liable party is defined. However, after October 15, 2015, the liability would get assigned to the merchant, because it did not have EMV terminals.

As a result, businesses, where payment card fraud risk is higher (such as small convenience stores), prefer to use EMV terminals. On the other hand, businesses, where fraud risk is lower (such as large hotel networks, which verify and retain the copies of all the documents of the cardholder at the time of purchase), may be less “stressed out” by the approaching deadline.
They may choose to implement point-to-point encryption as the primary security measure.

For businesses that already have an existing encrypted swiper based point-to-point solution (and consider fraud a minor threat) investing in the new EMV terminals (and EMV certification) might be a challenge. That is why they choose to invest in liability insurances and stay away EMV for now.


The best option is to use both EMV and P2PE technologies. However, if you already have point-to-point encryption functionality, and, presently, you do not consider fraud your top-priority problem, it is not that critical for you to purchase EMV terminals, go through certification, and try to implement respective solution at all your facilities before the liability shift. So why not just make your shift towards EMV standard more gradual and smooth?

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.

Payment Gateways: Standard Features

The purpose of this article is to discuss standard features to be considered during payment gateway selection.

If this is the first time you are reading our “Selecting a Payment Gateway” mini-series, please, start with the Introduction to improve your understanding of this post.

While people tend to look at a credit card as an ordinary peace of plastic with a magnetic stripe on it, cards can be of different types and there are many different features about cards. Based on what current and future needs are, a merchant might want to choose a processor offering payment gateway software capable of supporting these features.

Card processing levels

When cards are processed they can qualify for one of the three different levels (for more information check this article ). Consequently, if a business needs, for instance, level III processing, it is necessary to ensure that it chooses a payment gateway supporting that particular feature.

Industry-specific features

Some merchants operate within a specific industry with its special requirements or regulations when it comes to credit card processing. Examples of such industries with respective specific features include restaurants (tips), lodging (incremental authorization), healthcare (support for HSA/FSA accounts). Naturally, these merchants should deal with a processor/payment gateway specializing in their industry and providing support for the required features.

Card present vs card-not-present

All transactions can be viewed as card-present (retail) or card-not-present (CNP) (direct marketing\e-commerce). While many payment gateways support both, it is common for payment gateways and processors to specialize in one of these two types. Therefore, it is important to analyse the needs of a business with respect to transaction types that it has to support.

A business should keep in mind that the following types of transactions are only possible within card-present environment:

  • PIN-debit,
  • electronic benefits transfer (EBT),
  • EMV (Europay/MasterCard/Visa standard for integrated circuit or “chipped” cards).

On the card-not-present side it is appropriate to mention such features as

  • PIN-less debit,
  • 3D secure,
  • online fraud prevention.

Gift cards and loyalty cards support

Other categories of cards that a business might consider supporting are gift cards and loyalty cards. Both types of cards are rapidly gaining popularity, especially in the US, and that is why they should also be taken into account. If a business might require (now or later) support for either gift cards or loyalty cards, the decision-makers should keep that in mind while making a choice.

Merchant’s perspective

In the initial article of this mini-series a health club has been chosen as a merchant example, because it requires support of a variety of credit cards and features for its operations. Due to high competitiveness of the business, a fitness club might need to be able to quickly adopt to the new industry trends, such as, for example, gift and loyalty cards.


To enhance customer experience and to improve member retention, a health club wishes to introduce a gift card program (a loyalty program). The program will enable people to get free personal trainings after a certain period of club membership or after they accumulate a certain number of points through purchases.
If the payment gateway the club is dealing with supports this feature, then the club’s tasks, as well as the whole reconciliation process, are considerably simplified. Otherwise, the club might need to deal with a separate processor (the one that supports gift cards) and reconciliation would involve two different companies.


It is desirable for a merchant to choose a payment gateway, supporting the broadest spectrum of cards and features, currently or potentially required by the business.

Reseller perspective

If a business’s goal is to resell merchant services, the rule is as follows. The more flexible and wide the spectrum of services is, the easier it is to offer and resell these services. Moreover, the ability to offer additional services, beside standard features supported by all other resellers, may provide a competitive advantage for a reseller.


Having conducted a research, a fitness software company realizes that a considerable number of purchases are made online. Consequently, there is a need for a brandable mobile payment application that the software company could use to enable its customers to accept online payments. Partnership with a payment gateway, featuring the built-in support for mobile payments, allows the fitness software company to
grant the service to the clients without any complications, as well as consolidate all types of transactions under a single account and greatly simplify the reconciliation process for the company and its respective merchants.


The more features are supported by the payment gateway, the easier the service sales process will be, and the more money can be charged for standard features (retail, e-commerce), because beside them, additional ones (gift card support etc) will be available.

Our next post will cover fraud protection support as a payment gateway selection criterion.