What are the steps that need to be taken to achieve PCI Compliance for Magento CE?
For example using Paypal website payments pro or sage pay direct in a store would help to achieve PCI compliance?
Magento Stack Exchange is a question and answer site for users of the Magento e-Commerce platform. It only takes a minute to sign up.
Sign up to join this communityWhat are the steps that need to be taken to achieve PCI Compliance for Magento CE?
For example using Paypal website payments pro or sage pay direct in a store would help to achieve PCI compliance?
It was always regarded as being PCI Compliant - until EE came along, then EE needed another USP. As long as you aren't storing CC details - there is no requirement for encryption of other data (customer name/address etc).
But bear in mind that PCI Compliance is as much an application side requirement as it is a set of rules and definitions for running your company and handling sensitive information.
What level of compliance you fall in to will dictate what you need to do to ensure PCI Compliance. If SAQ (self assessment questionnaire) is suitable for your business size, then you can pass unaided with CE - when using an external payment method (such as those described).
Otherwise, above SAQ levels - you'll need a QSA anyway - and you're talking big money with professional assistance. The fact you are asking here probably stipulates you aren't in this boundary.
You would likely fall under SAQ-D
How do you accept payment cards?
A. Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants.
B. Imprint-only merchants with no electronic cardholder data storage, or standalone, dial-out terminal merchants with no electronic cardholder data storage.
C-VT. Merchants using only web-based virtual terminals, no electronic cardholder data storage.
C. Merchants with payment application systems connected to the Internet, no electronic cardholder data storage.
D. All other merchants not included in descriptions for SAQ types A through C above, and all service providers defined by a payment brand as eligible to complete an SAQ.
See https://www.pcisecuritystandards.org/smb/what_to_secure.html
- Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region 2
- Merchants processing 1 million to 6 million Visa transactions annually (all channels)
- Merchants processing 20,000 to 1 million Visa e-commerce transactions annually
- Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually
See http://usa.visa.com/merchants/risk_management/cisp_merchants.html
What is important is to differentiate the merchant level and SAQ level. They are separate. You can be SAQ-D as a Level 2 merchant. In-fact, in most cases you can self-assess up to Level 2 when at level SAQ-D - as the requirements are more relaxed because you are not handling card data at all.
Merely using EE does not make you PCI Compliant, the same way using a PCI Compliant host doesn't make you PCI Compliant. Your business as a whole (application, business/staff, hosting) must all be PCI Compliant.
The PCI level you need to comply with depends on how many transactions your are likely going to have. As a first step you should work out which level would apply to you:
http://usa.visa.com/merchants/risk_management/cisp_merchants.html this is from VISA but would similarly apply to PCI
With each level you will have different requirements to meet. Once you have done the assessment I am sure someone will be able to give you a more detailed answer on what steps to take with CE.
Enterprise Edition comes with an application called Payment Bridge which deals with a really nice amount of encryption and can be run on a separate server than your application. This can be over-kill for most contexts, and requires willingness to isolate and debug application code in a OO organization that isn't as easy to follow as the Magento Core code.
PCI compliance has many small nuances which actually do make CE not fully PCI compliant. The fastest and often best way to be PCI compliant on CE is to use a third party tokenization payment gateway system. There are a few extensions that already have integrated Authorize.net CIM, or Cybersource Payment Profiles, and a few others. This means that when implemented correctly, all you ever store is the profileID for the customer and the credit card data is stored on the payment gateway.
That being said, I don't think your question clearly states the information you're wishing to store about the transaction that you're looking to enhance to meet PCI compliance. Without more information it is difficult to help solve your particular requirement's architecture with any specificity.
I think are normally two ways:
You don't want to do it yourself, because you are a small shop, then you should stay with the CE and use some payment provider to do this thinks for you
You are a big company and expect a lot of transactions and want to do it yourself. Then you should have enough money to use the EE.
OLD ANSWER:
You have to encrypt all credit card data (thanks to @sonassi) in a "PCIish" way, and a lot more. To check for PCI compliance costs afaik a lot of money. Why do you want this? Use the EE :-)
All the information you need can be found On the PCI Website
And I don't think there are much developers here, who know the standard, me neither.
PCI compliance is nothing to play with. If you want this, you have to spent a lot of money and you need experts.
There are plugins (e.g. security company Foregenix have one that does logging, file change monitoring and few other things) that can help put some of the PCI controls in place quickly and simply. But if you're looking to take the easiest path from a compliance perspective you should really consider using a hosted payment page from your payment gateway. This will allow you to use SAQ A-EP (as long as you're not trying to do something different from the ordinary hosted payment page).