Authorize.Net API questions and help with your payment integration.
Authorize.Net API questions and help with your payment integration.
09-30-2013 02:05 PM
I know that some of the Authorize.net APIs allow for reduced PCI compliance scope, however is there any guidance anywhere indicating to what level? The PCI DSS E-commerce Guidelines released by the PCI SSC would seem to indicate that the only merchants that are allowed to use an SAQ A would be ones that employ a “wholly-outsourced E-commerce Implementation” (page 17).
Link to PCI DSS E-commerce Guidelines:
Since the various APIs offered by Authorize.net require some level of integration with the merchant, whether it is serving up the payment page/client side code or redirecting the customer to a hosted payment page, does that mean a SAQ D is required (wholly or sections). Would any of the APIs allow us to fill out a SAQ C?
09-30-2013 05:35 PM
10-01-2013 11:04 AM
Based on the guidance provided I don't see how SIM and CIM could be SAQ A. On page 17 of the e-commerce guidelines it clearly states that in a wholly outsourced e-commerce implementation "the merchant may be able to complete a SAQ A.”
A wholly outsourced implementation "consists of e-commerce application, hosted servers, and hosted infrastructure, which are all provided and managed by the third party". The note on that page is particularly clear: "Note that if the merchant has to install an application or code on a server, configure a server file, etc. for their e-commerce implementation, they should refer to Section 3.4.3, “Shared-management E-commerce Implementations,” above.”
Based on that statement I don’t see how any Authorize.net API or from any other vendor for that matter can qualify for an SAQ A. I’d love to be wrong on this, but after reading and rereading this document several times I just don’t see any other way to interpret this.
Without a doubt the API solutions provided by Authorize.net and others greatly reduces the scope of PCI, but I don’t think to the level that many people assume.
Can you get away with a SAQ C? I can’t say I’ve seen any definitive documentation to prove or disprove that assertion. If someone has something more substantive than a blog post I’d love to see it.
Also, transaction volume determines if you can fill out a SAQ or if you have to have a ROC completed by a QSA. It has nothing to do with the type of SAQ you are required to fill out. If you are dealing with less than 6 million transactions in a year then you can fill out a SAQ, otherwise it is a ROC.
10-02-2013 01:10 AM
10-02-2013 10:34 AM
Agreed with both solutions the merchant has zero visibility of the cardholder data. However, the merchant plays a role in ensuring that data is securely transmitted to Authorize.net. For example:
In my mind that equates to a breach caused by some weakness in the merchant’s e-commerce infrastructure.
Based on how I’m reading the e-commerce guidelines, if you manage code or systems involved in the transmission of credit card data it is under scope for PCI, and you cannot get by with a SAQ A. I agree with the statement above that a shopping cart does not equate to an e-commerce solution, but I think it is clear that is a component of that solution and therefore whoever is managing it is responsible for addressing PCI requirements.
10-02-2013 06:45 PM
10-03-2013 10:56 AM
Not sure what would qualify as SAQ-A if you are correct - would you have to offload your entire catalog to a third-party service?
Yes, that is exactly what the e-commerce guideline is saying. From page 17 of the PCI DSS e-commerce guidlines:
“Many merchants are interested in managing their PCI DSS responsibility by outsourcing all cardholder data storage, processing, and transmission to a third party hosting provider or e-commerce payment processor. In this case, merchants may elect to use a solution provided and hosted by a third party, which is wholly under the control and responsibility of the third party. This type of solution could consist of an e-commerce application, hosted servers, and hosted infrastructure, which are all provided and managed by the third party. A web interface is provided for the merchant to access the third-party site, and to manage the e-commerce store and customers.”
“PCI DSS Scoping Guidance: In this scenario, the merchant may be eligible for the PCI DSS Self-Assessment Questionnaire (SAQ) A. SAQ A reduces the number of applicable PCI DSS requirements for merchants that outsource all storing, processing, and transmitting of cardholder data to an e-commerce payment processor. More information about SAQ A can be found below under “Outsourced e-commerce Implementations and SAQ A.”
If you do that, why bother with SAQ at all? What is the purpose of SAQ-A?
Actually if you look at the requirements the merchant is being asked to attest to in a SAQ A (for reference at the bottom of this post), it totally lines up with a “wholly outsourced implementation”. Basically the merchant is validating 3 areas:
1. They are eligible to complete a SAQ A because wholly outsource the handling, storage,
processing, and/or transmission of cardholder data.
2. There are physical controls to protect credit card data that is on paper media received by
the merchant from the vendor.
3. The merchant has the appropriate contractual and policy pieces in place to spell out the
vendor’s responsibility in protecting cardholder data and ensure the vendor’s adherence to
Nothing in SAQ A references technical controls on the merchant’s part. It does not make sense that if you are using one of the APIs that you would not have to attest to some technical or process controls, because at a minimum it is your responsibility to ensure that the code that specifies where the cardholder data is posted is protected from unauthorized changes.
So we get back to my original question which SAQ or subsections of an SAQ make sense for a particular API?
SAQ A Validation Questions :
Requirement 9: Restrict physical access to cardholder data
Are all paper and electronic media that contain cardholder data physically secure?
(a) Is strict control maintained over the internal or external distribution of any kind of media that contains cardholder data?
(b) Do controls include the following:
Is the media classified so it can be identified as confidential?
Is the media sent by secured courier or other delivery method that can be accurately tracked?
Are processes and procedures in place to ensure management approval is obtained prior to moving any and all media containing cardholder data from a secured area (especially when media is distributed to individuals)?
Is strict control maintained over the storage and accessibility of media that contains cardholder data?
Is media containing cardholder data destroyed when it is no longer needed for business or legal reasons?
Destruction should be as follows:
Are hardcopy materials cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed?
Requirement 12: Maintain a policy that addresses information security for employees and contractors
If cardholder data is shared with service providers, are policies and procedures maintained and implemented to manage service providers, and do the policies and procedures include the following?
A list of service providers is maintained.
A written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.
There is an established process for engaging service providers, including proper due diligence prior to engagement.
A program is maintained to monitor service providers’ PCI DSS compliance status.
10-03-2013 04:58 PM
10-08-2013 12:42 AM