HSM, Tokenization Appliance, or Both?

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

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

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

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

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

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

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

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

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

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

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

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


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

EMV, P2PE, or both?

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

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

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

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

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

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


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

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

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


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

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.