Getting out of PCI scope

Introduction

More and more companies nowadays accept credit card payments. Payment card industry is regulated by Payment Card Industry Security Standards Council, which has specific security requirements. According to these requirements, each company, dealing with card data, has to go through regular PCI audit, which is quite a costly procedure. That is why many companies are trying to find the answer to the question: how can a business accept payment cards, but remain out of PCI scope.

Problem

The general problem is to move the existing payment system, which is presently in PCI scope, out of it. At the same time, the system has to be able to perform its functions as before.

Context

While some companies cannot avoid PCI audit, because their payment systems are too large, a number of merchants and software companies are technically able to reorganize their infrastructure in such a way, which would allow them to either get out of PCI scope completely, or reduce their “exposure level” and PCI audit costs.

From conceptual viewpoint the problem has several complexity levels.

  • Level 1: Card present vs card not present. If only CNP transactions are involved, it is much easier to reduce exposure level.
  • Level 2: Number of front-end systems.
    If only one front-end system (for instance, a POS system) is involved, the process becomes much more transparent. If there are many front-end systems, a solution must be found for each of them.
  • Level 3: Which kinds of applications are involved?In some cases web applications might be easier to remove out of PCI scope, than desktop applications. If you are dealing with a legacy system which uses obsolete technologies and has limited functionality (or, maybe, the developers who created the system are no longer with the company), the task becomes even more complex.
  • Level 4: Are recurring payments involved? If the answer is “yes”, then there is a need to store cardholder data, and the matter of exposure reduction gets trickier.
  • Level 5: Are all the merchants using different payment systems? Say, if you are a software company, the users of your software can either partner with the same PSPs, or have different independent (individual) processing solutions. So, is payment processing
    unified for all users of your platform, or do they have customized processing solutions associated with local banks or processors?

Strategy

In order to optimize your business infrastructure and successfully get your company out of PCI scope, or at least, reduce your exposure level, you need to perform the following important steps.

  • Consult the PCI auditor. Whatever strategy you have in mind, discuss it with the PCI auditor before implementation. Then compile all the necessary documents to start the process.
  • Decide, which of the components of your payment ecosystem have to be phased out. In the simplest case the system consists of a single software package. However, in many cases, it can include several packages, different terminal solutions, etc, and these components and solutions have to be prioritized.
  • Decide, if (similarly to the previous step) you need to sunset your integrations with some processors and migrate merchants to other processing platforms in order to unify and simplify the process.
  • Decide, whether you need to unify payment processing across your customers. Do you, potentially, need to reduce the number of supported processors and simplify the overall infrastructure, in order to make it more transparent.
  • Decide, whether you need to store cardholder data. If your company uses terminal capture, then you have to send the file with card numbers to your processor on a regular basis. Consequently, you have to store card numbers within your system. However, if you switch to host capture, card numbers no longer have to be stored in the system and sent to the processor.
  • Analyze the following two basic issues in the context of exposure level reduction: card flow and card storage (if necessary). Card flow can be handled in two ways: either using payment pages (mostly for CNP solutions), or (for card present solutions) using P2PE on card readers or payment terminals. For card storage a classical solution is tokenization of card data.
  • Verify, whether CNP, card present, and recurring billing solutions are supported by each of the PSPs your system works with. We should remind that if recurring billing is involved, you or your partner PSPs have to store and, consequently, tokenize card numbers. If some of the PSPs do not support all the necessary services (or if it is more relevant to work with some unified processor-agnostic service and eliminate the necessity to support different tokens), then you should consider partnering with some independent (processor-agnostic) tokenization services. Some information on migration from one processor to another can be found here.
  • Plan the integration works which have to be done for implementation of the new infrastructure. These may include integrations with tokenization services, P2PE service providers, and other entities.
  • Plan cardholder data migration process. If actual card numbers are stored within your system, or if your current tokenization solution is only partial, you need to decide, how and when card numbers will be migrated.

Conclusion

Even if you understand that you are unable to get your system out of PCI scope completely and all you need is to simplify the process of cardholder data handling, you might consider using some standardized open-source payment technology (such as UniPay Gateway), which is capable of performing all the necessary functions, within the existing payment ecosystem. This step will allow you to unify many internal processes and, thus, simplify PCI audit procedure.

Dealing With Multiple International Payment Platforms

Introduction

Present-day globalization tendencies push more and more businesses to process payments in multiple geographical zones.

Particularly, such companies include businesses, which start offering their products online internationally, and franchises, which enter international markets.

The purpose of this article is to outline the problems faced by these companies and try to provide structured step-by-step strategy that they could follow.

Problem

Let us say, there is a company, which wants to solve the problem of multi-currency and international transaction processing for itself or for its clients.

Context

The task of entering an international market can be addressed at one of the three “complexity levels”.

  • Level 1: A company wants to process its own transactions (product sales) in different countries.
  • Level 2: A franchisor wants to operate in different countries, but in each country at most one processing partner is sufficient (a franchisor can impose all franchisees to use a single processor).
  • Level 3: A software vendor company wants to service many clients in different geographic zones using several processing options (support more than one platform or acquiring bank in each country).

Strategy in brief

The crucial issues you will definitely have to deal with (if you want to expand your operations to multiple geographical locations) include:

  • Finding a solution for operations with several currencies
  • Prioritization of regions
  • Prioritization of typical transaction types handled by your payment ecosystem
  • Organization of underwriting and on-boarding processes in new geographies
    • Strategy in detail

      In order to organize the process properly, first of all, you have to study the overall situation and then – answer some fundamental questions.

      • Is it going to be possible to settle transactions in one single currency, or settlement currency must always be the same as authorization currency? If a company wants to charge its customers in a local currency and settle the funds from international sales in a single bank account, it can partner with a single acquirer, that supports dynamic currency conversion. If it plans to settle transactions in the local currency, then a local relationship with a specific bank will be required. In the second case a more complicated payment ecosystem will have to be built.
      • What are the high-priority and low-priority regions? What the actual transaction volume is going to be? Evaluation of transaction volumes is necessary for pricing negotiations and related issues. Establishment of the relationship with a payment processor and implementation of the required technical integration is never a simple process. It takes plenty of time, and it becomes even more difficult at the international scale, especially when several projects are under way. Most likely, you will have to proceed in the sequential manner, which is why it is important to prioritize.
      • What are the transaction types you need to process? Are you going to deal only with online card-not-present transactions? Is card-present transaction support required? Will you need EMV support and respective payment terminals? Usually, it is much easier to find a card-not-present solution, because various local regulations exist for use of the chip cards in a particular region. In some cases region-specific specifications are necessary for you to be able to accept cards in the retail environment. The additional challenge is that in some countries it is not possible to certify your existing EMV solution, and you may be required to use whatever is available on the local market. Some of these available solutions might not fit into your existing payment ecosystem.
      • Which banks will handle the underwriting process, and how merchant accounts are going to be issued? How are you going to integrate with these banks? What is the specific connection mechanism? These questions are extremely relevant for many countries. However, in some countries (say, in North America) there are payment gateways, which work with several processors or acquiring banks, and are able to facilitate your relationship with any one of them. On the international arena, the options might be more limited, because some regions have only few acquiring banks, and some gateways might be limited to work with only specific acquiring partners.

      As we can see, all business details (including corruption as well as local regulations and legislative barriers, which might result in cost increases) must be discussed and considered in advance.

      You must find the gateway, providing the best solution in each specific country in view of the listed questions.

      Finally, you will get a list of countries, banks and payment platforms you will have to partner with. After that you will have to analyze the available gateways and check, which of them have either all or most of the necessary bank connections.

      Example

      Let us consider a case when some “optimal” solution is found. Say, there is a gateway, which supports 3 of the 5 necessary bank connections, but is unable to add the missing 2 and all the subsequent ones (or the payment gateway provider is reluctant, because the cost of new connections is too high). This is just the case when you have to consider creating your own payment ecosystem (for some companies this might be the overall goal).

      Next you have to define, in which countries you will have to start from scratch, and in which countries you have some clients (merchants) already using the system. Keep in mind, that in any case if you are going to expand your operations, a strategy will be needed for on-boarding of new merchants.

      Existing clients

      Example

      A franchising company is a vendor of software for fitness centers. It doesn’t have any integrated solutions within the country. Franchisees have to establish a relationship and purchase standalone terminals from it. Every transaction, made at POS, is processed using the standalone terminal, and then – keyed into the main system of record, provided by the franchisor. The franchisor decides that the solution based on usage of standalone terminals is a bit complicated and it is better to offer integrated payment processing functionality. In this case the franchisor has to migrate the already existing merchant accounts.

      In such a situation, you have to analyze, how to migrate these clients from their existing solutions to the company’s main product. Beside that, you need a strategy for the new underwriting process (get new merchant accounts for the already existing merchants and check if processing costs are going to increase). Finally, you have to define, which technical solutions are needed (in terms of additional integrations) in order to allow merchants to be able to send transactions for processing.

      New clients

      If you have no clients (yet) in some region, you have to work out operations for on-boarding process in each particular country.

      Conclusion

      If you are planning to enter foreign markets, handle new currencies, and process transactions internationally, you need to set up priorities and develop a step-by-step expansion strategy.

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.