Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

We are an eCommerce website. I'm working on our PCI compliance at the moment, and I'm trying, if at all possible, to argue that our organisation falls under SAQ A rather than D. We do not sensitive card details in a database, physical media etc etc. We've passed numerous PCI scans.

Our payment flow is as follows:

  1. Add items to basket.
  2. Enter address details.
  3. Move to new page, hosted on our own website (which itself is generated by a dedicated server, hosted at a PCI compliant data centre) where the customer enters their card details.
  4. These details are then HTTPS POSTed to our server where they are assigned to a variable and then cURL Posted (with SSL) to our 3rd Party Payment processor.

I'm hoping that because card details are held in volatile RAM rather than any permanent storage we may still fall under SAQ A. If we do not, (and only considering the above criteria) would we fall under SAQ C or SAQ D? I've previously been advised SAQ C but this seems to be reserved specifically for hardware payment applications, which we don't use.

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted

It is not storage, but it is handling, processing and transmitting.

To qualify as SAQ A you must be able to state,

"Your company does not store, process, or transmit any cardholder data
on your systems or premises, but relies entirely on a third party(s) 
to handle all these functions;"

You are however transmitting cardholder data, thus you do not qualify.

For SAQ C, you appear to not qualify due to:

Your company does not otherwise receive or transmit 
cardholder data electronically through any channels
(for example, via an internal network or the Internet);

C only is intended to apply to companies that are entering the card information in to their site after taking the information via a non-electronic means (such as credit card information entered on a mailed in statement.)

You can check with a PCI-DSS specialist that can look at your situation in more detail, but you appear to fall under the SAQ D.

In order to avoid PCI-DSS requirements, you would need to never handle or touch PCI data in any way. You would need to provide the amount to bill to a third party provider who would handle the entry of PCI and payment processing and then return you a non-PCI linked payment receipt code.

share|improve this answer
    
+1 agree. Maybe it would be better if the credit card data went directly from the customer to a PCI-compliant server directly to the payment processor (as with Stripe, Square, Chargify, etc.), rather than making a detour through some other server. –  David Cary Feb 3 at 16:33
add comment

From reading your description it sounds like your an SAQ C. Additionally, as a food for though I would request an Attestation of compliance from your payment processor. This will basically state they are in compliance with PCI DSS. Also just to make sure aware PCI DSS 3.0 has been released and I strongly suggest you follow this new version due to updates. The following website provides some good information on helping you determine which SAQ you must complete. If you expand the blue links you see additional details:

http://www.pcicomplianceguide.org/merchants-20081023-pci-saq-forms-validation-types.php

But at this point...I feel confident you are going to need to complete an SAQ C. Reason are because you:

  • Accept payments on the Internet via your eCommerce website
  • You dont store any card numbers but you do process and transit them to your payment processor.
  • Lastly you simply direct your customers to a third party payment processor.

This meets the criteria for a SAQ C when reading the descriptions from the above link.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.