Does a small business still have to deal with PCI DSS if a processor handles the cards?

Summary

Yes. The PCI Security Standards Council says the standard covers every merchant regardless of size or transaction volume, and handing processing to a third party does not remove the merchant's responsibility. What changes is the workload: a shop that never touches card numbers is mostly checking on its provider and filing a short self-assessment questionnaire, usually SAQ A. Which form applies, and whether one is required at all, is set by the card brands and your acquirer, not by the Council.

Small volume does not mean out of scope

The Council's FAQ puts it directly: PCI DSS is intended for all entities involved in payment processing, including merchants, regardless of their size or transaction volume. Whether a small merchant must validate compliance is decided by the individual payment brands, and the FAQ sends merchants to their acquirer (merchant bank) or the brand for the reporting rules.

Visa says a merchant's total Visa transaction volume over 12 months determines its merchant level and what validation it needs, and that acquirers must make sure their merchants validate at the right level.

Outsourcing everything still leaves four jobs

For a merchant that never stores, processes, or transmits cardholder data itself, the Council's answer is still yes, PCI DSS applies. The merchant's remaining duties, as the FAQ lists them:

The merchant must also validate its own compliance, typically with a self-assessment questionnaire such as SAQ A.

Your checkout decides your form

SAQ A is for sites where every element of the payment page comes from a PCI DSS compliant service provider and nothing on it comes from the merchant's own website. If any element originates from the merchant's site, the merchant moves to SAQ A-EP.

Stripe maps its own products to forms. Checkout and Elements, which put the card fields in an iframe served from Stripe's domain, lead to SAQ A, as do its mobile SDK and Connect. Stripe.js v2 leads to SAQ A-EP. Terminal leads to SAQ C, and keying cards into the Dashboard leads to SAQ C-VT. Sending card numbers straight to the API leads to SAQ D, which Stripe calls the most demanding of the questionnaires. It says a business handling card data directly may face more than 300 security controls.

What changed in SAQ A in 2025

In January 2025 the Council removed the payment-page script requirements (6.4.3 and 11.6.1) from SAQ A and added an eligibility criterion instead: the merchant has confirmed its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The October 2024 version of SAQ A was retired on 31 March 2025.

The criterion applies only to merchants that embed a processor's payment form in their own page, for example in an iframe. It does not apply to merchants that redirect customers to the processor's page, or that fully outsource payment by emailing customers a payment link. A merchant can meet it with its own script protections or with confirmation from the processor that its embedded form includes them.

Some providers charge a PCI fee and some do not; Helcim lists its PCI fee as $0. The fee and the questionnaire are separate matters, and paying one does not file the other.

Sources

Related on this site

Written by Kaz (pen name). Figures are copied from providers' published pricing pages on the dates shown. We have not used these products. Corrections: contact form.