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.


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.

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.


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.

Payment Terminal Application Features

In this article we are going to provide a brief description of the common features of a payment terminal application. The features under consideration concern such aspects as payment processing, loyalty programs, management of agreements, and other, more advanced matters.

Let us describe each of these aspects, and respective payment terminal application features, one by one.

Payment Processing-related Features

  • ACH transaction handling – ability to handle bank account payments or capture bank account data for recurring payments. More detailed information on how ACH works can be found in our respective article.
  • Swipe/Manual – ability to handle magnetic stripe cards, as well as manual card entry for processing and recurring payments.
  • PIN Debit – ability to handle encrypted PINs when PIN-debit or EMV transactions are processed.
  • Contact EMV – ability to handle ICC (integrated circuit card) EMV payments. For contact EMV transactions an ICC (chip) is inserted into the terminal.
  • Contactless EMV – ability to handle contactless EMV payments. During contactless EMV payments it is enough to touch the terminal with a card (without inserting it). Check out our respective article on the benefits of EMV standard for more information.
  • Proximity – ability to handle RFID (radio frequency identification) cards and mobile payment systems like ApplePay or Google Wallet. For RFID card handling it is enough to put the card close to the terminal without inserting it.
  • Gift Cards – ability to handle closed loop gift cards, including activation, reloading and redemption. Closed loop cards are accepted only by the company, which issued them to its customers.
  • Offline Transactions – ability to handle transactions when no connection to the host is available (generally due to connectivity issues); exists in two flavors – store and forward (for non-EMV cards) and EMV offline handling.

Features Concerning Loyalty Programs

  • Cards – ability to handle non-payment magnetic cards for loyalty programs. Examples include cards for accumulation of points, bonuses, etc which can be later exchanged for some benefits
  • Phones/Tags – ability to use NFC (near field communication) enabled devices or NFC tags for non-payment operations (check-in, loyalty program, etc).

Features Concerning Agreements Management

These features are common for large-screened terminals, which have an ability to support different non-payment functions, particularly concerning customer agreements. Usually, these features concern interaction with a customer through dialogues and forms displayed on the terminal screen.

  • Custom Dialogs – ability to show custom prompt dialogs and capture customer’s selection.
  • Signature Capture – ability to capture signatures and initials.
  • Custom Forms – ability to present customized input forms to collect arbitrary data.

Features of a Stand Alone Offering

  • Regular Payments – ability to handle payments using terminal without POS (stand alone terminals).
  • Split Payments – ability to handle partial authorization. Partial authorization takes place, for instance, when a customer wants to pay with one of his cards, but gets an “insufficient funds” response, and makes the actual payment with another card.
  • Batch Management – ability to handle voids and settlements using terminal without POS. In terminal management context a batch means a series of transactions accumulated during the day.
  • Tip Management – ability to handle tip adjustments on pre-authorized transactions using terminal without POS.

Advanced Payment Terminal Application Features

  • Tokenization – in addition to standard payment processing functionality, tokenization allows capturing of payment information for its subsequent reuse as part of the recurring billing process. It is often necessary to avoid manual entry of payment information for tokenization purposes. For more information on tokenization, see our respective article
  • P2PE – ability to encrypt PAN data from the point of capture (terminal) all the way to the point of processing (either at the gateway or processor level). While P2PE without formal PCI certification does not provide out-of-scope status for merchants using it, it significantly reduces possible exposure of cardholder’s data. Usage of P2PE methodology imposes additional key injection procedures. For more information on P2PE, see our respective article
  • Advertising – ability to show customized media content (image slideshows or video) on terminal’s screen in idle mode (when terminal is not used for a specific operation). Targeted deliver of marketing content provides additional value to the terminal offering and helps justify costs associated with hardware acquisition.
  • TMS – ability to connect and communicate with terminal management system for remote configuration and updates. While the feature is not required for solutions with local footprint where DLLs are distributed as part of the main application (desktop thick clients), it is necessary for embedded system.
  • Donations – ability to accept donations or surcharges as ‘add-ons’ to primary application payments.


When you make a decision concerning implementation of some terminal solution, make sure that you think through the payment terminal application features that you are going to need, and that they are available in the solution of your choice.

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.


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.


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.


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.