Outsourcing card handling earns the simplest PCI paperwork, not none

The workload

PCI DSS version 4.0, published 31 March 2022 per the PCI Security Standards Council's own v4.0 Resource Hub, replaced the prior standard and brought updated Self-Assessment Questionnaires with it — the hub states, verified, that 'SAQs for PCI DSS v4.0 are Now Available.' SAQ A is the track the Council's own materials associate with merchants who hand card data entirely to a third-party service provider (TPSP): a website that redirects payment to a processor like Stripe or Paddle, or embeds a TPSP's hosted payment page in an iframe. The workload is completing that self-assessment and attesting to it, not undergoing an on-site assessment by a Qualified Security Assessor.

What the documents show

Verified, from the Council's own 27 March 2024 SAQ update Q&A: SAQ A gained new obligations for v4.0, including external vulnerability scans 'performed by a PCI Approved Scanning Vendor (ASV)' specifically for merchant websites that redirect to a TPSP or embed a TPSP payment page, plus new policy requirements for protecting paper records containing account data and for password or passphrase security where the merchant uses either. The same source states, verified, that PCI DSS v3.2.1 retired on 31 March 2024, and that requirements flagged as 'future-dated' could be marked 'Not Applicable' only until 31 March 2025, after which they count fully in any v4.0 assessment — SAQ A's easier path still tightened over a documented three-year window, not overnight.

The operating cost

Neither Council page prices an SAQ A assessment; because the merchant self-attests rather than paying an assessor for an on-site review, the direct obligation named is labor — confirming eligibility, completing the questionnaire, and arranging the newly required ASV scan — not a dollar figure. Pricing the scan and the internal time to complete the questionnaire would require quotes this entry did not obtain.

The stop condition

SAQ A eligibility depends on how card data actually flows through a specific integration, not the merchant's size or general intent to outsource. The moment a merchant's own systems store, process, or transmit cardholder data directly rather than fully routing it to a validated TPSP, SAQ A stops applying and a heavier questionnaire governs instead — a distinction grounded in the Council's own description of what SAQ A's redirect-and-iframe-specific scanning requirements address, though the exact boundary for every integration pattern was not fully itemized in the pages retrieved.

• Does the checkout flow actually redirect or embed a TPSP's payment page in every case, or does some path let card data touch the merchant's own servers first?
• Has an ASV scan been arranged for the website, now that SAQ A requires one for redirect and iframe integrations?
• Is the merchant treating a future-dated requirement as optional past its 31 March 2025 deadline, when the Council's own timeline says it no longer can be?

SAQ A is the lightest validation path PCI DSS offers, and the Council's own record shows it is still a moving target: the version that applies, the scans it requires, and the deadline for treating anything as not-yet-applicable have all changed since March 2022.