OK, we are tackling this wonderful subject for the second time. We have last year touched on this through this post. Unfortunately there are still so many questions on this, that we feel that we need to re-tackle this matter again.
One response a company received regarding this issue from their payment processor was as follows (when merchant requested if they can do SAQ A-EP)
“No. SAQ A-EP you are still not allowed to transmit card data. Please have a look at below snippet taken from the SAQ A-EP AOC:
* All processing of cardholder data, with the exception of the payment page,is entirely outsourced to a PCI DSS validated third-party payment processor.
* 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.
If you want customers to enter their card data on your website you require the
PCI SAQ D.”
And so, our lengthy reply was as follows:
Your payment processor could be correct (or incorrect) depending on how your page is set up. They are sort of correct in saying you are not allowed to ‘transmit card data’. Because in the SAQ A-EP example, you serve the payment page, and then the card data is transmitted from the user desktop directly to the Payment processor. It is the way the SAQ A-EP is worded that makes it so confusing. You can clearly see that these two statements may sound like they actually conflict each other:
* All processing of cardholder data, with the exception of the payment page,is entirely outsourced to a PCI DSS validated third-party payment processor.
* 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.
If you read the above, it actually says that, all processing must be outsourced except the payment page (meaning the merchant can host the payment page). The below statement seems to shoot itself in the foot by putting in “The website does not receive cardholder data but controls how cardholder data is ‘redirected’ to a payment processor.” Unfortunately this is not the only place where PCI SSC mucks up its documentation. I can name like a dozen more times they read like its written in Hebrew and translated to English after that.
The only way to really explain is to refer to two documents I will refer to here – first, the “Understanding SAQ document” and the other is from VISA itself, the “Processing Ecommerce Payments Guide” which is what SAQ A vs SAQ A-EP is based on.
Read Page 4 of Understanding SAQ document and tell me how you interpret the table.
Its basically saying the payment page can come from EITHER the merchant website OR a PCI DSS website. As if that’s not enough to clarify, the next page, PCI even gives an example, whereby the “MERCHANT SITE CREATES THE PAYMENT FORM”. So this is clear. The payment form CAN BE IN YOUR WEBSITE.
Apparently they differentiate “receive cardholder data” and creating a payment form doing a direct post to the payment processor. Because in the form, you can send it directly to the processor to process the form posts and input, or you can process it on your own (I used for instance <form action=”PHP_SELF”> which was many years back to reprocess the form input in the same page). The latter example is what they mean by “receive cardholder data”. Not by creating the form itself, but by actually processing what the form is sending when user clicks submit.
You can process it, and then send it to the processor; or you can send it to the processor direct and have them process it.
The first one is SAQ D, the second one is SAQ A-EP. Both occasions the form is still residing on your merchant page. It is what happens after the ‘submit’ is clicked that is important.
If you want to read further, Visa has a better document, the “Processing Ecommerce Payments Guide”. In page 5, the bottom table clarifies a lot.
Basically if you are a merchant 3 and 4 doing either a direct post or javascript, with payment page sitting on your website, then you are eligible for SAQ A-EP.
Lets look at direct post in page 10 and tell me what you are interpreting.
- The merchant website CREATES a payment form and SENDS it to the customer computer
- The customer computer displays the payment form
- The customer enters their card data into the payment form and presses the OK button
- The customer computer SENDS the card data to the PSP
The red parts are all done IN YOUR ENVIRONMENT or your customer. Only in step 4 is the card data sent directly to the PSP. So yes, technically, your website is only “serving” the payment page. Once the page is ‘served’, it goes via direct post to the PSP when the submit button is clicked.
SO, in conclusion: The key thing here is that if your website is directly processing the entries of the forms, then it falls under XML or ‘anything else’ and that’s SAQ D and your processor is correct. This is page 14 of the ecommerce payments guide from VISA. We sometimes see this in merchants who create the form, then for some reason or another prefer to process the information entered into the form and then only sends the information on its way to the processor. They don’t store it, but they process it first before shooting to the processor.
Once more, you can see this by your form. If you have a <form action=”to your own page” or current_page or whatever> then basically you are processing the form before sending to your processor. If your action is to direct to the processor site, then SAQ A-EP can be used.
Hopefully this matter is put to rest!
