Answers.Body: <p>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:</p>
  
  <ul>
  <li>your own server's security protocols (including, but not limited to, SSL)</li>
  <li>how the payment information is transferred to the payment processor</li>
  <li>in-office protocols for access to data both on- and off-line</li>
  </ul>
  
  <p>A great starting point is <a href="http://gitbook.civicrm.org/initial-set-up/security.html" rel="nofollow">http://gitbook.civicrm.org/initial-set-up/security.html</a></p>
  
  <p>One component is whether or not your site is utilizing SSL.  The CiviCRM wiki on <a href="https://wiki.civicrm.org/confluence/display/CRMDOC40/Security+Considerations+and+PCI+compliance" rel="nofollow">Security and PCI Compliance</a> has some excellent points about SSL.</p>
  
  <p>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 (<a href="https://forum.civicrm.org/index.php?topic=2930.msg90253#msg90253" rel="nofollow">see Lobo's comment here from 2011</a>) 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: <a href="https://www.youtube.com/watch?v=BXs5_dPOEFI" rel="nofollow">Adventures in Payment Processing</a>).</p>
  
  <p><strong>For eWay specifically</strong>, their website says they are <a href="https://eway.io/about-eway/technology-security" rel="nofollow">tier one PCI DSS compliant</a>. 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 <a href="https://www.eway.com.au/about-eway/technology-security/pci" rel="nofollow">your organization's responsibilities in PCI compliance</a>.</p>
  
  <p>A great explanation of PCI compliance and things an organization should consider relating to PCI compliance is available from this CiviCon Denver 2015 talk: <a href="https://www.youtube.com/watch?v=0TSPiYH2AS8" rel="nofollow">CiviCon Denver Data Security and Payment</a>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-16T09:59:40.837Z
Answers.Text: Allen. Thanks for the detailed reply. I am going to go through the links over the next couple of days. Cheers.
Answers.UserDisplayName: Sohal Khatwani
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-15T19:09:57.197Z
Answers.LastActivityDate: 2016-03-16T17:01:25.157Z
Answers.LastEditDate: 2016-03-16T17:01:25.157Z
Answers.UserDisplayName: Allen Hutchison
Answers.Body: <p>I have had to research this subject for my organisation so thought I'd add this answer with more eWAY-specific detail.</p>
  
  <p>The CiviCRM core eWAY payment processor and the two 'eWAY Recurring' extensions <a href="https://civicrm.org/extensions/eway-recurring-payment-processor-agileware" rel="nofollow noreferrer">here</a> and <a href="https://civicrm.org/extensions/eway-recurring-payment-processor" rel="nofollow noreferrer">here</a> all use eWAY's Legacy Direct XML API.</p>
  
  <p>The CiviCRM Omnipay extension only recently added support for eWAY. This extension is built on the <a href="http://omnipay.thephpleague.com/" rel="nofollow noreferrer">Omnipay multi-gateway payment processing library</a>. It supports these eWAY gateway APIs:</p>
  
  <ul>
  <li>Legacy Direct XML </li>
  <li>Rapid Direct</li>
  <li>Rapid Transparent Redirect</li>
  <li>Rapid Responsive Shared Page</li>
  </ul>
  
  <p>Referring to <a href="https://www.eway.com.au/about-eway/technlogy-sercurity/pci-dss" rel="nofollow noreferrer">eWAY's PCI compliance page</a>, eWAY states that:</p>
  
  <ul>
  <li>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)</li>
  <li>Rapid Transparent Redirect requires SAQ A–EP (140 requirements)</li>
  <li>Rapid Responsive Shared Page requires SAQ A (14 requirements)</li>
  </ul>
  
  <p>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.</p>
  
  <p>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 <a href="https://www.eway.com.au/developers/api/secure-panel" rel="nofollow noreferrer">Secure Panel</a> or <a href="https://www.eway.com.au/features/secure-field" rel="nofollow noreferrer">Secure Fields</a>. 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 <code>SecuredCardData</code> field that eWAY requires is catered for by Omnipay.</p>
  
  <p>Another option that is available in Australia is Stripe. <s>Stripe claims that when its <a href="https://github.com/drastik/civicrm_stripe" rel="nofollow noreferrer">Stripe.js is used that only SAQ A is required</a>, however this may be <a href="https://pciguru.wordpress.com/2017/03/21/stripe-questions-come-back/" rel="nofollow noreferrer">contentious</a>. The author of the CiviCRM Stripe extension also <a href="https://github.com/drastik/com.drastikbydesign.stripe/issues/189" rel="nofollow noreferrer">warns</a> of its limitations.</s> 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 <a href="https://stripe.com/docs/stripe-js" rel="nofollow noreferrer">https://stripe.com/docs/stripe-js</a>.</p>
  
  <p>Disclaimer: I am not a QSA and the above is just my opinion based on researching this same topic for myself.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2017-11-06T05:24:43.090Z
Answers.LastActivityDate: 2019-01-08T00:05:20.960Z
Answers.LastEditDate: 2019-01-08T00:05:20.960Z
Answers.UserDisplayName: Andrew Thompson
Body: <p>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. </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-16T20:41:19.977Z
Comments.Text: (1) Only a PCI [Qualified Security Assessor](https://en.wikipedia.org/wiki/Qualified_Security_Assessor) may answer the question "Does X comply with PCI" authoritatively.
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-16T20:44:50.960Z
Comments.Text: (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.
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-16T20:44:59.010Z
Comments.Text: (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 :)*
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-16T21:04:56.380Z
Comments.Text: 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?
Comments.UserDisplayName: Sohal Khatwani
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-22T23:39:22.417Z
Comments.Text: 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.
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-07T05:27:59.363Z
Comments.Text: Sohal, have you looked at the [nz.co.fuzion.omnipaymultiprocessor](https://github.com/eileenmcnaughton/nz.co.fuzion.omnipaymultiprocessor/tree/master/vendor/civicrm/omnipay-paypalstandard) extension for CiviCRM? [Looking at the code](https://github.com/eileenmcnaughton/nz.co.fuzion.omnipaymultiprocessor/blob/master/CRM/Core/Payment/processors.mgd.php) it appears to support 3 of the eWAY Rapid APIs listed on the eWAY page linked by Allen. Note: I haven't tried this extension before but will also have to deal with the same issue soon so would be interested in hearing if you make any progress.
Comments.UserDisplayName: Andrew Thompson
Tags: <civicontribute><payment-processor><pci-compliance>
Title: CiviCRM & PCI Compliance
ThreadText: # CiviCRM & PCI Compliance
  
  (Asked by: username_0 on 2016-03-14)
  
  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.
  
  **Tags:** civicontribute, payment-processor, pci-compliance
  
  > **Comments:**
  > **username_1**: (1) Only a PCI [Qualified Security Assessor](https://en.wikipedia.org/wiki/Qualified_Security_Assessor) may answer the question "Does X comply with PCI" authoritatively.  
  > **username_1**: (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.  
  > **username_1**: (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 :)*  
  > **username_0**: 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?  
  > **username_1**: 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.  
  > **username_2**: Sohal, have you looked at the [nz.co.fuzion.omnipaymultiprocessor](https://github.com/eileenmcnaughton/nz.co.fuzion.omnipaymultiprocessor/tree/master/vendor/civicrm/omnipay-paypalstandard) extension for CiviCRM? [Looking at the code](https://github.com/eileenmcnaughton/nz.co.fuzion.omnipaymultiprocessor/blob/master/CRM/Core/Payment/processors.mgd.php) it appears to support 3 of the eWAY Rapid APIs listed on the eWAY page linked by Allen. Note: I haven't tried this extension before but will also have to deal with the same issue soon so would be interested in hearing if you make any progress.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2016-03-15. Score: 8
  
  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](https://wiki.civicrm.org/confluence/display/CRMDOC40/Security+Considerations+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](https://forum.civicrm.org/index.php?topic=2930.msg90253#msg90253)) 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](https://www.youtube.com/watch?v=BXs5_dPOEFI)).
  
  **For eWay specifically**, their website says they are [tier one PCI DSS compliant](https://eway.io/about-eway/technology-security). 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](https://www.eway.com.au/about-eway/technology-security/pci).
  
  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](https://www.youtube.com/watch?v=0TSPiYH2AS8).
  
  > **Comments:**
  > **username_0**: Allen. Thanks for the detailed reply. I am going to go through the links over the next couple of days. Cheers.  
  
  ---
  
  ### Answer by username_2 on 2017-11-06. Score: 1
  
  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](https://civicrm.org/extensions/eway-recurring-payment-processor-agileware) and [here](https://civicrm.org/extensions/eway-recurring-payment-processor) 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](http://omnipay.thephpleague.com/). 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](https://www.eway.com.au/about-eway/technlogy-sercurity/pci-dss), 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](https://www.eway.com.au/developers/api/secure-panel) or [Secure Fields](https://www.eway.com.au/features/secure-field). 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](https://github.com/drastik/civicrm_stripe), however this may be [contentious](https://pciguru.wordpress.com/2017/03/21/stripe-questions-come-back/). The author of the CiviCRM Stripe extension also [warns](https://github.com/drastik/com.drastikbydesign.stripe/issues/189) 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.
  
  
  ---
  
  