PCI ASV Certification: How It Differs From PCI Certified and PCI Compliant
PCI ASV certification explained: how it differs from PCI certified and PCI compliant, who validates each, and how to verify a PCI approved scanning vendor.
PCI compliance for PayPal merchants is one of the most misunderstood parts of running an online business, and the misunderstanding usually starts with a single wrong assumption: that using a trusted, well-known payment platform means compliance is “handled”. It isn’t, not entirely, and the gap between what PayPal secures and what you’re still responsible for is exactly where most merchants get exposed.
The Payment Card Industry Data Security Standard (PCI DSS) applies to every business that stores, processes, or transmits cardholder data, regardless of which processor sits behind the transaction. What PayPal actually changes is scope: how much of your own systems fall under PCI DSS review. That reduction in scope depends entirely on which PayPal integration you use. A merchant using a full redirect checkout, a merchant using PayPal Hosted Fields to keep customers on-site, and a merchant building a custom form with Braintree Direct are all “PayPal merchants”, but each carries a different compliance obligation, and a different SAQ.
This guide sets out exactly what PCI DSS requires of PayPal merchants in 2026: which SAQ applies to which integration, when a quarterly ASV scan is required, what PayPal’s own PCI DSS Level 1 certification does and doesn’t cover, and what changed with PCI DSS v4.0.1. If you’ve been operating on the assumption that PayPal covers all of this for you, this is worth reading in full.
PCI DSS (Payment Card Industry Data Security Standard): a set of security requirements developed by the PCI Security Standards Council (PCI SSC) and enforced contractually by Visa, Mastercard, American Express, Discover, and JCB through your acquiring bank, not a government body.
SAQ (Self-Assessment Questionnaire): the validation tool most Level 2–4 merchants (based on annual transaction volume) use to attest to PCI DSS compliance instead of undergoing a full on-site assessment. There are nine SAQ types; which one applies depends on how your payment page handles cardholder data.
ASV (Approved Scanning Vendor): a company certified by the PCI SSC to run quarterly external vulnerability scans against internet-facing systems that fall inside PCI scope. Required for some SAQ types, not others.
Cardholder Data Environment (CDE): the people, processes, and technology that store, process, or transmit cardholder data, or that are connected to systems that do. The goal of most PayPal integrations is to keep as much of your infrastructure out of the CDE as possible.
PayPal Standard / Smart Payment Buttons: the customer is redirected fully to PayPal's own domain (or a PayPal-hosted overlay) to enter card details. Your servers never touch the payment form.
PayPal Hosted Fields / Advanced Checkout: card fields are rendered inside your checkout page via an iframe served entirely from PayPal's domain, so it looks native to your site, but the code originates from PayPal.
Braintree Direct/custom API integration: your own code builds part or all of the payment form, or your backend calls PayPal or Braintree's API directly. Card data touches your infrastructure in transit even if you never store it.
No. Using PayPal does not automatically make your business PCI compliant; it reduces your compliance scope but does not eliminate your obligations. You still need to complete the correct SAQ, maintain secure systems, and meet your acquiring bank's validation requirements independently.
The core principle behind PCI DSS is that any entity handling cardholder data, directly or indirectly, must meet a defined set of security controls. PayPal’s role is to shrink the amount of cardholder data that ever touches your own environment. By routing sensitive payment information through PayPal’s servers instead of yours, you reduce your cardholder data environment (CDE). A smaller CDE means fewer controls to implement, but a smaller scope is not the same thing as zero scope.
What your obligations actually look like depends on three factors: your annual transaction volume (which sets your merchant level), your PayPal integration method (which sets your SAQ type), and what your acquiring bank specifically mandates on top of the PCI DSS baseline. It’s worth being direct about a risk many small merchants underestimate: non-compliance becomes a problem before a breach ever happens. Acquirers can and do impose monthly non-compliance fees on merchants who fail to validate their SAQ status. If a breach does occur without a documented, current SAQ on file, the financial and reputational fallout is considerably worse.
Get a quick, no-obligation scope check based on your actual integration method.
Yes, PayPal is a certified PCI DSS Level 1 service provider, the highest validation tier available, and it undergoes annual assessments by a Qualified Security Assessor (QSA). But that certification covers PayPal's own infrastructure exclusively. It does not extend to your website, your servers, your staff access controls, or your network.
PayPal publishes its Attestation of Compliance, and its Level 1 status is listed on the major card brands’ registries of validated service providers. That confirms PayPal’s own environment meets the industry’s most rigorous standard. The confusion sets in when merchants interpret that certification as coverage that extends to their business. PCI DSS works on a shared-responsibility model: a service provider’s compliance covers the services that provider delivers, nothing more. Your acquirer doesn’t ask PayPal whether your business is compliant; they ask you directly, and your attestation has to reflect everything outside PayPal’s boundary that still touches your checkout.
Merchants using PayPal's fully hosted checkout, where the customer is redirected entirely to PayPal to enter card details, typically qualify for SAQ A, the shortest and least demanding self-assessment questionnaire available, with no ASV scan required.
SAQ A was built for card-not-present merchants who’ve completely outsourced cardholder data handling to a validated third-party provider. If you use PayPal Standard, Smart Payment Buttons, or PayPal Checkout configured as a full redirect, your website never sees, touches, or stores the card number, expiry date, or CVV; all of it moves directly between the cardholder and PayPal’s servers.
SAQ A contains a comparatively small set of controls: confirming your payment pages haven’t been compromised by web-skimming attacks, that your redirect functions correctly, and that you maintain basic security hygiene around passwords, access control, and incident response. Most of this is manageable for a business already practising reasonable IT security.
What SAQ A doesn’t exempt you from is worth flagging directly: PCI DSS v4.0.1 added a requirement for SAQ A-scoped merchants to implement script monitoring on payment pages, closing a gap that earlier versions left open. If your site runs a CMS, third-party scripts, or plugins near the checkout of WordPress, Shopify, or otherwise, those now factor into your assessment even on the lightest SAQ.
Merchants using PayPal Hosted Fields, where card input fields are embedded directly into your checkout page, carry more compliance scope than full-redirect merchants and typically fall under SAQ A-EP, not SAQ A.
Hosted Fields is popular because it lets merchants keep customers on their own branded checkout without a visible redirect. The fields themselves are served by PayPal as iframes, so card data still goes directly to PayPal, but your page hosts the frames, and your page’s JavaScript environment is responsible for rendering and interacting with them. That involvement is enough to move you into SAQ A-EP territory, which carries substantially more requirements than SAQ A, including vulnerability management, system hardening, and network security controls.
This is also where the 2025–2026 rule change matters most directly. Under PCI DSS v4.0.1’s FAQ 1588, merchants can no longer assume “we use an iframe, so we’re covered”; they need documented confirmation, from PayPal or through their own controls, that script-tampering protections under Requirements 6.4.3 and 11.6.1 are actually in place. Practically, that means confirming in writing with PayPal that its Hosted Fields solution includes these safeguards, verifying the iframe was implemented exactly as PayPal instructs (a modified or wrapped iframe can void eligibility), and documenting this alongside your annual Attestation of Compliance.
AQ A-EP requires quarterly external vulnerability scans from a PCI-approved ASV; this is not optional and cannot be self-certified. SAQ A merchants on a genuine full redirect generally don't need one, since there's no internet-facing system in scope to scan.
Many merchants choose Hosted Fields without realising that the ASV requirement comes attached. They set up the integration, start accepting payments, and assume that because card data ultimately reaches PayPal, they’re in the same compliance position as a merchant using a plain redirect. That assumption is incorrect and leaves a business exposed both to real security risk and to acquirer penalties.
If a scan returns vulnerabilities, they need to be remediated and rescanned before compliance can be validated. For merchants building custom forms and calling PayPal or Braintree’s API directly, scope expands further still, potentially into SAQ D or even a full Report on Compliance, depending on how data is handled. Check PCI ASV scan requirements and what a PCI ASV scan covers before assuming your integration is exempt.
See transparent PCI ASV scan pricing and typical turnaround time.
Once card data reaches your own database, spreadsheets, CRM, or order-management exports, even temporarily, you're generally outside SAQ A or A-EP territory and into SAQ D-Merchant, the longest questionnaire, with mandatory quarterly ASV scanning and documentation across all 12 PCI DSS requirement families.
This trips up merchants who process payment through PayPal correctly but then pull full card numbers into a separate accounting or order system “just in case,” not realizing it changes their entire compliance category. If you’re unsure whether your workflow does this, check whether you need PCI ASV scanning for a quick self-assessment.
Scope each payment channel independently, then let your acquirer confirm the combined picture; don't assume you can default to the shortest applicable SAQ across the board.
PCI compliance for PayPal merchants comes down to one decision more than any other: which integration method you use. A full redirect keeps your compliance scope narrow and typically qualifies for SAQ A with no ASV scan. Hosted Fields expands that scope into SAQ A-EP, bringing mandatory quarterly scanning and a documented script-integrity check under the 2025–2026 FAQ 1588 update. A custom API integration or storing transaction data yourself expands it further still into SAQ D territory.
None of these integration choices is inherently wrong, but each comes with a different set of obligations, and PayPal’s own PCI DSS Level 1 certification, real as it is, doesn’t extend to cover any of them on your behalf. The merchants who run into serious compliance problems are rarely the ones who ignored security on purpose; they’re the ones who assumed a trusted payment brand made the question moot. It doesn’t, and your acquirer won’t accept that as a defence. Confirm your SAQ type, complete it accurately, and if your integration places you in SAQ A-EP or SAQ D scope, get your ASV scan booked with an approved vendor.
Secusy ASV runs acquirer-recognized quarterly scans built for merchants who need accurate results without the runaround.
No. PayPal secures the data that passes through its own systems, which reduces your compliance scope, but you still need to complete the correct SAQ and meet your acquirer's validation requirements.
Yes, PayPal is a certified PCI DSS Level 1 service provider and undergoes annual audits by a Qualified Security Assessor. That certification covers PayPal's infrastructure only, not your website or business systems.
Typically SAQ A, since the customer is redirected entirely to PayPal's domain and your servers never handle card data.
Generally SAQ A-EP, because your page hosts the iframe fields even though card data still goes directly to PayPal. Under PCI DSS v4.0.1's FAQ 1588, you also need documented confirmation of script-tampering protections.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.