Is PCI SAQ A or A-EP applicable for my use case?

Question

I read the FAQ over here andI feel that we do not need to be PCI Compliance but I have read many other posts, articles etc which seem to contradict my assumption. So I was wondering if any of you guys can throw some light on it. Here is my use case,

We are a subscription based platform, so basically we charge users on a recurring basis once they sign up.

We currently use Stripe, PayPal & Amazon Payments as our Payment Processors. While using these services we never store, process or transmit cardholder data through out servers.

• For PayPal there is a complete re-direct to their pages for login & approval.
• For Amazon Payments a JavaScript widget is used to login to Amazon account (provided by Amazon itself) and grant us the approval.
• For Stripe, we use their Checkout widget to do the complete CC processing. We just get the token at the end of it.

It is kind of confusing trying to figure it out the required level of PCI compliance if any. If we were to be required for PCI compliance then there is further confusion as to whether SAQ A or SAQ A-EP is applicable to us.

UPDATE

• Looks like at least using Stripe we are good with having just SAQ A per their customer support.

Answer 1

Short version:

You seem to be A-EP You seem to be A, based on the specific products referenced, but you should ask your processor(s) to be sure.

If by "Amazon Payments JavaScript widget" you mean Amazon Express Checkout, then you're SAQ A-EP, because "elements of the payment page originate from the merchant website".

Amazon Payments "Login and Pay" is jut a button that takes the processors site, and the entire payment is carried out on the processors site, so technically there are no "elements of the payment page (that) originate from the merchant website" - the payment page is all on Amazon, none on your site. So that should also be SAQ A, although it would be really nice if Amazon put this in their FAQ.

Mind you, the distinction between a link that sends customers to the processors site and a link that cites an iframe on the processors site and a link that uses direct post or javascript requests to send card data to the processors site are, in security terms, completely equivalent. In all cases, an attacker who compromises the merchant's web server can affect where the customer sends their card data. The only significant difference is that the customer can see the processor's URL in their address bar with something like "Login and Pay", and we assume people check that and know not to perform Amazon payments with aamazon.ru, even if it has a valid certificate.

Or - in short - if this is confusing to you, it's because it's confusing. Again, best to ask your processor. They're supposed to know better.

If by "Stripe Checkout widget" you mean Checkout, then you're SAQ A-EP, because "elements of the payment page originate from the merchant website."

According to Stripe, even though Checkout is a JavaScript widget "it already rests inside an iframe controlled by Stripe, you can continue to fill out SAQ A." (emphasis mine)

You would only seem to be SAQ A because all your checkout forms were hosted by the processors and your customers were directed to them before checkout or via an iframe .

Long version:

The key distinction here is found in page iii of the SAQ A:

The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s)

If your processors all get invoked via an iframe, then you probably meet this requirement. But if their "javascript widget" or "checkout widget" are served from your servers, then you fall into SAQ A-EP instead. Your processors, of course, should be able to tell which they are.

The fact that the word "Javascript widget" shows up here suggests to me you're A-EP, but I'm not familiar enough with Amazon or Stripe's offerings to really know. And, honestly, you're not really expected to know the difference - they are.

The full set of expectations for a SAQ A merchant to meet are as follows:

SAQ A merchants may be either e-commerce or mail/telephone-order merchants (card-not-present), and do not store, process, or transmit any cardholder data in electronic format on their systems or premises.

SAQ A merchants confirm that, for this payment channel:

• Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
• All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers;
• Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;
• Your company does not electronically 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;
• Your company has confirmed that all third party(s) handling acceptance, storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and
• Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.

Additionally, for e-commerce channels:

• The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).