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


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.

From Batch to Retail Payment Processing


The landscape of modern payment services market is rapidly changing. More and more well established companies, using legacy software, face the problem of expansion of their existing offerings to accommodate the newer needs of the market. One of transition-related issues is the addition of retail functionality to an existing recurring-billing-oriented payment system.


A well established business, which traditionally functioned as payment aggregator, has recently become a payment facilitator. Its main function is aggregation and facilitation of recurring payments in some industry (membership dues, insurance, installment payments, utility bills etc). Now the company faces the necessity to add a card-present EMV solution to its business offering.


The problem is most relevant to billing companies, which sell their software products to front-end users. Many of such billing software vendors traditionally focused only on card-not-present transactions. They used to function as recurring payment aggregators for a long time, but (under pressure from associations) switch to payment facilitator model. We should remind, that such a transition also allows these companies to get greater control of merchant underwriting process.
On the other hand, under pressure from their customers, they have to add retail component as well as e-commerce processing to their (initially recurring-payment-oriented) payment system.

The pressure from the customers has the following reasons.

Many customers of such companies are brick-and-mortar businesses, which emerged long before online operations became possible. (Recently founded businesses, in contrast to brick-and-mortar ones, operate mostly online and, consequently, do not need any retail components). Some other businesses, representing the clientele of recurring payment aggregators, follow “mixed” operation modes.


A fitness center receives membership dues as recurring online payments, but sells physical merchandise, such as apparel, foods, drinks, and supplements, at a physical facility. Another example is an insurance company, which collects recurring payments, but wants to be able to collect past due payments and pre-payments in retail environment or online.

In order to be able to accept card-present/EMV payments, some of subscription-based businesses resort to third-party solutions, such as usage of standalone payment terminals. For handling of online payments these businesses can use PayPal or Authorize.net services on an individual basis. However, we should stress, that reconciliation process becomes more complex, as you, potentially, have to reconcile payments handled by multiple systems.

Another issue, faced by recurring billing companies, concerns handling of non-recurring payments. All the payments, made using a standalone terminal (past due payments or pre-payments, for example), have to be, then, manually input into the primary system of record, used for management of recurring payments.

Consequently, in order to ensure greater convenience and flexibility of operations for its customers, the aggregator/payment facilitator has to add both retail and e-commerce processing functionality.

Addition of a retail component, in fact, calls for implementation of real-time processing functionality. As EMV has recently become an official standard for retail payment processing, in a situation like the one just described, implementation of EMV solution becomes a top priority.

In order for your retail payment processing implementation project to be a success, you can use the following strategy, which includes several important steps, and which poses some challenging questions to be answered.

Strategy in brief

You need to understand both business and technological sides of the problem.

Business-related questions are as follows.

  • How are merchant accounts going to be issued? Who will be underwriting them?
  • Which processing system is going to be used?
  • What is the integration cost and how much time will the integration take?
  • What’s going to be the by-rate charged by processor for retail payment processing and what rate will be charged for the merchants?
  • How will funding be handled?
  • How will merchants acquire the necessary equipment? Who will they buy payment terminals from? Is fulfillment center relationship needed? How the terminals are going to be priced (full price/discounts/subsidies)?
  • Which card brands are you going to handle and in which countries?

Technology-related questions are as follows.

  • How you are going to implement a payment terminal solution and go through EMV certification, if necessary?
  • Which architectural changes need to be introduced into the existing system, initially developed exclusively for handling of recurring payments, in order to enable it to support real-time payments?
  • Are you going to use standalone terminals, or do you need to integrate with some POS systems?
  • Will you need only standard terminals or mobile terminals as well?

Strategy in detail

Here (in greater detail) are some important strategic issues to address.

Who will provide merchant accounts for retail payment processing?

Can you stay with your current processor? If your current processor supports different payment modes, such as e-commerce and EMV, can you use them for both recurring and retail payments? If yes, can you provide retail (real-time processing) services as a payment facilitator (the model you are already successfully using for batch processing), or do you need to switch to a different model (say, a retail ISO) to provide retail services? As we explained in our previous articles, under retail ISO model, you will simply resell merchant accounts, while merchant on-boarding and funding will be handled by the processor. If you stick to the payment facilitator model, you will have to handle merchant on-boarding and funding.

If your current processor is CNP-only, should you try to establish a new retail relationship? I.e., should you try to get merchant accounts for retail from a different processor? Does it make sense to move your entire business (both card present and CNP) to the processor that offers all the functionality you need, a better price, and, possibly, some additional services (such as robust merchant on-boarding, chargeback handling, and cross-brand account updater mechanisms)?

How are you going to technologically implement the integration?

Real-time and batch integrations are conceptually different processes. Consequently, no matter, whether you switch to a new processor or stay with the current one, real-rime integration is needed anyway. Moreover, if you need to use EMV payment terminals or mobile devices, you also need to select an appropriate EMV solution. As we mentioned in our previous use case, you have to study hardware options, supported by your specific processors, and, if you want to use your own customized terminal solution, you have to keep in mind fulfillment-related issues.

During the integration, you can either develop the software using your own development team, or use some third-party software product.

How are you going to handle non-recurring payments?

Your existing recurring billing system is, most probably, not adapted for handling of one-time payments. If, conceptually (and architecturally) the system was not intended for support of one-time payments, then addition of non-recurring payment functionality is quite a challenge.

Even if you have the logic to handle one-time cash or check payments, this logic might be too rudimentary to accommodate real-time credit card or ACH processing. Moreover, this functionality is, probably, not fit for handling of complex transaction lifecycles.


Addition of a retail payment processing component to your recurring-payment-centered system can be a major challenge, given all of the items that you have to consider. However, you can consider this challenge as an opportunity to switch to a more standardized and robust payment management platform (such as UniPay Gateway), that will not only solve the current problem, but also improve the overall quality and the capabilities of your existing payment ecosystem.

From ISO to Payment Facilitator


Recently the term “payment facilitator” has gained popularity. The role of payment facilitators at the merchant services market has grown significantly. The concept of a payment facilitator is actively promoted in the merchant services industry. Consequently, more and more companies consider the idea of assuming the role of payment facilitators.


A business, selling merchant accounts, is currently functioning as ISO, but wants to become a payment facilitator.


An ISO, generally, relies on other entities in many aspects of its activity. If a business needs to get a merchant account (purchase it from an ISO), the ISO needs to address some other entity (usually, the payment processor) to handle this issue.
Traditionally, the model functioned as follows. ISOs and software companies, which performed the role of ISOs for their clients, referred their clients to the processors and helped sell the accounts, relying on external gateway. Underwriting and funding was handled by the processors. With time, as the number of clients increased, they realized that the model was not very effective. As a result, payment card associations suggested the concept of payment facilitators, which provided these new entities with greater control over the processes of MID issuing, merchant funding etc.
ISOs have various reasons for becoming payment facilitators.
As we’ve mentioned in one of our articles, a payment facilitator actively participates in sub-merchant funding, and each of its sub-merchants is funded under a separate MID. In view of these functions, to become a payment facilitator, an entity needs to perform several important steps and answer some critical questions.


Finding a processing partner

If you are an ISO, you already have a certain number of merchant accounts to support.

  • Are you going to become a payment facilitator with your current payment processor, or find a new processing partner? In either case, as mentioned in the respective article, you will have to sign a separate agreement with your processing partner, and go through the payment facilitator underwriting process.
  • If you are switching to a new payment processor, what is the plan for migration of your merchants? Will all the existing merchants from your portfolio be able to go through underwriting process with the new payment processor? If not, what is the “plan B” for those merchants, which are unable to do that? Some tips on migration to a new processor can be found here.

Pricing strategy and underwriting

If you are going to change our processing partner, you need to carefully study the following two issues:

  • What are the underwriting requirements of the given processor? Which documents and guarantees are required? What are the requirements for merchant services reserves? Remember, that before being able to underwrite your sub-merchants, you need to go through underwriting procedure with the payment processor yourself.
  • What transaction pricing model is offered by your potential processing partner? More information on transaction pricing models can be found in our previous articles, such as this one.

Technical aspects

You need to address several technical aspects. Mostly, these concern the peculiarities of new integration(s).

  • What types of payment cards and transactions do you need to support?
  • How will the new merchants be set up? How will the new MIDs be issued? What is the merchant underwriting mechanism you are going to use? If merchant information changes over time, how will those changes be delivered? In other words, what is the strategy for merchant on-boarding and provisioning?
  • Who will implement KYC (know your customer) logic, verification procedures? Is it going to be the processor or your own development team?
  • How will sub-merchant funding, remittance, statement generation, and reporting be organized?
  • Do you need card-present solutions (which, naturally, call for usage of physical payment terminals)? Which terminals are you going to use? Which processor(s) is(are) going to support particular solutions (card-present and card-not-present, or some others)? If several processors are going to be involved, then merchant on-boarding, funding, and chargeback handling procedures have to be worked out for each of the processors. If you need to process only card-not-present transactions, do you need to handle recurring payments and batch transaction processing? How are you going to handle these tasks? What is your solution for merchant information updating (account updater functionality)?
  • Are you going to handle most of the abovementioned processes manually? If yes, you need to develop training materials for your personnel. Otherwise (if the processes are going to be automated), you need to launch the respective development projects in order to implement the necessary logic.

PCI compliance and fraud protection

What is your status in terms of PCI compliance? What fraud protection mechanisms are available? In order to ensure the security of all the processes, you need to go through appropriate PCI audit as a prospective payment facilitator, and implement the best fraud protection tools you can find.


Becoming a payment facilitator, you are getting more control of merchant funding and underwriting processes, but you are also assuming greater risks and responsibilities. Your transition strategy must include all the aspects, needed to ensure smooth handling of the whole life-cycle of your sub-merchants.