topic Re: Integration methods that reduce PCI compliance in Integration and Testing

Integration methods that reduce PCI compliance

rob — Mon, 07 Nov 2016 17:35:43 GMT

We are already integrated with Authorize.net AIM but would like to reduce PCI scope. We looked at the SIM integration method but were surprised that it's not responsive and honestly is not very attractive. Then we looked at the Accept.js solution but that solution (to our understanding) doesn't reduce our PCI scope as much as say a Stripe.js. We are currently looking at Spreedly but honestly that seems really strange that we'd have to resort to a separate company altogether. Am I just totally missing something?

Re: Integration methods that reduce PCI compliance

RichardH — Wed, 09 Nov 2016 03:42:55 GMT

Hello @rob

As you've discovered, you can move to Accept.js and build your own form. We are working on solutions to replace SIM that provide will be both responsive and help meet PCI DSS SAQ A, but that will coming in the next few weeks.

Richard

Re: Integration methods that reduce PCI compliance

rob — Thu, 10 Nov 2016 20:53:06 GMT

Thanks @RichardH! We looked at Accept.js but my understanding is that from a PCI standpoint it isn't as good as a provider which hosts the credit card fields. Is this an accurate statement?

Thank you.

Re: Integration methods that reduce PCI compliance

RichardH — Thu, 10 Nov 2016 21:00:05 GMT

@rob

I would suggest having a conversation with your QSA or merchant account provider. These solutions help meet PCI DSS requirements but you'll need to discuss with an expert on what is best for your organization.

Richard

Re: Integration methods that reduce PCI compliance

coppercup — Tue, 22 Nov 2016 18:05:52 GMT

Hi rob,

In case you have not already found more specific answers, my research indicates that Accept.js still achieves a PCI scope of no less than SAQ A-EP (not the simpler SAQ A) due to its javascript submission method and the fact that the cardholder data fields are still generated by your own website.

Here are two articles that discuss this specifically:

https://www.endertechnology.com/blog/notable-updates-authorize-net-july-2016

https://www.paradoxlabs.com/blog/accept-js-paradoxlabs-authorize-net/

Here are some other resources that help clarify:

https://pciguru.wordpress.com/2015/01/07/saq-a-and-saq-a-ep-clarification/

https://blog.sucuri.net/2016/06/navigating-pci-self-assessment-questionnaires-saq-ecommerce-websites.html

https://pciguru.wordpress.com/2011/11/12/of-redirects-and-reposts/

https://www.pcisecuritystandards.org/pci_security/completing_self_assessment

It is also important to note that both SAQ A and SAQ A-EP only apply to e-commerce transactions and do not apply to card-present situations (see that last article from the PCI Standards Council).

At this point, it appears that only the SIM hosted payment page can help you reach SAQ A compliance, so we all anxiously await the SIM replacement hosted page that will be responsive and mobile-friendly.

PS - I am not a PCI expert so it is advisable to do your own research. (That's my CYA, which is apparently the name of the game these days.)

Regards,

Fritz