PCI Compliance with Sage Pay Form, Server & Direct

Posted on 21 July 2009

Tags: SagePay, PCI

I’ve done a vast amount of research into PCI Compliancy, specifically in relation to Sage Pay and Magento. After running in many circles I can finally summarise my findings (don’t rely on this article- you should seek advice of a certified professional if in any doubt).

The comments below are based on a Level 4 Merchant (most SME’s come into this category) who only ever uses their Magento Website to take payments, i.e no on/offline terminals, etc). For this article, I assume that “storing” cardholder data includes even for a short while in “memory”. Unfortunately the “in memory” issue seems to have a lot of people arguing, I’ve come to the conclusion that by taking the details of a card on your site and then using Apache to post these onto the Payment Provider, you are indeed storing the details in Memory and exposing them to any potential Viruses/Hackers on your server.
Merchant’s using Sage Pay Form and Server (also Google Checkout, PayPal Standard, etc)

1. Do not need quarterly vulnerability scans unless their merchant account providers specifically require it.
2. The website does not need to be hosted with a PCI compliant service provider.
3. Should complete SAQ-A because they:
* Do not store, process or transmit any cardholder data on merchant premises but rely entirely on (Sage Pay) to handly these functions.
* The third-party service provider (Sage Pay) is confirmed to be PCI DSS compliant.
* The merchant is not storing cardholder data in electronic format.

This all seems to be backed up by Sage Pay on this page under PCI DSS.
Merchant’s using Sage Pay Direct (also Authorize.net)

1. Should not store un-necessary cardholder data. This can be achieved with Magento by following these two steps
2. Should be running a PA-DSS Compliant Payment Application by October 2009 (Coming soon in Magento Commercial which costs around $8,900 USD per annum)
3. Should host the site with on a Dedicated Server environment with a Level 1 or 2 PCI Compliant Service Provider (with the Database and Application Server seperated). A setup like this is offered by ZZ Servers for around $300 per month, more details below.
4. Should carry out quarterly vulnerability scans of their server network
5. Will need to complete SAQ-D because they are storing data (even thought it’s for a short time in system memory). The SAQ-D is complicated and can cost a lot of time and money to complete! Just to prove that I’m not the only one that thinks SAQ-D is required, you might like to read this article.

At the moment there are very few web hosts who are actually fully PCI-DSS certified service providers to Level 1 or 2 (due to the costs and restrictions). Be very wary of web hosts who claim that their hosting is PCI compliant without saying which levels, types and parts they are talking about. Remember that passing the security scan is only a small part of overall compliance. Visa provides a list of the Level 1 service providers here:

http://usa.visa.com/download/merchants/cisp_list_of_cisp_compliant_service_providers.pdf

I’ve also compiled a list of some providers I’ve been able to confirm their status with:

ZZ Servers
GSI Hosting

Approved Scanning Vendors who can provide the scanning and PCI certificates include McAfee Secure, Comodo and SecurityMetrics (https://www.pcisecuritystandards.org/pdfs/asv_report.html)

Once all this has been done, the SAQ along with the successful completion of the quarterly vulnerability scan (if any), should be submitted to your merchant account provider to show compliance with the requirements of PCI-DSS.

I hope this helps some people along the way, feel free to comment below!