EMV Compliance: How to Become EMV Compliant

Nowadays, more and more merchants are becoming concerned with the problem of EMV standard implementation. These merchants are looking for the most suitable EMV solutions. The purpose of this particular article is to provide some guidelines, which will allow merchants to solve EMV compliance related problems.

The concept of EMV compliance is relevant for merchants, whose facilities are equipped with devices, needed for accepting of EMV payment cards. Depending on the size of a merchant (its transaction volume), its operations model, and industry type, several approaches can be used by the merchant to become EMV compliant.

Your EMV compliance implementation strategy will depend on particular payment terminal solutions, used by your business. Conceptually, there are three scenarios a merchant can follow to become EMV compliant.

EMV compliance for different merchant types

In this section we are going to consider several merchant types, starting from simpler ones, and moving on to more complicated models. Specific steps to be taken by the merchant on the way to EMV compliance will depend on the type of payment terminal solution this merchant uses.

Standalone terminal solution case

Let us consider a merchant business (say, a retail shop), which uses either no terminals, or a standalone terminal solution, provided by the MSP. The terminal is used as a standalone device, which accepts payments, and is not integrated with the POS system. After a payment is accepted by the terminal, it should be registered in the main POS system that is used as a primary system of record.

Consequently, the current solution can, potentially, be replaced by any similar standalone terminal of the same class, which supports EMV standard. So, in order to become EMV compliant, such a merchant should address its current MSP, and verify what EMV options are available (the simplest strategy for the merchant). If the current provider cannot offer any EMV options, the merchant can address other MSPs, which offer similar pricing conditions.

Integrated terminal solution case

Let us now consider the case, when the merchant (say, a large network) already uses some payment terminal solution, provided by the MSP, and the merchant’s POS system is already integrated with the existing payment terminal solution.

In this case it would be desirable for the merchant to resolve the issue of EMV compliance with its current MSP. However, if it is not possible, then the merchant has to search for an alternative solution, taking into account all the intricacies of potential new integration.

As the process of implementation of a new terminal solution involves integration of POS system with payment terminal(s), the merchant should devise the integration strategy in advance. As we wrote previously, the strategy involves several critical issues, such as:

  • Hardware to be used
  • Functions it should perform
  • Terminal fulfillment mechanism
  • Payment types to be handled
  • Required terminal solution types

A detailed description of EMV terminal solution implementation strategy is provided in the respective use case.

Proprietary terminal solution case

The third case concerns a merchant, which developed its own payment terminal software using its own development team. In contrast to the merchants, described in the first and second subsections, this merchant cannot use any other solutions from any MSPs, because it has its own application, supported by its own designated personnel. This application has to be certified by the merchant with the current processor.

In order to keep using its current terminal application, the business (merchant) needs to go through EMV certification process. As part of the EMV certification, the merchant will, most probably, have to perform the following steps:

  • address its current processor
  • buy the respective product
  • perform integration at server level
  • add the respective logic to the payment terminals
  • purchase EMV certification toolkit
  • go through EMV certification process, as described in the respective article

Conclusion

In order to achieve EMV compliance, you need to decide, which type of merchant your business belongs to. This will allow you to define the scale and the main phases of the process of becoming EMV compliant. If you follow all the necessary steps carefully, EMV compliance will open an opportunity for gaining new benefits.

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.

Payment Terminal Management Systems

The purpose of this article is to familiarize you with the features that a terminal management system needs to have in order for you to be able to rely on it. Payment terminal management systems are intended for different needs, which arise while operating the terminals.

These needs include:

  • re-injection (changing) of encryption keys;
  • remote update of parameters;
  • updates of the application, installed on the terminal,
  • other needs.

There are several options you can choose from if you need a terminal management system (TMS):

  • develop your own TMS
  • choose one of the existing systems and license it,
  • choose some other option.

There are many different TMSs that can be deployed on premises, or used as hosted solutions.

Regardless of whether you are going to build your terminal management system yourself, or prefer some other option, it is important to understand in detail some of the features that you will be looking for.

Functions of a terminal management system

A TMS must be able to perform the following functions.

  • Configure some parameters inside the terminal. For example, you have to define, which card types a terminal is going to accept, which application IDs (AIDs) will be accepted on EMV transactions, what the floor limits will be, etc.
  • Perform remote key injection (in some cases). There are some types of keys that can not be injected remotely, either because it is physically impossible, or, mostly, because of the regulations; however, there are some other encryption keys, which you definitely need to remotely inject. For example, while remote injection of PIN debit encryption keys is not a very popular practice, remote injection of CA (certification authority) public keys for EMV is used quite widely;
  • Perform remote updates. For example, from time to time you have to introduce changes into the software installed on your terminals (including applications, associated libraries, and underlying kernels on the remote terminals);
  • Collect statistical information from the terminals and generate appropriate reports or alerts. For example, if a terminal gets restarted too often, a software update fails, or some untypical situation occurs in terms of card types, offline approvals, etc. Statistical information also concerns the current condition of the terminal, availability of free disc space, memory, number of installed applications and libraries, current software version, etc.
  • Manage the terminal’s lifecycle. Ideally, it should manage the terminal from the point of order through fulfillment into final deployment to the merchant, activation, and subsequent processing. For example, it is important to identify when a terminal is activated at a fulfillment center, when it is shipped and deployed at a merchant’s location.
  • Remotely manage advertising materials, such as videos, image-based slide-shows, etc. For example, you may want to display different images and videos every month, depending on the promotions that are happening in the store. Regularly updated advertising content is, in fact, an instrument of targeted marketing.

Conclusion

A terminal management system is an essential component of any embedded payment terminal solution. If you choose to implement such a solution, you definitely have to analyze the functions you need your TMS to perform in the context of your business, and carefully select the solution which is optimal in terms of both budget and functionality.

Point-to-point Encryption

As new types of fraud emerge in the modern payment processing industry, the concept of point-to-point encryption (sometimes referred to as end-to-end encryption) becomes more and more relevant as an additional protection mechanism. The purpose of this article is to provide an overview of what the concept is and how it can be implemented in your payment system.

So, we are talking about an additional protection mechanism for the cardholder’s data, transmitted between the point of entry (usually, payment terminal) and the point of processing (usually, payment gateway or a processor). While SSL encryption is always used at the communication level, point-to-point encryption provides yet another protection layer to secure the information further (since under certain circumstances SSL communication can be compromised).

There is no consensus on the best encryption methodology or algorithm to use for this process. Some people choose to use symmetric encryption keys and triple-DES algorithm, as it is done for PIN encryption. Others choose to use asymmetric encryption keys and algorithms, such as PGP.

There are several reasons why people choose one algorithm over another. Sometimes, the choice is dictated by the performance of a particular encryption algorithm (limitations of the device), sometimes – by limitations of the HSM system used to eventually decrypt the data.

When choosing the algorithm that you want to use, you have to consider the requirements around your encryption process and requirements around your decryption process.

Decryption

The first thing is where and how the decryption algorithm is going to be implemented.

Decryption can be performed in one of the two ways: either using software, or using hardware (hardware security module (HSM), which is, basically, a hardware implementation of a particular decryption algorithm). It should be noted that only a solution with HSM can be certified as a PCI-compliant point-to-point solution.

The advantage of HSM solution is that the key is stored within the hardware device and never exposed to the outside world. Therefore, the device is capable of decrypting any value, without ever exposing the key, stored within it.

When a non-HSM solution is used, a decryption key is, generally, stored in some secure fashion. However, it has to be extracted from this location, and loaded into the memory of the server, executing the decryption code. Potentially, the key can be intercepted during this process, and, to prevent this, HSM solutions exist.

Encryption

The other fundamental thing to consider is: at which point the encryption is going to take place.

In the ideal world, the hardware that you use would encrypt the data at the point of card insertion, or at the point of swipe. However, there are a lot of terminals that do not have this capability.

The next obvious location to place your encryption logic would be within the terminal itself (as this reduces the path that unencrypted data has to travel, and it is more difficult to penetrate a terminal, than it is to hack a regular workstation). However, this approach can be used only in conjunction with an embedded terminal solution. Besides, embedded terminal developers are somewhat difficult to find.

On the other hand, there are many solutions today, which are not embedded, and which implement terminal-controlling logic outside of the terminal as a form of DLL library.
Consequently, unencrypted data has to travel between the terminal and the DLL library (usually, through a serial or USB port). At the same time, a piece of code running on a workstation is exposed to unencrypted card data, which might have additional PCI audit consequences.

Theoretically, you could still implement a decent point-to-point encryption solution, using this approach. However, you will, likely, have to go through separate PA-DSS certification of the code, handling the encryption of the card. The reason is because it is deployed into a merchant’s network that cannot be managed by security personnel of the payment company which provided the solution, and, therefore, cannot be covered by the PCI audit of the company.

It should be stressed that one of the key reasons why point-to-point encryption procedures are used and independently certified is that they enhance the security and reduce the possibility of problems, emerging on the merchant’s end. However, point-to-point solutions can also be separately PCI-certified as a solution, taking the merchant out of PCI scope. The premise is that encryption is performed at the point of swipe (or somewhere close to it) and decryption is only possible at the gateway or processor level, so that the software, that falls in between, has no ability to access card data in any way.

Point-to-point encryption and tokenization

An important thing to consider is that point-to-point encryption often comes in conjunction with tokenization. For straight retail businesses that only do one-time purchases (such as grocery stores and supermarkets) the storage of card data for repeat purchases may not be relevant, and, therefore, tokenization will not be required. However, many companies have use cases that require them to reuse cards at some point in the future for on-account purchasing or recurring billing. Health clubs provide a classical example.

In a traditional scenario, when an unencrypted swiper is used, the account number can be extracted from track data by any intermediary software components, including POS systems. However, when point-to-point encryption is used, the decryption capability, usually, resides somewhere at the very end of the “path”, i.e. either with a gateway, or with a processor, and, therefore, no intermediary parties have access to the card data. Because of that, they will, generally, expect some form of token to come back from the processor, associated with the card, allowing to use the card again for repeat purchases or recurring billing.

Conclusion

Point-to-point encryption is a useful practice, which may prove handy for your business, but it has a lot of important aspects associated with it, and each of these aspects must be carefully considered (particularly, from budgeting viewpoint) prior to implementation of some specific solution.

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

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.

Integrating Terminal Application into a Payment Ecosystem

If you are implementing your own terminal application or planning to integrate terminal applications into your payments ecosystem, you have to choose potential ways of interaction with payment terminals.

In our previous article we discussed the pros and cons of several payment terminal solution implementation options. Now we are going to analyze several approaches to integration of payment terminal applications into your payment ecosystem.

In essence, you can choose from among the two conceptually different approaches: standalone terminal use and integrated terminal use. The first approach allows the terminal to function on its own. The second approach envisions control of the terminal by point-of-sale (POS) application.

Standalone terminal use

You can often witness a classical example of standalone terminal use in many convenience stores. In such a store, after all the items you’ve picked are rung up at the POS, the cashier keys in the amount into the terminal and hands it over to you to complete the payment. In this case, the POS application has no interaction with the terminal.

When the terminal functions independently, in order to process a payment, you only have to input the payment amount. After that, the payment is made, while POS application, through which the sale was made, is not even “aware” of that.

As more and more commercial and open-source POS systems become available for various segments of businesses, the demand for standalone terminal offerings is gradually declining, because more and more businesses desire to have an integrated approach.

Integrated solution for terminal application

To integrate a POS system with a terminal, you have to connect the terminal to the workstation (on which the POS system is installed). Traditionally, POS was connected to the terminal through a serial port (presently – through a USB port). There are several ways of structuring interaction between POS and the terminal.

Fully integrated versus semi-integrated approaches

When it comes to integrated terminal solutions, there are two terms, that are commonly used to define the communication paradigm between POS and a terminal: semi-integrated and fully integrated.

Traditionally, all of the applications were fully integrated. In a fully integrated approach a terminal is used as a reader, obtaining card information, which is then consumed by the POS system, formatted into appropriate message, and sent to the gateway for processing. In a semi-integrated approach, the terminal is used as a standalone processing unit, which collects payment information, formats the appropriate message, and sends it to the gateway or processor for authorization.

Regardless of the communication approach used, there are several ways, in which the actual integration can be done.

Integration through an SDK

Traditionally, the terminal was managed through low-level libraries, allowing communication with serial/USB ports. In case of Windows these were the DLL libraries, provided by the manufacturer of the terminal (as we’ve mentioned in the previous article).

The advantage of the approach is that it is the most popular and widely spread one, as respective SDKs are available, and generic drivers such as uPOS, JavaPOS, etc, are available and supported by the existing POS systems.

Some payment solution providers see the advantage in the fact that most of the terminal behavior-controlling logic is located outside of the terminal, i.e. on the POS end, and, thus, in order to change the application’s “behavior”, no updates within the terminal are required. Consequently, you can reduce dependence on terminal management system (which is primarily used for remote terminal application updates).

The disadvantage of the approach is that it is not always suitable for web applications, which are not allowed to access to the low-level services of an operating system. While such applications can fall back on usage of ActiveX controls or Java Applets, these approaches present various security and deployment challenges.

Integration through a REST API

An alternative approach is to connect to the terminal through a REST API.

The advantage of the approach is that you do not have to deal with native code. Any application, capable of making web-service calls, can communicate with the terminal and control it.

The disadvantage of the approach is that all the logic driving the terminal’s behavior is, usually, deployed within the terminal as the terminal application. In this case, any enhancements of the application require updates within the terminal. Consequently, it is difficult to maintain such a configuration without involving a terminal management system of some sort.

Non-integrated approach

In some cases, the POS system does not need to control the terminal’s behavior at every step of the process. In such cases, POS developers prefer not to do integration with the terminal of any kind. However, you might still need the terminal to receive the information on the amount to be collected, while your POS system has to get the information about payments going through terminal.

In such cases you can utilize the so-called non-integrated approach.

When the POS system needs to process a transaction, it sends it to the gateway (without payment information included). Once a key on a terminal is pressed, the terminal connects to the gateway and checks if there are any pending transactions to be processed. It “sees” the transaction, that the POS sent previously, collects the payment information from the cardholder, and sends it to the gateway for processing. Once the gateway authorizes the transaction, it issues a call to the POS system, informing it that the original sale request has been fulfilled and the payment has been successfully made.

Naturally, the solution is available only for systems with a centralized processing server, such as web-based systems.

The advantage of this approach is that web-based systems can use the terminal without actually integrating with it.

Conclusion

Now that you have better understanding of payment terminal integration issues, you can decide, what terminal strategy is best for your business.

Implementing Your Own Payment Terminal Solution

If you are a player in the retail space, thinking that your business needs support for payment terminals, or if you are considering different payment terminal solutions in search of the most suitable one, this article is for you.

The need for customized payment terminal solutions is gaining urgency in view of approaching introduction of EMV standards and requirements in the US, scheduled for the end of 2015.

In this article we are going to consider several solutions, available for payment gateways and payment service providers with respect to their EMV strategy.

In essence, a terminal is a mini-computer with its own OS, where a terminal application has to function. Payment gateway must integrate with this terminal application to support EMV properly.

Payment solution offered by the acquirer

The first and, seemingly, the simplest solution is using payment terminal application, offered by an acquirer.

Many present-day acquirers offer you some form of payment terminal solution, which some PSPs or gateways may consider using. Upon closer inspection, however, you realize that there are a couple of issues with that.

One of the issues is that most payment terminal solutions (applications) offered by acquirers are tied directly to their platforms. Particularly, because of the tight EMV regulations, they avoid sending transactions from the terminal to some third-party gateway, intermediary CRM, or software system, which would then forward them to the acquirer. This may present a problem, because they need to keep track of these transactions to accommodate the business model of a PSP/gateway. The problem with the solution is that these transactions become invisible to the third-party gateway providers within their systems.

Because of that, many gateways and PSPs choose to integrate their software system with a terminal in a way which they can fully control.

Integration with a terminal

Integrating with a terminal can be done at two levels. At a higher level a PSP/gateway can utilize an existing terminal application and integrate with it using integration SDKs. At a lower level a proprietary embedded application can be written and subsequently integrated into the overall payment processing ecosystem.

SDK-based integration

The advantage of the first solution is that the SDK-based integration, usually, is much quicker than development of an embedded terminal application. Major payment terminal manufacturers (such as Ingenico, VeriFone, and PAX) offer their own terminal applications, which can be used in various ways, and thus, it is possible for payment gateways to take advantage of these applications.

While this solution is the simpler of the two, it has its disadvantages:

  • The gateway will not always be able to customize the terminal application (its interface or logic). For instance, you might be unable to add non-payment-related functionality, such as quality survey, to the application, when you need it.
  • SDK-based integration method may not be conceptually suitable for your application. Traditionally, platforms that used terminals, were desktop applications (only desktop applications existed). That is why many terminal integration SDKs still rely on the so-called native code, such as Windows-compiled DLL library. This imposes the requirement on the application to be able to deal with the native code. While this is, generally, not a problem for a desktop application, it does present a challenge for a web-application, which operates from within a sandbox, and, usually, does not have security privileges to operate at such a low level.

Embedded solution

The advantage of an embedded solution is that you can customize everything, and the application can do whatever you choose for it to do. You can develop an SDK or integration API, that will work for you, or your customers in any way, that you find appropriate.

On the other hand, this solution has a price tag attached to it, and is associated with some challenges:

  • Writing your own terminal application requires your own specialized knowledge, and a special costly certification, that has to be competed with the respective vendor in order to acquire preliminary knowledge and access to SDKs, allowing to do embedded development.
  • Building and testing the application, definitely, takes time. Therefore, immediate integration with the payment gateway solution is impossible.

In the next post we will describe some specific methods of integration and implementation of various SDK, allowing you to incorporate the terminal application into some software solution or payment ecosystem.