July 1, 2010 is quickly approaching. I know this, because I am currently working on a couple of ecommerce projects. One thing that struck me is the number of custom built shopping cart solutions out there. Personally I like these custom solutions, because they can be tailored to the specific needs of a client’s customers. You can support odd configurations and logic that an off-the-shelf solution may not support. The challenge is making sure the solution is compliant with credit card regulations otherwise known as PCI-DSS.
A lot of off-the-shelf and Open Source shopping carts leave it up to the store owner to certify compliance. They try to follow software best practices, such as specified in section 6.5 according to the Open Web Application Security Project Guide. But these guidelines are very detailed and verbose. You could probably blow a clients budget just trying to understand all these guidelines. It really is making custom cart solutions a challenge especially on a tight budget.
Considering this I would focus on making the web site experience a positive one for the client’s customer. Focus on creating great interfaces for browsing and searching products, configuration options, etc. and then use a PCI compliant solution for checkout. This could be a PCI compliant cart like Pinnacle Cart or a hosted solution like Paypal or CRE Loaded. These solutions cost a bit more on a per-order basis, but simplify the implementation, especially for existing carts.
Once you have squared away the cart aspect you’ll need to square things up back at the office and with your hosting provider. Both of those require compliance as specified in section 7&8 and 1 respectively.
For a complete set of requirements see the PCI DSS Prioritized Approach documentation.
2 Comments
PCI compliance is such a joke. And an annoying one at that. Some of the PCI Compliance reports we’ve gotten back from clients’ banks have things like “Your server is running version 5.2.0 of PHP, and there’s a known bug in that version. You must upgrade to version 5.2.1” They don’t bother to check that the bug they mention would be impossible to exploit in the site’s code, but I don’t think they bother to check much of anything… So for clients in a shared hosting environment, where PHP version upgrades are impossible, you now have a huge problem. Most Mom-and-Pop eCommerce stores simply can’t afford the hosting requirements or the work involved in getting their sites to match up with these ambiguous requirements. Okay, rant over.
Thanks for your comments Mike. I know where you are coming from and it is going to make things tough on the Mom-and-Pop operations. Spoke to someone today and he is going to have his site one place and his checkout another, just to comply with PCI. Not ideal, but it kind of makes sense. I perceive that PCI compliant checkout services are going to take off if the credit card companies actually crack down on this. It is just such a wide field, there is no way they are going to be able to check everyone. I’m sure they’ll be looking for key players to go after and hope that media coverage scares everyone else to take action. I also agree that nit picky details are not nearly as important as overall best practices. For instance not storing credit card data at all in your database pretty much eliminates the need for a large portion of the requirements. If you simply send things to Authorize.net you need to make sure: 1) data is encrypted from the browser to the cart to Auth.net, 2) the system is secure enough that no one messes with the cart code to record this information through that authorization process.