This is the final installment in a mini-series of posts dedicated to PCI compliance. The purpose of this particular article is to familiarize merchants that have to accept payment card data and store it, so that their software is involved in cardholder data flow, with some solutions, allowing them to improve their flexibility in terms of PCI compliance.
If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.
The general solution, allowing merchants’ front-end software (web-site\CRM) not to be involved in cardholder data flow is to avoid touching credit card information. There are three ways to accomplish this: using a filter, using a hosted payment page (PayPage) or using a server request interceptor.
Cardholder data filter
When a merchant has a big and complex application with many different data flows, and it is desirable to take the application out of scope, it is possible to reconfigure the system in such a way that all of the incoming and outgoing messages are going through a sanitizing filter (so that the main application is connected to the outside environment only through this filter). The filter could use some sort of algorithm cleaning the credit card information from the incoming messages (replacing it with tokens) and inserting credit card information into the outgoing messages.
This scenario is intended for more complicated systems that need to receive messages from clients and exchange messages containing cardholder data with other systems.
This filter solution is a server-oriented one, capable of reducing the PCI scope of a business (because the filter application is still touching the credit card data) but not of completely eliminating its PCI responsibility.
Hosted payment page
Hosted payment page is a common solution for smaller applications that simply need to process payments (and require credit card information only for that).
If the needs of the merchant are confined to accepting payments in a secure way and keeping its own front-end application out of scope, it can rely on a hosted payment page to collect credit card data.
In essence, a PayPage is a web-page that contains fields to gather credit card information. The merchant supplies the payment amount (how much to charge) and description (what to charge for) to the PayPage, and the PayPage collects credit card information and then processes the transaction (pushing the result back to the merchant via callback).
For example, a merchant has a shopping cart as part its own web-site. At the time that payment needs to be collected, a redirect to the PayPage occurs (specifying the payment amount and the information on what the payment is charged for). The PayPage (residing on a PCI-compliant server of the merchant’s payment processor) takes care of the rest. The user enters credit card information and the merchant gets a payment confirmation, or transaction response, which might include token for the merchant to store if it needs to reuse the card in the future.
Server request interceptor
An interceptor is somewhat similar to the filter, only it operates on the client’s side and is used as a solution for web-applications. The interceptor is a script (usually, Java script) residing on a PCI-compliant server, that attaches itself to a static form (responsible for taking in credit card information), and is able to intercept the request when the customer puts in all of the information and hits the “Submit” button. The form gets rendered, the user enters credit card information and submits the form. The script then intercepts this request and sanitizes it by dynamically extracting the credit card information (i.e. cardholder data), converting it into tokens and re-inserting them in the request, that is subsequently sent to the server.
Since the page itself is static, the interceptor script itself comes from a PCI-compliant server and the request hitting the server no longer has the credit card information in it, the entire application is, technically, out of PCI scope.
Conclusion to the PCI compliance mini-series
The article on cardholder data flow management concludes our PCI compliance mini-series.
Although the final decision is always made by the assessor\auditor (especially, when a merchant is processing large volumes of transactions), there is a whole range of solutions allowing merchants to reduce their PCI scope or get out of it. So, even if a merchant doesn’t have resources to go through the full PCI audit, there are still ways allowing the merchant’s business to accept credit cards.
Our development has experience of using all three types of techniques, so if you need an advice on implementation of any of the described solutions, do not hesitate to contact us via our “ask question” page.
Recommended to you
