Can we use SAQ A with a payment processor's iframe, and do we still need ASV scans?

A TPSP iframe loaded directly from the processor is exactly the scoping fact that qualifies you for SAQ A: PCI DSS v4.0.1 SAQ A (r1, effective 31 March 2025) applies where every payment-page element comes "only and directly" from a compliant third-party service provider, either as a redirect/hosted page or as a TPSP iframe loaded directly — with no merchant system electronically touching card data. If any element instead came from, or could be altered by, your own site (direct post, merchant-hosted fields, a proxied/self-served script), you'd be on SAQ A-EP instead. Confirm with your acquirer, since they authorise final SAQ eligibility.

Two things to complete on SAQ A because of the iframe:

1. The 2025 script-attack eligibility criterion. SAQ A r1 removed 6.4.3, 11.6.1 and 12.3.1 as line-item requirements and replaced them with an eligibility statement that your site is not susceptible to script attacks affecting the e-commerce system. That criterion applies specifically to merchants who embed a TPSP form (your case), not to plain redirects. You satisfy it either by deploying 6.4.3/11.6.1-style protections on the embedding page yourself (or through a third party), or by obtaining confirmation from your PCI DSS-compliant processor that the embedded iframe protects against script attacks when implemented per their instructions.

2. ASV scans are still required. SAQ A retains the external vulnerability scan requirement (11.3.2) for merchants using redirects or embedded TPSP iframes, even though payment processing itself is fully outsourced. The scans must be quarterly and run by a PCI SSC-listed Approved Scanning Vendor using its ASV solution — outsourcing the payment form does not remove this obligation.