SAQ C or D

[IslandTea]

Thank you for these forums!

I am a small merchant with both a brick & mortar and a webshop.

In the brick & mortar we use a stand alone dial-up terminal.

For our website we offer PayPal business standard (no access to CC info), or I retrieve CC info from mals-e which is then entered into ProPay. Both PayPal and ProPay are PCI compliant. No CC info is retained.

Does this indicate SAQ C or D?

[jbhall56]

If you just had your Web site, it would require an SAQ A if it truly works as you say.

If you just had your brick & mortar, it would require an SAQ B because it uses stand-alone, dial up terminals.

SAQ C is for organizations that are using an integrated point-of-sale (POS) environment which fits nothing you have.

The problem is that you are doing data entry of cardholder data and that, IMHO, puts you in SAQ D territory because you fall into the category of none of the other SAQs fit your business processes.

[IslandTea]

Jeff,

Thank you. I thought that might be the unfortunate case. I started the SAQ D earlier this week which prompted my search for info. I'll call my acquiring bank today to verify which they want.

There are so many small merchants out there with a similar business model. I really feel for them.

I think I will close my ProPay account and go PayPal only for my website, that will simplify things some. I will be closing my brick & mortar early next year and be online only. If I only use PayPal Standard for the website, that will then take me from SAQ D to SAQ A next year. Something to look forward to.

Again, thank you. Back to my SAQ D I go.

[manukabay]

SAQ C is for organizations that are using an integrated point-of-sale (POS) environment which fits nothing you have.
This is not true. An integrated POS system is only one example of the type of system covered by SAQ C. Per the PCI SAQ Instructions and Guidelines:
SAQ C has been developed to address requirements applicable to merchants whose payment application systems (for example, point-of-sale or shopping cart systems) are connected to the Internet (via highspeed connection, DSL, cable modem, etc.)

POS and shopping carts are just examples of payment applications. I don't see why you couldn't consider your browser connecting to Paypal as your payment application. And I don't see how this would preclude also having a stand-alone dial-up terminal.

I'm not a QSA, so take it FWIW. If you are concerned about the interpretation, I would advance this argument with your acquirer and see what they say. The worst that can happen is that you'll still be stuck with SAQ D, which in my opinion is ridiculous for a merchant like you who is keeping cardholder data out of your environment as much as possible.

[IslandTea]

I did call my acquirer today, excellent advice, and was referred on to a great consultant. We worked together on an online form with a series of questions to determine which SAQ is needed. She determined SAQ C was the correct one for my situation, because I use an online shopping cart system, enter info into a dial up machine or PCI Compliant virtual terminal, and most importantly I store no CC data anywhere in our system.

I am very happy to not be working through the SAQ D, which she agreed was overkill for merchants like me. She is hoping there will be clarification and extra guidance offered after the current feedback period ends.

There must be thousands, if not millions, of small merchants with very similar situations. Clarification would be good.

[jbhall56]

I stand corrected on the SAQ C. We have not run into any instances with our clients where they use PayPal or similar through their PCs. It's always been an integrated POS on a network within their retail locations with a connection out to the Internet to process card transactions.

We have two Internet/Web-based solutions, but those are different as one is an SAQ A candidate and the other is an SAQ C candidate. Then we also have brick and mortar with dial up terminals which is SAQ B. This is the problem with the SAQ series when you have multiple ways to take payments, you don't fit any of the first three and you are stuck with SAQ D, the catch all.

The only option would be to talk to your acquiring bank and see if they would allow you to fill out an SAQ B for your brick and mortar, an SAQ A for the Web site and an SAQ C for the data entry through the payment service. However, after all of that, I'm not sure you have saved yourself all that much.

[manukabay]

I did call my acquirer today, excellent advice, and was referred on to a great consultant. We worked together on an online form with a series of questions to determine which SAQ is needed. She determined SAQ C was the correct one for my situation, because I use an online shopping cart system, enter info into a dial up machine or PCI Compliant virtual terminal, and most importantly I store no CC data anywhere in our system.

I am very happy to not be working through the SAQ D, which she agreed was overkill for merchants like me. She is hoping there will be clarification and extra guidance offered after the current feedback period ends.

There must be thousands, if not millions, of small merchants with very similar situations. Clarification would be good.

Glad to hear it worked out for you. SAQ D just isn't very feasible for most small merchants. I definitely agree on the clarification, not just in SAQ selection. They really need to make things easier to understand for the small merchant if they truly want compliance.


The only option would be to talk to your acquiring bank and see if they would allow you to fill out an SAQ B for your brick and mortar, an SAQ A for the Web site and an SAQ C for the data entry through the payment service. However, after all of that, I'm not sure you have saved yourself all that much.
Since SAQ C includes all the requirements of SAQ A & B I guess I don't see why you would need to fill out three. It seems reasonable and within the intent of the SAQ's that anyone who has a payment system eligible for SAQ C could also have SAQ A & B type systems in place as well. But even if you have to fill out all three its a cut and paste for A & B. Far, far easier than going to SAQ D for the small merchant.

[jbhall56]

Since SAQ C includes all the requirements of SAQ A & B I guess I don't see why you would need to fill out three. It seems reasonable and within the intent of the SAQ's that anyone who has a payment system eligible for SAQ C could also have SAQ A & B type systems in place as well. But even if you have to fill out all three its a cut and paste for A & B. Far, far easier than going to SAQ D for the small merchant.

I too am glad to hear things worked out.

The problem we have run into with some acquirers and processors is that they use the filing criteria at the front of the SAQ literally. If a merchant does not exactly fit the criteria, then they will not accept it. That is why I always recommend contacting your acquirer and/or processor to make certain that you are all on the same page.

In this instance, the acquirer is sophisticated enough to allow you to use SAQ C. However, not all acquirers are that sophisticated and not every merchant will be so lucky.

[Hatkinson]

Just to echo the above posters point; we had two customers who were identical in terms of how they accept payments.
When we asked for clarification from their individual merchant acquirers; they came back to us with two completely different views on the same scenario with one requiring SAQ C and the other requiring SAQ D

As always verify with your merchant acquirer as in the event of any PCI related issues; you'd be dealing directly with one of their compliance officers.