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.
Recommended to you
