I'm doing a bit of research on my level of PCI compliance, and I'm having a difficult time grasping where I'm supposed to be.

I have a web service that has recurring billing. The site is created using PHP and Drupal. I accept and transmit credit card information through a form, and submit it via TLS encrypted POST to Authorize.net for processing and storage.

I never store any credit card information.

I use a PCI-compliant hosting service, with a private, physical, dedicated server.

I process very, very few credit cards. Like, on the order of 1 every 2-3 months.

I know that I am required to be PCI compliant, but I'm unsure of which level it is, and I'm thinking it's either level A, or C. I'm hoping for level A, but I'm unsure of it, because I need recurring billing, and Authorize.net's ARB API seems to be the only one that supports it without me storing anything, so I then encrypt and post the data to Authorize.net.

Thanks for any answers.

  • 1
    If everything goes through Authorize.net and your server never even sees the cardholder data, then you should be SAQ A. But if it's sent to your server and then you resend it to Authorize.net, then you're going to be SAQ C or SAQ D. Nov 30, 2013 at 4:37
  • Only completely outsourced solutions are SAQ A (see the accepted answer below). Sep 24, 2015 at 16:15

1 Answer 1


Short version:

Possibly SAQ C, but be careful, because SAQ D is full of people who thought they were SAQ C. If you gave more information, it might not be long until I nodded sagely and said "ah, yes, SAQ D."

Long version:

If you haven't, you should read the PCI DSS Self Assessment Questionnaire Instructions and Guidelines.

You're not SAQ A. A is for "Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced." (emphasis mine). If your server is accepting a card number, then re-transmitting it to your processor, then you're transmitting card data, which is a cardholder data function.

You're not SAQ B. B is for "Imprint-only merchants", that is, merchants with access to the physical card. "B" is for Brick & mortar :).

You're not SAQ C-VT. VT means "web-based virtual terminals", which means that your employee sits with a computer in front of them and a phone and types in the card numbers the customer tells them; the VT acts exactly like the terminal in the checkout line at your supermarket: talks to the processor, gets back a response, doesn't store card data. If customers are entering data into your web server, then it's not a VT.

You might be SAQ C. If you're immediately sending auth requests off to your processor, never storing them (like for batch), and don't have any other systems talking to the system that's taking cards, then you might qualify for C. But the kicker is "The payment application system/Internet device is not connected to any other systems within your environment". You really have to be as minimal a conduit as can be. This is where the nuance about transmitting-but-not-storing can impact you, by the way. Storing card data will push you up to D, just transmitting might not - if properly limited.

That leaves you with SAQ D, "All other merchants not included in descriptions for SAQ types A through C". It's the longest SAQ, which is why a lot of borderline cases believe hard enough that they become a SAQ C.

But even if you're SAQ D, if your processor supports tokenization, you can reduce your scope by answering "N/A" to a lot of questions and listing that as your compensating control. For example, DSS 3.4, the requirement to encrypt card numbers, can be marked N/A if you're never storing card numbers but instead using tokens.

I work for Litle, but you might look into their PayPage + Vault,
which gives you tokenization and allows you to avoid having card
data transit your server.  Recurring payments, too, IIRC.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .