EMV Compliance: How to Become EMV Compliant

Nowadays, more and more merchants are becoming concerned with the problem of EMV standard implementation. These merchants are looking for the most suitable EMV solutions. The purpose of this particular article is to provide some guidelines, which will allow merchants to solve EMV compliance related problems.

The concept of EMV compliance is relevant for merchants, whose facilities are equipped with devices, needed for accepting of EMV payment cards. Depending on the size of a merchant (its transaction volume), its operations model, and industry type, several approaches can be used by the merchant to become EMV compliant.

Your EMV compliance implementation strategy will depend on particular payment terminal solutions, used by your business. Conceptually, there are three scenarios a merchant can follow to become EMV compliant.

EMV compliance for different merchant types

In this section we are going to consider several merchant types, starting from simpler ones, and moving on to more complicated models. Specific steps to be taken by the merchant on the way to EMV compliance will depend on the type of payment terminal solution this merchant uses.

Standalone terminal solution case

Let us consider a merchant business (say, a retail shop), which uses either no terminals, or a standalone terminal solution, provided by the MSP. The terminal is used as a standalone device, which accepts payments, and is not integrated with the POS system. After a payment is accepted by the terminal, it should be registered in the main POS system that is used as a primary system of record.

Consequently, the current solution can, potentially, be replaced by any similar standalone terminal of the same class, which supports EMV standard. So, in order to become EMV compliant, such a merchant should address its current MSP, and verify what EMV options are available (the simplest strategy for the merchant). If the current provider cannot offer any EMV options, the merchant can address other MSPs, which offer similar pricing conditions.

Integrated terminal solution case

Let us now consider the case, when the merchant (say, a large network) already uses some payment terminal solution, provided by the MSP, and the merchant’s POS system is already integrated with the existing payment terminal solution.

In this case it would be desirable for the merchant to resolve the issue of EMV compliance with its current MSP. However, if it is not possible, then the merchant has to search for an alternative solution, taking into account all the intricacies of potential new integration.

As the process of implementation of a new terminal solution involves integration of POS system with payment terminal(s), the merchant should devise the integration strategy in advance. As we wrote previously, the strategy involves several critical issues, such as:

  • Hardware to be used
  • Functions it should perform
  • Terminal fulfillment mechanism
  • Payment types to be handled
  • Required terminal solution types

A detailed description of EMV terminal solution implementation strategy is provided in the respective use case.

Proprietary terminal solution case

The third case concerns a merchant, which developed its own payment terminal software using its own development team. In contrast to the merchants, described in the first and second subsections, this merchant cannot use any other solutions from any MSPs, because it has its own application, supported by its own designated personnel. This application has to be certified by the merchant with the current processor.

In order to keep using its current terminal application, the business (merchant) needs to go through EMV certification process. As part of the EMV certification, the merchant will, most probably, have to perform the following steps:

  • address its current processor
  • buy the respective product
  • perform integration at server level
  • add the respective logic to the payment terminals
  • purchase EMV certification toolkit
  • go through EMV certification process, as described in the respective article

Conclusion

In order to achieve EMV compliance, you need to decide, which type of merchant your business belongs to. This will allow you to define the scale and the main phases of the process of becoming EMV compliant. If you follow all the necessary steps carefully, EMV compliance will open an opportunity for gaining new benefits.

Legacy System Replacement

Introduction

A lot of already-established companies are still using solutions, based on legacy software that was developed using mainframe systems. Many of these companies want to switch to newer solutions from archaic older ones. However, the process presents certain difficulties.

Problem

A company is using a legacy system, which performs all the critical payment handling functions for the company. The system is strategically important, because all company’s business operations revolve around it. The company needs an efficient way to migrate to the new solution.

Context

While it often seems obvious that an old system needs to be replaced with a new one, the actual implementation of the new system is a very challenging process. Let us suppose, there is a legacy system, used by some organization. The legacy system has many integrations with banks and other entities. Also, many front-end systems (such as POS and CRM systems) are connected to the legacy system. A lot of data of various kinds (merchant data, transaction data, etc.) is stored in the system. Certain rules, implemented in the legacy system, are not always trivial or obvious. People, who implemented them, might no longer be working with the company. At the same time, the system is used by the whole company and many vital operations rely on it.

Strategy in brief

As we can see from the previous section, the main question is how to migrate all the integrations, business logic, and data to the new system. Keep in mind that some new logic and business processes might have to be added to the new system during the migration.

The main issues to be addressed in the context of transition from the legacy system to the new one are:

  • PCI compliance
  • Integrations with processors
  • Integrations with front-end systems
  • Personnel training
  • Data migration

In the next section we are going to describe the steps, addressing each of these issues one by one.

Strategy in detail

In fact, there are several options a legacy system user can follow. We are going to use the example of one of our clients, which faced the problem of legacy system replacement and successfully managed to solve it.

Environment preparation

The first thing you should do is prepare PCI environment and install the respective software into this environment. If hosted environment is used, then all the respective hardware and software has to be provisioned into the cloud platform.

Optimization of integrations with processors

You should decide, which integrations have to be implemented to enable real-time and batch processing of transactions, account updater, chargeback handling, and merchant on-boarding. Possibly, you have to sunset some of the existing integrations, if the number of merchants using these integrations is relatively small. These merchants will have to be migrated (transferred) to the new platform, terminated, or temporarily retained on the existing platform.

In other words,

  • transaction volumes have to be analyzed,
  • based on this analysis, the key platforms for future integrations should be selected,
  • the future of the existing integrations with low-transaction-volume platforms should be decided. You should decide whether the migration is worth the effort, as certification of each new integration is a time- and labor-consuming procedure (see, for example, article on EMV certification for details).

Analysis of integrated systems

You should conduct the analysis of all the front-end systems, integrated into the existing payment gateway, and decide, whether these integrations are relevant for the new product.
Front-end systems include POS systems, CRM systems, web-sites and online services, that process payments through them, any mobile terminal solutions, or any other systems, that submit transactions into the legacy system for processing.

Just like in the case of merchants and processors, the options are: to migrate the systems, to leave them temporarily integrated with the old platform, or to phase them out (as legacy products used by a very small number of clients).

Once the inventory of the integrated systems is taken, and the decision is made as to which of them must be re-connected with the new system, the most appropriate re-integration strategy must be worked out.

Fundamentally, there are two ways to accomplish this.

  • Integrate the new system with the new payment processing system using the new system’s standard (native) API. This implies changes made in the front-end system and may not be appropriate for cases when the front-end system can no longer be modified.
  • For cases when it is not desirable to change the front-end system, an emulator of the legacy system’s API can be implemented in the new system. This way the news system will be able to accept transactional information from the front-end systems in legacy format that was used before.

Analysis of the business processes

The next important thing to do is analysis of all the business processes (and how they are performed) with the operations team. The business processes include merchant on-boarding, reviewing of files, settlements, funding, reconciliation of deposits, and others. Equivalents to these processes should be found within the new gateway. Gaps should be identified and plans should be worked out for implementation of the respective new logic. Sometimes, the logic might be already in place, but additional training materials are required, in order for the team to be able to use them for reference while working with the new system.

Development of data migration strategies

The next step to take is to decide, how the data is going to be migrated. The relevant data, usually, includes

  • Merchant settings (MIDs, settlement times, etc.)
  • Tokens (payment information, which might be used in future)
  • Recurring billing schedules (payment plans)
  • Transactional activity (statements, transactions)

You should define the ways of handling each of these data types.

Merchant settings, generally, have to be migrated. Migration is, usually, done through API or file formats of the existing gateway. It is preferable for the mechanism to allow you to transfer the merchants from one platform to another one by one. If transition goes flawlessly for one or two merchants, other merchants can be moved as well. Ideally, you should devise an approach, allowing you to add new merchants to the new system, and, at some point, import all of the existing merchants into it. Keep in mind, that the information of a merchant might get changed before it goes live on a new system and some manual adjustments after the import process might be necessary.

Tokenization data requires special attention. Tokenization data is not always readily available. Sometimes the tokens are stored by the processor and extraction of the data has to be ordered in advance. A special process might be required for conversion of tokenization data from one vault to another (re-tokenization). The tokens will have to be updated with the already existing systems. If tokens cannot be updated, you need to devise a strategy for token mapping with the new values in the existing gateway. As you are dealing with tokenization, PCI compliance issues will also have to be addressed.

Recurring billing data has to be addressed separately, because billing history and balances might be required for future analysis.

As for transaction data, in most cases there is no need to migrate it (although, sometimes, when recurring billing is involved, migration is necessary). If necessary, the respective reporting documents with transaction data can be found in the old database. If the data has to be transferred, a separate strategy is needed for the transfer. If the API is available, transaction data transfer can be performed through the API, if not – migration should be done at the database level.

Preparation for PCI audit

If PCI compliance remains the responsibility of the company, originally owning the legacy system, it needs to prepare all the documentation, necessary for the future PCI audit. It is easier to record all of the procedures at the initial development phase and analyze all of the PCI consequences at that time.

Conclusion

Before replacing your legacy system with a new one, you should gather the information on the transition process and devise a clear system replacement strategy.

The challenges of mobile EMV solutions

The purpose of this article is to familiarize the readers with the challenges of implementation of mobile EMV solutions. The article is primarily targeted at software companies, which are looking for effective approaches to integration of card-present solutions into their mobile applications. The article might also be of interest to payment gateway providers, trying to solve the problem of mobile EMV solutions for their clients.

Lately a lot of new mobile POS systems emerged, which were based on various kinds of card readers for smart phones and other mobile devices. For example, Square Readers represented one of the first available solutions, which allowed merchants to turn their cell phones into mobile POS systems.

We should stress, that the first mobile payment card readers scanned the data in an unencrypted format. In order to manipulate the reader, a native app has to be installed on the mobile device (i.e., the card reader cannot be controlled by a web-application from the web page). Consequently, a mobile card reader, that “touches” the unencrypted card data and communicates it to the mobile device, puts the whole mobile POS system within the PCI scope.

In order to better protect cardholder data and get the POS app out of PCI scope, several solutions are available. However, when EMV is involved, some of the solutions work better than the others.

Similarly to payment terminal solutions, mobile card-present solutions can be conceptually divided into three groups: integrated solutions, standalone solutions, and semi-integrated solutions. Let us address these solution types one by one.

Fully integrated solutions: EMV certification required

In pre-EMV world most companies used encrypted card readers, which encrypted card data at the moment of swipe and, thus, got the app out of PCI scope. If you apply the same methodology with EMV, there still remains a problem with EMV regulations.

The mobile POS app needs to be integrated with the payment gateway or payment processor, which is going to handle the payments. At the same time, it needs to be integrated with the EMV reader, which is going to scan the card data. If you integrate with the EMV reader, you have to go through EMV certification (using the EMV toolkit), because in this case, transaction path will go through the mobile application. Consequently, the mobile application is included into the EMV path, and it has to be re-certified every time when some change is introduced either by the gateway or by you (the POS app developer), as required by EMV regulations.

You also have to remember, that, in order to do initial certification, you have to understand the EMV certification process, buy an EMV toolkit, pay the developers, and spend a lot of time and money to complete the task. The whole EMV certification process might take three to six months.

In order to get the POS system out of the scope of EMV regulations, and, at the same time, protect the integrity of both EMV card and EMV kernel of the POS app, you can use either a standalone solution, or a semi-integrated one.

Standalone mobile EMV solutions

This solution implies the use a separate, “isolated” application for handling of payments (EMV payments included). For example, a software package, obtained from the payment gateway provider, can be installed on the merchant’s mobile device. This package is capable of performing basic payment operations. This solution is equivalent to a standalone payment terminal. The point is that the software package provided by the payment gateway is independent from the mobile POS system or app, and, at the same time, it is already EMV certified by the payment gateway.

In order to accept a payment, the merchant switches to the EMV-certified payment app, provided by the gateway, completes the payment, and then switches back to the POS app (mobile POS system), provided by the software vendor, to confirm this payment.

As we see, the POS app remains out of the EMV path.

Semi-integrated mobile EMV solutions

Another EMV mobile solution is a semi-integrated one. It is more flexible and provides somewhat greater control of the business logic than the standalone solution. However, this solution is more complicated, than the standalone one, because in order to implement its particular architecture, you need to get approvals from processors and associations.

In case of semi-integrated solution, you have to create an independent, autonomous component. SDK of this component should give your mobile POS system the opportunity to control the overall flow of business logic, but does not allow any interaction with the EMV kernel, or any control over payment processing workflow. The component itself is responsible for the transmission of the data to the payment gateway. It is also EMV certified on its own as embeddable solution. Therefore, other software packages that integrate this component into themselves, can rely on its EMV payment processing functionality, but remain out of EMV path (and out of PCI scope).

This solution is, in some way, a “gray area”. It imposes particular requirements on the architecture of the component. Architectural solution, allowing the component to keep the software package, that integrates with it, out of EMV regulations scope, will depend on the particular processor that you work with.

Conclusion

When you consider implementing your own mobile EMV solution, you need to keep in mind the needs of your existing (and, possibly, potential) customer base. Will you be able to get away with the standalone solution? Will it be better for you to offer your clients an integrated solution? If you want to go with a semi-integrated solution, be sure to approve your overall design with the EMV certification team of the underlying processor, before you embark on the actual implementation.

EMV payment terminal cloud demystified

In our previous articles we mentioned embedded payment terminal solutions, however the concept of payment terminal cloud is still an innovative one. The purpose of this article is to describe a new conceptual approach for embedded solutions, a technology called NIO (non-blocking input/output or non-blocking i/o). The technology allows to create a kind of a payment terminal cloud, that can be manipulated.

The majority of traditional non-embedded solutions, and many embedded solutions as well, are based on the assumption that the POS communicates directly with the terminal (i.e. sends all the messages directly to the terminal).

As we explained in the respective article this communication can be organized through a serial/USB port, or through the local IP of the terminal (using Ethernet cable). However, with the emergence and development of NIO technology, it became possible to use an alternative approach, where the POS does not actually have to ever communicate directly to the terminal.

The concept is very similar to many chat programs. When two people want to chat with each other, their chat client software (remote clients) subscribes to the centralized chat server. When the first person types a message, it is sent to the server and delivered to the chat client of the second person, subscribed to receive messages. The response is delivered back to the first person in the same way.

A similar mechanism can be used to control the work of a terminal. Particularly, a terminal, when initialized, can open a channel for communication with the server and keep it open (persistent connection), so that it can receive any notifications, which are addressed to it. On the other hand, a POS system can also get connected to the server and send commands to the terminal, which is already connected to this server. When multiple terminals get connected to the server in the way described above, a so-called “terminal cloud” is formed. Many terminals are maintaining connection with the server. Once the POS gets connected to the cloud, it can send messages to any connected terminal through the channel, maintained by this terminal.

Formerly, the solution was hard to implement, especially for large number of terminals, as support of multiple persistent TCP connections required too many resources. Presently, NIO technology, which can be built into a terminal and initialized on a server, allows this server to support thousands of open connections without requiring significant resources from the server.

The advantage of the approach is that it allows for usage of the same integration concept for card present and card-not-present transactions. In both cases a POS system sends messages to the server (or payment gateway) in the same way, while in traditional systems card-present and card-not-present transactions represent two different data flows (card-present transactions are, traditionally, handled through integration with the terminal, while card-not-present ones are sent to the gateway).

Another advantage concerns simplification in terms of PCI compliance. The terminal communicates with the gateway, and thus, POS remains completely out of scope, because it neither touches card data, nor communicates directly with the terminal.

Conclusion

If you are a provider of a web-application, or a mobile application, which needs to manage terminals without any local footprint (.dll libraries), or if you use OS, for which there are no available terminal adapters of terminal integration libraries, you need to search for a terminal solution, which is based on payment terminal cloud approach.
If you are a developer of payment terminal solutions, you can utilize payment terminal cloud concept. It makes your solution more promising, as it becomes acceptable for a broader spectrum of potential customers.

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

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.