So, you want to store credit card information in your site …

Unless you have money to burn, don’t. It’s not worth it.

We’ve been asked a few times to build systems that store credit card data locally on the website because it’s convenient for the client to do it that way, or their product/service cannot be billed immediately.

The key reason not to store the information locally is one of liability.

Imagine that the credit card information that was stored locally was stolen from your site … you’d be potentially liable for all losses on any of the credit cards stolen. That could be hundreds of thousands of pounds and I doubt if your insurance would cover it. Plus it would probably mean the end of your online business, not to mention the risk of closing you down. Remember there are also broader issues of identity theft which could carry a liability also.

There are also data protection compliance issues. Depending on how you store the information you could range from compliant to non-compliant. Any non-compliancy only exacerbates your liability. Remember too that these data protection issues also extend to how your staff access the system and how easily it would be for an employee to grab the data, leave/pass it on and compromise your organisation … for organisations that have many staff, multiple access points and higher turnover rates, this is a very real issue.

Then you also need to consider Payment Card Industry (PCI) Compliance. This is complex and difficult to achieve properly, and unless it is done properly then you will be violating your bank’s merchant agreement. At the moment the PCI is pursuing Payment Service Providers (PSPs) for DSS compliance but after this year, they should be ready to move on to enforcing it with merchants directly (ie the online stores). The six sections for PCI compliance are:

1. Build and Maintain a Secure Network
2. Protect Cardholder Data
3. Maintain a Vulnerability Management Program
4. Implement Strong Access Control Measures
5. Regularly Monitor and Test Networks
6. Maintain an Information Security Policy

From a technology point of view, it can be done. Here’s one scenario to consider.

Install an SSL certificate and a second secure server running behind a firewall, preferably with a nonpublic IP address and no default route set, which is inaccessable directly from the web (and maybe go as far as to have a dedicated crossover cable between the two servers). The second secure server runs a dedicated SQL server that the webserver (website) can only insert into – no selects or other access. The website itself should be running on its own server (dedicated IP) so that there is no risk of security breach from other sites that share the same IP address.

For larger companies, this may be a viable option and a requirement. But security is not cheap and you have procedural considerations to consider. For smaller companies with more restrictive budgets, you should only ever consider using a third-party payment gateway to take credit card information.

Payment gateways such as Protx allow you a secure integration with your website, manage the credit card information for you securely, mitigate the liability risk, include deferred payment options (so you only bill when you ship) and only cost a £20 per month flat fee.

The cost of developing your own system, not to mention the hardware and annual support costs is significantly higher than using a company that has already invested huge sums of money to ensure security. And don’t forget the lurking liability costs too.