Is PCI SAQ A sufficient for an eCommerce website with a custom payment page?

Question

The question - Our payment flow is as follows:

1 - Customer adds items to basket.

2 - When viewing basket, customer can see products & also has the option of entering a delivery address AND a billing address, but NO sensitive card details.

3 - The customer proceeds to a new page, hosted on our website. Customer enters sensitive card details here.

4 - Crucially, on pressing "order", the card details are POSTed directly to our Payment Processor. They are NOT sent to our server first.

I'm trying to argue with my merchant bank that we fall under SAQ A - Is this the case?

My reasoning:

1) Our dedicated server is managed by a third-party, PCI compliant host.

2) We never store card details.

3) While the customer enters their card data on a webpage hosted by ourselves, this is dynamically generated and so only exists in the customer browser. On submitting the order, the details are POSTed directly to our payment processor. These details therefore never touch our server and A) Are not stored on the server HDD or database as a Session or B) not even fleetingly held in the server RAM

4) We have passed a number of PCI scans from different authorities to make sure we are compliant and have SSL, TFA for the server etc etc

5) As far as I can see, the two main attack vectors here would be a compromised customer computer (not under our jurisdiction) or if someone managed to gain control of our server and changed how the checkout works. But this surely affects ANY eCommerce site, even one that outsources the pages the card details are entered into to (a malicious attacker with server access could just redirect to a fake set... it's pretty much game over)

However, the eligibility criteria for SAQ A is slightly ambiguous (to my mind anyway). It states:

• Merchant does not store, process or transmit and cardholder data on merchant systems or premises but relies entirely on third party service provider(s) to handle these functions *

For me, that 'merchant systems' could include the wider meta-system of the checkout as a whole. In which case, our checkout DOES transmit card details, albeit in what I believe is a secure fashion. However, if 'merchant systems' means, for example, hardware, then we do NOT have any POS systems or servers that transmit details.

I've not been able to get a straight answer out of my compliance liaison. Sometimes they suggest I fill out D, then say it's not applicable for me so say to fill out SAQ C, but then say this is specifically for 'payment applications' such as physical terminals that are connected to the internet.

I think the crucial pivot to our argument is that even though we host the payment pages, the card data never reaches our server.

Any help would be gratefully appreciated. I'd offer a bounty but it won't let me atm :(

Thank you very much in advance!

Answer 1

I think that you are right and you should be able to use a SAQ A. However, how is this "3 - The customer proceeds to a new page, hosted on our website. Customer enters sensitive card details here." implemented? Is it a full redirect, an iFrame or something else? The hand off effects things. Remember, it's between you and your bank, if they want you to do a SAQ D, you may have to do an SAQ D.

Cheers, Nate

Answer 2

Sorry to disappoint you, but you are an A-EP.

• For SAQ A: Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored
• For SAQ A-EP: Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor.

"In a Direct Post implementation, the merchant website produces the web page that is used to accept payment data, and then passes it directly to the third-party payment processor."

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-SAQ-A-EP-used-for-Direct-Post-while-SAQ-A-is-used-for-iFrame-or-URL-redirect

Answer 3

I'm new here, can't comment,

I'm trying to figure out myself which SAQ to use A or A-EP in case if I use 3rd party provider.

So for discovered the following: SAQ A: Your page is NOT originated on your server. You may have a shopping cart and pay button which redirects customer to a processor which hosts a payment form. Example: PayPal Express.

SAQ A-EP: Your page is originated on your server, you fill it in with data and submit via post to a 3rd party. As long as data is not captured by your server and POST payload flies directly to your processor via normal form submit or JS ajax - it's A-EP.

SAQ-D: you submit data to your server. They probably worry that you can log sensitive data, or forward it somewhere else, etc.

IMHO SAQ D is way over complicated for small business that doesn't store data.