EMV Parameters and EMV Keys Rotation

The purpose of this article is to explain why EMV parameters and EMV keys rotation are an essential component of EMV certification process.

The general assumption is EMV certification process includes just two basic stages: host certification and terminal certification. Respective information can be found in our respective articles here and here. However, there is another process which is also required to ensure normal functioning of EMV processing logic.

Somehow this third process is often neglected and many developers realize its importance at late stages of EMV functionality implementation. This can lead to considerable shifts of implementation deadlines. In this article we are trying to explain the essence of the process and help those who need to implement it when the time comes. The issue is particularly relevant for those who want to support more than one acquirer.

In order for EMV kernel logic embedded in payment terminal software to function properly, it needs a set of EMV application parameters and certificate authority (CA) keys. The CA keys are involved in the interaction between the EMV kernel of the terminal and the chip.

Quite often (for example, in Verifone and Ingenico terminals) the EMV kernel is going to use XML configuration file. The file includes the information on application IDs (AID), which are going to be supported by the terminal, respective parameters and keys for these AIDs.

EMV parameters are not changed very often (if changed at all). Most processors provide these parameters in pdf format. Usually, a pdf file is a contextual document, where they can be found. On their basis an XML file can be assembled.

Importance of EMV keys rotation: EMV certification perspective

In contrast to parameters, CA keys have to be changed (rotated) regularly. Most processors usually provide some sort of API (as a rule, it is a part of the main processing specification), including a subset of functions, dedicated to loading of the CA keys. Some processors will provide the initial set of keys through a document and require you to load updated keys using the API. Some processors will tell you initially to get all the keys by making a respective API call. Therefore, it is important to allocate time and resources for the implementation of this logic from the very beginning of your project planning, because there is no equivalent for this in card-not-present integrations or swipe integrations.

As we can see, in addition to host integration and terminal integration (with subsequent certifications), you also have to implement the rotation procedure for CA keys. Some of the processors will leave it up to you to implement this and will not require you to formally certify the process. Some of the processors (such as Chase Paymentech) will actually require you to demonstrate (during the certification process) that you can dynamically change the keys as transactions are getting processed.

Generally, the functionality around key rotations is appropriate for payment terminal management systems (TMS), and the function will be available in the TMS that you use. However, if you are not using any TMS, or TMS is unavailable for you, you can implement the respective logic as part of payment gateway functionality. The implementation process will depend on the number of different processors that you support and on the differences between application parameters (such as floor limit) across payment terminals. Implementation can be as simple as a file download from a server over FTP, where the file gets re-generated every time you get a different set of keys from the processor. It can be as complex as an API call where terminal identifies itself and then terminal-specific configuration file is assembled based on the most up-to-date information available from the processor that this terminal uses.

Conclusion

It is extremely important to allocate the time and resources for implementation of EMV keys rotation logic even for the most basic EMV certification. Even if you are not required to present the logic at certification stage, you are definitely going to confront the issue during production. While expiration period for a some of the keys can be up to 24 months, you will not necessarily have all that time before the initial key rotation has to be done.

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 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.

Conclusion

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.

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.