Implementation of EMV Payment Terminal Solution

Introduction

Many companies at the modern merchant services market are looking for an optimal card-present solution to implement. Some of these companies are expanding or re-organizing their activities (a step, which often leads to the need to choose and implement a payment terminal solution). Others are newcomers, which want to accept both card-present and card-not-present payments.

Problem

A company is looking for a universal card-present solution to implement. Either it can be a new solution, which is to replace an old one, or it can be the first card-present solution to be implemented by the company.

Context

The problem is relevant for several categories of businesses:

  • existing companies which already have a card-present solution in place, but want to replace it with a better one (possibly, in response to EMV liability shift)
  • existing companies, which previously dealt only with card-not-present transactions
  • startups that require card-present solutions
  • Strategy

    In order to implement a card present solution in the most reasonable and adequate way, your company needs to take the following important aspects into account.

    What hardware should be used in the new payment terminal solution? Which payment terminals are to be used? What functions should they be capable of performing?

    In order to answer these questions, you should analyze your business situation, the needs of the merchants you are going to service, as well as the price these merchants are willing to pay for the new terminals.

    For example, you might need the cheapest monochrome screen terminals or high-end 7-inch touch-screen ones with the most advanced functionality for your particular case.

    Keep in mind, that payment terminal market is an oligopoly, i.e., it includes only few large vendors, so your choice may be limited. Beside that, most companies’ offers may be quite similar.

    Do you need mobile solutions?

    Some companies offer solutions for both payment terminals and mobile POS systems. Maybe, it might be advantageous for you to deal with such a universal vendor, rather than to involve different vendors for different kinds of solutions.

    Which payment types do you need to handle?

    Do you need EMV contact and EMV contactless payments or are you going to deal only with encrypted swipe payments?

    Do you need standalone or integrated payment terminal solutions?

    Remember, that a payment terminal is just a hardware unit and different kinds of software can be installed on it. While terminal manufacturers (such as Ingenico and VeriFone) offer their own terminal applications, alternative payment terminal solutions are also available from third parties. Such third-party software products may be more suitable for your particular situation, than the software, developed by the terminal vendors themselves (for which you need to pay separately anyway).

    Depending on the type of payment terminal solution that you need (standalone or integrated), you need to evaluate the available software options according to the following three criteria:

    • Quality of user interface. I.e. how the software looks, works, and performs its intended functions inside the terminal (button sizes and colors, supported languages etc.).
    • Ability of the terminal application to communicate with the payment gateway. Some vendors offer terminal applications which are “strategically tied” only to their partner gateways. The question is, thus, whether the terminal application, that you are going to use, is already (or can be) connected to the payment system you need to interact with. You should also avoid situations when in order to deal with different processors you have to use different types of payment terminals and terminal applications, as the process may become too complicated to manage. In other words, your terminal application must be able to smoothly communicate with all back-end payment systems you need.
    • Ease of integration of a payment terminal with the POS system. Many companies still offer legacy integration strategies, which require either installation of DLL libraries or Windows service on the workstation. Both these solutions present deployment challenges, especially, for web-based applications. Beside legacy strategies there are other available options, such as cloud solutions (offered, for instance, by UniPay Gateway).

    As you can see, your choice of a particular terminal solution will not depend so much on the physical hardware and its price, as on the availability of your preferred terminal application on particular terminal models, or on support of a particular payment gateway by the terminal application you want to choose. For example, if your bank or payment gateway tells you that you can only use Ingenico, it makes no difference if you find Verifone more suitable for your business.

    Fulfillment strategies

    One of the most important aspects to consider is payment terminal fulfillment. I.e., who will be loading the new terminals and shipping them to your merchants. There are several options possible.

    You can buy a batch of (say, a 1000) terminals from a vendor or manufacturer, and then use an internal team to inject the respective keys and terminal applications into them as they are shipped to merchants (in smaller quantities). This process requires a whole infrastructure. Although this option is plausible for some companies, most businesses choose to delegate terminal fulfillment to special entities. Consequently, you can partner with a fulfillment center that will install software applications on the terminals, service the terminals, and handle terminal replacement.

    When choosing a fulfillment center, you should consider the following issues:

    • what it costs to buy a new terminal or replace an existing one; what the shipping rates are
    • which software applications (custom software packages) can be loaded
    • which terminal models it supports
    • with which processors it has agreements for PIN key injection (as it needs to be able to inject respective encryption keys), and in which countries
    • if you need some particular terminal application to be installed on your terminals, you should check with the fulfillment center, if it is able to install this application for you.

    When you find a fulfillment center, which is suitable for you in terms of pricing and servicing conditions, and a terminal application, which supports the payment gateway you are (or are going to be) partnering with, your choice of payment terminal solutions may become very limited.

    Example

    You have done a market research and realized that your options include Ingenico iSC 250/480 or VeriFone MX 915/925. However, in order for your terminals to be able to interact with your payment gateway, you need a special terminal application. Only two fulfillment centers are able to install this particular application, and only one of them deals with the three processors, whose keys you need to inject. This fulfillment center supports only Ingenico terminals. In this situation there is no point in some in-depth analysis of specifications and price offerings of VeriFone, as Ingenico turns out to be your only choice.

    EMV certification (if necessary)

    If you need to support EMV standard and keep using your own payment platform, you will need to integrate your terminal solution into an existing payment ecosystem (i.e. integrate your terminals with an existing gateway). This means that you need to go through EMV certification process.

    Remember, that each EMV kernel, installed on devices, which you are using within your solution, must be separately EMV-certified. Consequently, in order to simplify EMV certification process, you need to minimize the number of EMV-kernels on your devices (including EMV-kernels provided by one and the same manufacturer/vendor).

    Example

    A company wants to work with a certain number of models of terminals and mobile devices. Some mobile devices are using the EMV kernel which is used by payment terminals, while other mobile devices are using a different EMV kernel. (For instance, Ingenico uses both its own mobile solutions and solutions, developed by ROAMpay before its acquisition by Ingenico). In this case the company has to certify two EMV kernels, i.e. go through two certifications.

    In order to minimize the number of EMV kernels and, thus, reduce time and cost of EMV certification process, you need to verify, whether all the devices you are going to use, are made by the same manufacturer, and whether one and the same EMV kernel is installed on all the models of these devices.

    Conclusion

    Many newcomers in the merchant services industry erroneously think that selection of a card present solution starts with the analysis of available hardware options. Selection of hardware, in fact, may be the last phase of the process. You should, definitely, know the names of the key hardware brands. However, a decision, based only on hardware specifications, may result in a costly error. The key factors to be considered first and foremost often include terminal application compatibility, support of the necessary gateway integrations, number of necessary EMV certifications (if they are needed), and preferable fulfillment strategies

Payment Terminal Fulfillment Process

In our previous articles we addressed different types of payment terminal solutions. If you decide to utilize an embedded terminal solution, then one of the key questions you have to address is how to implement fulfillment of the terminals, which is going to involve proper key injection into the brand-new (or factory-unlocked) terminals, and how to do the initial software load.

The classical arrangement of fulfillment process is as follows. A contract is signed with a reseller of payment terminals. The reseller (fulfillment company) is going install the necessary applications, inject encryption keys, and ship the terminals to the merchants. Some fulfillment companies also can do servicing of the terminals, as well as provide support and take inbound customer calls.

When you select a payment terminal fulfillment partner, it is important to keep several points in mind. First, your partner should be capable of installing the applications you need, including the ones you’ve developed yourself. Second, your partner needs to be able to inject the keys for the processors you need (in those countries you need to be processing). This second aspect is particularly important when you are working with multiple acquirers and in multiple countries.

When you think through your payment terminal fulfillment mechanism, we highly recommend you to map out the following processes (and how they will occur).

  • Initial order. How is the payment terminal order going to be captured from a merchant? Who will capture the order (you or fulfillment center)? If it is you, how is it going to be placed in the fulfillment center? (The merchants can place the order on your web-site, so that you will forward the order to a fulfillment centre, or they can directly address the fulfillment centre themselves). How will the appropriate terminals be set up within your gateway and/or terminal management system (TMS)?
  • Modification of orders. A merchant ordered three terminals of a certain model and then decided that he needed an extra terminal. Or, maybe, he decided that one of the terminals had to be of a different model. Appropriate procedures must be developed for the cases, when an order has not been sent for fulfillment yet, as well as for the cases when the order has already been submitted for fulfillment (or even has been shipped).
  • Cancellation of orders. Procedures, similar to the abovementioned order modification scenarios must be developed.
  • Return of terminals. A terminal can have some defects, or a merchant can terminate his partnership with a respective payment service provider. In both cases, the terminal has to be returned. Respective procedures for return or exchange of the terminals must be implemented. A re-stocking strategy must also be in place, as the returned terminals (previously rented by some merchant) might be re-purposed elsewhere.
  • Maintenance issues. If merchants experience technical problems with a terminal, there needs to be a service they can contact. Respective support procedures should be thought through.
  • Stock shortages. You should also consider your strategy for potential stock shortages. The two most common approaches are as follows. First, you can pre-purchase terminals of certain models in advance. For example, you may purchase 500 terminals from a fulfillment center, and when only 50 of them are left in stock, you automatically order the next 500. Second, you can sign agreements with several fulfillment centers and maintain some stock with each.

Conclusion

If you are a provider of embedded terminal solutions, you need to pay particular attention to your payment terminal fulfillment process, and make sure that it is tailored for your needs or needs of your merchants, and those of your embedded solution.

Embedded Payment Terminal Solutions

Traditionally, payment terminals were connected to workstations through RS 232 serial ports. As technologies evolved, this connectivity method was replaced with USB connection. Until recently most payment terminal solutions were developed based on an assumption that a terminal was an additional device, which was, in many cases, relying on the internet connection of the workstation.

With further evolution, a terminal got its own Ethernet port and wireless connectivity. In essence, it became a stand alone mini-computer. This allowed to turn it into a server. Consequently, it became possible to treat it as a remote server, and not as a peripheral device.

In this article we are going to compare payment terminal solutions, described above, outline their advantages and disadvantages, and try to explain, when each solution should be used.

Now let us address the two solutions (payment terminal as an attached peripheral device, a.k.a. “local footprint” solution versus payment terminal as a remote server, a.k.a. embedded solution) in greater detail.

In the first case workstation (particularly, POS application) communicates with the terminal through direct wire connection (over serial/USB port). In the second case the workstation (POS application) communicates with the terminal (connected to a local network) remotely, using a local IP-address. A local footprint is required only in the first case.

Payment terminal solutions with local footprint

The advantages of the first solution are as follows.

  • It is industry accepted. The history of solutions with terminal as a slave spans over several decades, as, historically, this was the first solution to be developed.
  • It is more accessible in the market. Due to high availability of such solutions, more fulfillment centers are able to deliver pre-built terminals with complete terminal applications. As these solutions are often based on standard components already installed on the terminal, every terminal has more or less standardized configuration. If you try to install your own solution, you have to change it.

The disadvantages of the solution are as follows.

  • The local footprint. Some terminal-controlling software code (local footprint) has to be installed on the workstation. Card data may go through this software code. As a result, installation of such a solution in remote networks of merchants may require PA-DSS certification of the product, installed on the workstations.
  • Limitations on P2PE. The logic controlling the terminal behavior is placed outside the terminal. It uses some standard components, which are necessary to perform all other operations. These components manage the terminal “in general” (basically, read a card swipe), without any specific use cases. All such use cases must be handled outside the terminal, so card data will have to go through an external application. Consequently, truly “point-to-point” encryption is not always possible, as external controlling logic has to access card data.
  • Maintenance issues. The local footprint (a.k.a. payment terminal adapter) has to be maintained and updated. Maintenance activities are determined by the operation system, installed on the workstation.
  • Overall dependence on the operation system.

Embedded solution: terminal as server

The advantages of this solution are as follows.

  • Accessibility. Embedded terminal solution can function without a local footprint, which makes it accessible to different types of clients. These include mobile clients that will not require any special native logic to handle the terminal. A mobile device can connect to the terminal through its local IP-address, using a router. Consequently, the terminal can be controlled using a mobile device with a browser.
  • Simplified flow. As the terminal has its own internet connection, it can directly communicate with the gateway. This makes communication more simple and transparent from PCI audit viewpoint, because card data never gets to the workstation.
  • Cross-platform nature. The solution does not depend on the operating system of the workstation, as any client can manage it through HTTPs calls.
  • P2PE. As a result of simplified flow (see above), communication between the payment terminal and payment gateway is direct. Consequently, the data can be encrypted inside the terminal and decrypted by the payment gateway.

The disadvantages of the solution are as follows.

  • Fulfillment and injection. The solution requires specialized software loaded in the terminal, while usage of P2PE technology also requires additional key injections. This limits options when it comes to fulfillment and maintenance as not every terminal fulfillment center is equipped or certified to carry out required operations.
  • Need for Ethernet connection. Ethernet connection is needed to enable the terminal to interact with the payment gateway.
  • Remote updates. As local workstations have no drivers or any kind of software to deliver updates to the terminal, remote updating logic is necessary within the terminal to deliver configuration and software updates. Generally, a terminal management system must be used in such cases.

Conclusion

If you are making a choice between an embedded and non-embedded payment terminal solution, you need to keep in mind all advantages and disadvantages of each of the two options, and analyze both solutions from budgeting viewpoint in the context of your business.

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.

Conclusion

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.