https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf https://www.pcisecuritystandards.org/documents/Understanding... There is a com

https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf https://www.pcisecuritystandards.org/documents/Understanding... There is a comparison of PCI SAQ A and EP, if all you do is link to a 3rd party site (or load an iFrame) and the CC is loaded in that PCI compliant site, you are OK in SAQ A. Stripe.js is tricky. Stripe says their QSA has verified that the new version of Stripe.js will let their merchants qualify for SAQ A since the transport of credit card info happens through a iframe (you can see the updated Stripe.js https://js.stripe.com/v2/stripe-dss3-debug.js https://js.stripe.com/v2/stripe-dss3-debug.js). I personally disagree with that, but Stripe Checkout definitely falls under SAQ A. Per the linked doc: What types of e-commerce implementations are eligible for SAQ A-EP vs. SAQ A? SAQ A: Merchant website provides an inline frame (iFrame)to a PCI DSS compliant third-party processor facilitating the payment process. SAQ A-EP: Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.