Does anyone know if the Core CiviCRM Payment Methods are PCI Compliant. We want to use the eWay payment gateway in Core but not sure what the setup is of the payment processor. I know PCI Compliance requires a whole number of other factors as well but from a Payment processor standpoint I thought I should ask.
As I'm sure you are learning, PCI compliance is a complicated business. The payment processor (I discuss eWay below) and your own operations play the biggest role in PCI compliance. Some of the issues on the organization's end are:
- your own server's security protocols (including, but not limited to, SSL)
- how the payment information is transferred to the payment processor
- in-office protocols for access to data both on- and off-line
A great starting point is http://gitbook.civicrm.org/initial-set-up/security.html
One component is whether or not your site is utilizing SSL. The CiviCRM wiki on Security and PCI Compliance has some excellent points about SSL.
CiviCRM itself does not store credit card information in the database, but if you are collecting credit card info on your Civi forms and then sending it to the payment processor, the credit card info will be on your server temporarily by default (see Lobo's comment here from 2011) so your server will need to be PCI compliant. (Eileen mentions options like direct post and transparent redirect in this CiviCon talk for certain payment processors, but that takes some semblance of custom work: Adventures in Payment Processing).
For eWay specifically, their website says they are tier one PCI DSS compliant. If you are sending people to an external site for eWay to process on their site (I don't know if that's an option for eWay), then a lot of the responsibility for PCI compliance gets off-loaded as well. If you are collecting credit card info on your own Civi forms and then sending the info to eWay, they have a page about your organization's responsibilities in PCI compliance.
A great explanation of PCI compliance and things an organization should consider relating to PCI compliance is available from this CiviCon Denver 2015 talk: CiviCon Denver Data Security and Payment.
I have had to research this subject for my organisation so thought I'd add this answer with more eWAY-specific detail.
The CiviCRM Omnipay extension only recently added support for eWAY. This extension is built on the Omnipay multi-gateway payment processing library. It supports these eWAY gateway APIs:
- Legacy Direct XML
- Rapid Direct
- Rapid Transparent Redirect
- Rapid Responsive Shared Page
Referring to eWAY's PCI compliance page, eWAY states that:
- Legacy Direct XML and Rapid Direct APIs require PCI SAQ D (326 questions) compliance (this is the API used by the CiviCRM Core, eWAY Recurring extensions, and the Omnipay Rapid Direct and Omnipay Direct payment processors)
- Rapid Transparent Redirect requires SAQ A–EP (140 requirements)
- Rapid Responsive Shared Page requires SAQ A (14 requirements)
So using the Omnipay extension and choosing Rapid Shared is the only available eWAY+CiviCRM option that could reduce the PCI compliance scope to the lowest level, SAQ A. However, it's not that simple. Offsite payment processors such as this are only supported by CiviCRM on front-end pages and do not work for back-end pages. There is no available option for eWAY+CiviCRM back-end contributions that can result in less than SAQ D.
SecuredCardData field that eWAY requires is catered for by Omnipay.
Another option that is available in Australia is Stripe.
Stripe claims that when its Stripe.js is used that only SAQ A is required, however this may be contentious. The author of the CiviCRM Stripe extension also warns of its limitations. EDIT: At some point in 2018 Stripe changed its requirements: Stripe.js (on its own without Elements) will now necessitate SAQ A-EP as per https://stripe.com/docs/stripe-js.
Disclaimer: I am not a QSA and the above is just my opinion based on researching this same topic for myself.