Your Payment Provider Handles Checkout. So Why Are You Still Being Asked for an ASV Scan?

If your payment provider hosts the checkout page, embeds the payment form, or otherwise handles card processing, being asked for an ASV (Approved Scanning Vendor) scan can feel contradictory. After all, if the provider handles payments, why is the merchant still being asked for a PCI scan? Because outsourcing payment processing does not automatically outsource every PCI DSS responsibility. PCI SSC’s guidance for merchants makes clear that using third parties does not remove the merchant’s obligation to ensure applicable PCI DSS requirements are still met, and the ASV program specifically exists to validate compliance with the external scanning requirement in PCI DSS Requirement 11.3.2.

For further context on recent SAQ A changes affecting e‑commerce merchants, see our blog post ‘PCI DSS SAQ A Update: Changes We Didn’t See Coming’ (/pci-dss-saq-a-update-changes-we-didnt-see-coming).

The Short Answer

Your payment provider may handle the checkout technology, but the merchant is still often responsible for proving that the applicable PCI DSS requirements have been addressed for its environment, its website, and its compliance scope. PCI SSC has clarified SAQ A eligibility for certain e‑commerce merchants using embedded payment pages, reinforcing that merchants still have responsibilities tied to the security of their own webpages.

Why Merchants Are Getting Asked for ASV Scans

PCI DSS requires external vulnerability scans to be performed by an Approved Scanning Vendor for applicable internet‑facing systems under Requirement 11.3.2. These scans identify known vulnerabilities across the payment environment and must be carried out by an ASV solution. Many merchants assume their provider handles this automatically. Sometimes providers do handle parts of it. Sometimes they do not. The real issue is whether the provider is performing the required scanning for all applicable in‑scope external assets and whether that responsibility is clearly documented.

For detailed guidance on external vulnerability scanning and authenticated scanning, read our post ‘PCI Scanning Guide 2026: ASV & Authenticated Internal Scans’ (/pci-scanning-guide-2026-asv-authenticated-internal-scans).

The Real Issue: Who Performs It vs. Who Owns It

This is where teams usually talk past each other. There are really three separate questions: who performs the scan (an ASV with an approved solution), who coordinates the scan (which could be the merchant, the processor, or a managed security partner), and who remains accountable for compliance. Usually, the merchant still needs to show that the requirement has been addressed for its environment and validation path, even when a provider or processor supports the technical side.

For insights into how payment processors can support merchants without removing the merchant’s compliance accountability, see our article ‘How Payment Processors Can Simplify PCI Compliance for Their Merchants Without Compromising Security’ (/how-payment-processors-can-simplify-pci-compliance).

A Common E‑Commerce Example

A merchant uses a third‑party payment provider with an embedded checkout experience on the merchant’s website. The merchant thinks: ‘We never touch card data, so the provider owns this.’ But PCI SSC’s SAQ A clarifications focus on e‑commerce merchants whose webpages include a provider’s embedded payment page or form. That means the merchant’s page can still affect the security of the payment process, which is exactly why these merchants are being scrutinized more closely.

If you are interested in ongoing compliance beyond a single audit, check out our post ‘Beyond the Audit: Continuous Monitoring for PCI DSS Compliance’ (/beyond-the-audit-continuous-monitoring-for-pci-dss-compliance).

What Merchants Should Ask Their Payment Provider

If you are being asked for an ASV scan and your provider handles checkout, ask these questions:

• Are you performing PCI ASV scans for any part of our environment on our behalf?
• Which exact IPs, URLs, or external assets are covered?
• Can you provide documentation showing that coverage?
• Does that coverage include assets on our domain, or only provider‑controlled infrastructure?
• If something is not covered, who owns remediation and rescanning?

Those questions usually surface the real answer quickly.

What Payment Providers Should Make Clear

Payment providers can reduce a lot of friction by being explicit about what they secure, what they scan, what the merchant still owns, what documentation the merchant will need for PCI validation, and whether they provide any assistance with remediation. That is especially important because confusion around shared responsibility is one of the fastest ways for compliance gaps to appear.

The Practical Takeaway

If your payment provider handles checkout, that does not automatically mean they fully own the ASV scan requirement for everything tied to your payment environment. The provider may perform part of the work. The merchant may still need to coordinate part of it. And the merchant will often still need to show that the requirement has been satisfied for its own compliance scope. PCI SSC’s merchant guidance, SAQ A clarifications, and ASV program materials all point in that direction.

How Clone Systems Can Help

Clone Systems helps merchants, processors, and partners clarify external scanning responsibilities by identifying applicable external assets, performing PCI ASV scans where required, and helping teams understand what is covered, what is not, and what documentation is needed for validation. Our guidance aligns with official PCI SSC materials and draws on experience from hundreds of merchants. If your business is being asked for an ASV scan and the answer from your provider is still vague, that is usually the point where scope needs to be clarified.

References

1. PCI Security Standards Council. ‘Approved Scanning Vendor Program.’ Available at https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors/.
2. PCI Security Standards Council. ‘Merchants: Information for Merchants.’ Available at https://www.pcisecuritystandards.org/merchants/.
3. PCI Security Standards Council. ‘FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants.’ Available at https://blog.pcisecuritystandards.org/faq-clarifies-new-saq-a-eligibility-criteria-for-e-commerce-merchants.
4. Clone Systems. ‘PCI DSS SAQ A Update: Changes We Didn’t See Coming.’ Available at /pci-dss-saq-a-update-changes-we-didnt-see-coming.
5. Clone Systems. ‘PCI Scanning Guide 2026: ASV & Authenticated Internal Scans.’ Available at /pci-scanning-guide-2026-asv-authenticated-internal-scans.
6. Clone Systems. ‘How Payment Processors Can Simplify PCI Compliance for Their Merchants Without Compromising Security.’ Available at /how-payment-processors-can-simplify-pci-compliance.
7. Clone Systems. ‘Beyond the Audit: Continuous Monitoring for PCI DSS Compliance.’ Available at /beyond-the-audit-continuous-monitoring-for-pci-dss-compliance.