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 Gateway Monitoring

This installment continues a mini-series of articles, dedicated to the insights of payment gateway development. We continue to review different aspects, allowing to improve the efficiency of a payment gateway performance and the overall quality of its service.

Payment processing in today’s world has become a necessary service for increasing numbers of emerging online businesses. One of the critical payment gateway quality factors is availability of the gateway 24/7.

However, issues occur from time to time, and the best thing you can do is to be aware of these issues as early as possible to be able to take action swiftly, minimizing potential downtime.

There are two strategies that we recommend when it comes to potential issue detection.

Internal audit of payment gateways

The first mechanism is the internal audit mechanism (self-diagnosing system). This mechanism is “responsible” for detecting any functional problems or errors within the system. Detection of errors can be performed in one of two ways: either through analysis for errors of logs, generated by different components of the system (in special log files or database tables), or through active health checks of various services (this can be accomplished by executing a kind of ping operation on every particular service to verify that it is functioning without errors). If any problems or errors are detected, the internal audit subsystem can notify the administrators about them (using e-mail alerts, SMS etc).

Transaction velocity tracking in payment gateways

In some situations a problem may occur not within the system, but either somewhere along communication channels or on the customer’s end. Instead of pushing the responsibility to other entities, most payment gateway systems try to resolve or at least detect the reason of such a problem. Consequently, a need for a special detection mechanism arises. The mechanism has to detect the situations when transaction flow from a particular client is interrupted, or changes its typical behavioral pattern.

The approach used for detection of such situations is called “transaction velocity tracking”. The idea is to monitor transaction volumes usually received from a particular client during a certain period of time.

Example

About a hundred transactions are usually processed through a particular MID within a 30-minute interval, but at some point this number suddenly falls below that level. Respective notifications are sent to administrators. Naturally, some of the notifications will be “false alarms”, however, close monitoring of incoming transaction volumes allows to detect serious malfunctions on the merchant’s end (POS system or e-commerce web-site).

Before you develop specific velocity tracking mechanism, you should define which criteria you are going to use to track the transaction volumes, i.e. how you are going to quantify them. While tracking by MID can seem the most obvious approach, sometimes it is not the best one. In many cases instead of tracking specific MIDs it might be more relevant to track specific integrations. Say, if a gateway is integrated with ten different POS systems, it might be appropriate to track each of them as opposed to their individual merchants.

MID-level tracking is more relevant for desktop applications and individual payment terminals. However if you are dealing with a web-application with a centralized server, which uses the same credentials for processing transactions on behalf of hundreds of merchants, tracking by MID is not justifiable. In such cases, it is better to introduce the notion into the gateway, represented by this integrated software package, and then track velocity based on that.

Obviously, the two mechanisms become absolutely critical to the payment gateway, and any malfunction in these mechanisms can cause significant impact. In order to ensure proper functioning of these audit mechanisms, an additional audit service might be required on top of them. This extra layer would allow some external monitoring services, such as Pingdom or Nagios, to do health verifications on the internal audit and velocity tracking mechanisms. Health verification system is going to ping the payment gateway every 5 minutes or so, verifying that the entire gateway system is functional and operational; as part of the process it will verify that audit and velocity tracking systems are functioning properly. While this mechanism is also not a bullet-proof one, it significantly reduces the possibility of something going wrong and you not knowing about it.

Conclusion

The architecture, described above, is suitable for large-scale enterprise systems. If you are dealing with a smaller-size payment system, you do not actually need such a high level of complexity. However, make sure that you do make some provisions, similar to the ones, we’ve mentioned, before you actually go live.

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

PSPs, Payment Facilitators, and Aggregators

Depending on particular region of the world, the terms payment service provider (PSP), payment facilitator, and payment aggregator can denote different concepts and have slightly different meanings, i.e. one and the same type of entity can be called in a different way. However, globally, the three different concepts do exist, no matter how you might call them.

The purpose of this article is to explain the difference between the three crucial concepts, defining the three types of important merchant services industry players. Let us now provide a more detailed explanation of the differences.

Payment Service Providers

A payment service provider (PSP) is an organization, which provides individual merchant accounts to its merchants (i.e. provides traditional merchant services). Such a company works with a group of merchants, however it, generally, does not participate in the process of merchant funding.

A PSP facilitates merchant underwriting and payment processing, but merchant funding is, generally, done directly by the acquirer. Subsequently, a payment service provider can derive certain residual revenue only from the processing fees collected by the acquirer.

Payment Facilitators and Aggregators

A payment facilitator is similar to a PSP, but in contrast to a PSP, a payment facilitator does fund the merchants directly. However, the entities which conduct sub-merchant funding can be further subdivided into two groups.

The first group includes classical payment facilitators. In this case each business (merchant) is treated as a sub-merchant of the payment facilitator. This means that there is a separate MID, that is issued for each merchant involved in processing.

The second group includes the so-called aggregators. In case of an aggregator the same MID is used for every sub-merchant.

Examples

An example of a payment service provider is any independent sales organization (ISO). ISOs and resellers of merchant services can serve as examples of merchant service providers. Almost every bank nowadays has a department dealing with merchant services.A restaurant software (gym software, club management software, or any POS software) company is an example of a classical payment facilitator. Each restaurant using the software can get the merchant account through the POS development company. In this case the payment facilitator (being the software and financial services company) is going to review the account, collect the proper information from the customer and register it as a sub-merchant in their payment facilitator’s portfolio.

Another example includes such companies as lodging services (for instance, Airbnb) or marketplaces. A person renting accommodation through Airbnb does not have his own MID. A general aggregate MID is used for the whole service. The aggregator funds the apartment owners, and ensures that appropriate payments are deposited to respective apartment owners’ accounts.

One of the principal differences between payment facilitators and aggregators is the size of businesses (merchants) the two types of entities are dealing with. Payment facilitator model is suitable and effective in cases when the sub-merchant in question is a medium- or large-size business. Classical payment aggregator model is more suitable when the merchant in question is either an individual or a small business. Consequently, sub-merchants of classical aggregators must follow certain constraints of maximal processing volumes. When transaction volumes of a merchant become larger, this merchant can be obliged to have its own MID, or even become an independent business.

Conclusion

As the need for payment service providers and payment facilitators grows, you may consider becoming one. It is important to identify the specific model that you want to follow and ensure that you have necessary banking relationships, procedures, and software to handle the needs of the respective market segment.

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