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.