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.
-
(1) Only a PCI Qualified Security Assessor may answer the question "Does X comply with PCI" authoritatively.– Chris BurgessCommented Mar 16, 2016 at 20:41
-
(2) PCI applies to software & other components in the context of an organisation; software may fail requirements for PCI compliance, but cannot comply on its own.– Chris BurgessCommented Mar 16, 2016 at 20:44
-
(3) Recommend offsite/direct post processors that ensure CC data is never submitted to your server; you cannot misplace data you never had, and that's a good thing when it comes to credit cards (& PCI). Comments posted as opinion because I'm not a QSA :)– Chris BurgessCommented Mar 16, 2016 at 20:44
-
Thanks Chris. Besides PayPal I can't seem to find a suitable Australian payment gateway for CiviCRM that does offsite redirection to make a payment. Do you know any?– Sohal KhatwaniCommented Mar 16, 2016 at 21:04
-
Depending on what you mean by "Australian" (accepts AUD, is based in AUD, is reg'd for tax in AUD etc) the answer may vary. We have several customers based in AU, not sure which (if any) have offsite gateways in operation.– Chris BurgessCommented Mar 22, 2016 at 23:39
|
Show 1 more comment
2 Answers
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.
answered Mar 15, 2016 at 19:09
-
1Allen. Thanks for the detailed reply. I am going to go through the links over the next couple of days. Cheers. Commented Mar 16, 2016 at 9:59
I have had to research this subject for my organisation so thought I'd add this answer with more eWAY-specific detail.
The CiviCRM core eWAY payment processor and the two 'eWAY Recurring' extensions here and here all use eWAY's Legacy Direct XML API.
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.
In the future I think it will be important for CiviCRM to support more payment processors that can reduce PCI scope to SAQ A (as maintaining even SAQ A-EP will be beyond many organisations' resources) such as eWAY's Secure Panel or Secure Fields. A problem could be that these rely on some client-side Javascript and the Omnipay project seems to not include JS in its scope and I'm also not sure that the 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.
