Merchants often encounter PCI DSS requirements when a processor asks them to complete a questionnaire or an acquirer requests an Attestation of Compliance (AOC). The payment gateway may already have its own compliance documents, yet the merchant is still expected to meet certain requirements. This can be confusing, especially when the provider handles card payments on its own infrastructure.
A PCI DSS-compliant gateway does not automatically make the merchant’s entire payment setup compliant. Even with hosted checkout, some security responsibilities may remain with the business. What matters is how cardholder data moves through the payment process and which systems could affect its security.
The checkout page and its scripts are one place to look. Depending on the setup, call recordings, CRM records, support tickets, refund exports, administrative access, and system logs may also need attention. They do not automatically fall within PCI DSS scope simply because the business uses them. Their relevance depends on whether they store, process, or transmit cardholder data, or could affect its security. Merchants working with several acquirers, virtual terminals, or backup providers also need to understand how responsibilities are divided across their payment integrations.
Hosted payment pages and tokenization can help reduce PCI DSS scope. A compliant gateway can take responsibility for certain parts of the payment environment, but its validation does not automatically extend to everything the merchant operates.
The better question is: which systems and controls are covered by the provider’s validated environment, and which responsibilities remain with the merchant?
What Does PCI DSS Compliance Mean?
PCI DSS stands for Payment Card Industry Data Security Standard — a globally accepted standard to protect payment card data: cardholder data (CHD), such as the card number, and sensitive authentication data (SAD), such as CVV codes, full track data and PINs. This standard was developed and continues to be updated by the PCI Security Standards Council (PCI SSC).
For merchants, PCI DSS compliance means protecting payment card data and applying the relevant security controls to systems that store, process, or transmit it, as well as those that could affect the security of the cardholder data environment. Compliance under the PCI DSS can only be understood in the context of the actual flow of payments rather than the idealized version often found in marketing materials provided by payment providers.
Not storing PAN in a merchant database does not, by itself, determine PCI DSS scope. The assessment must also consider systems that process or transmit cardholder data and those that could affect the security of the cardholder data environment (CDE).
Who PCI DSS Applies To
PCI DSS is applicable to all organizations that store, process, or transmit cardholder data or sensitive authentication data. It also extends to organizations that have an ability to influence the security of that data. That sounds a little abstract, so let’s translate it.
This includes gateways, PSPs, processors, and acquirers. It also covers merchants that accept card payments, such as online stores, marketplaces, and subscription services, along with call centers that take card details by phone. Other service providers, including hosting companies, fraud and chargeback platforms, and token vaults, may also fall within PCI DSS scope if they handle cardholder data or can affect its security.
Being small does not eliminate PCI. It may only change how validation is performed.
A smaller merchant using a hosted checkout may have an easier task than a large merchant holding PAN in-house. Lighter does not mean zero, though.
The 12 PCI DSS Requirements in Plain Language
How many requirements are there for the PCI DSS? The PCI DSS has 12 main requirements. It may seem like the official language is quite dense. However, the true meaning is easier to understand: make sure that the payment environment is controlled, that data is protected, that access is restricted, that actions taken in the environment are monitored, and that security does not become a yearly crisis.
The summaries below are for orientation only and do not replace the full PCI DSS requirements or professional scoping advice.
Payment Gateway vs Payment Processor
| PCI area | Requirement | What it means in merchant work |
|---|---|---|
| Controlled environment | 1. Install and maintain network security controls | Do not leave payment systems sitting in an unmanaged network |
| Secure setup | 2. Apply secure configurations | Remove defaults, harden systems, control changes |
| Stored data | 3. Protect stored account data | Avoid storing PAN; protect it strongly if storage is unavoidable |
| Data in transit | 4. Protect cardholder data during transmission | Use strong cryptography over public networks |
| Malware risk | 5. Protect systems from malware | Use anti-malware controls where they apply |
| Secure software | 6. Develop and maintain secure systems and software | Patch systems, fix vulnerabilities, control payment-page scripts |
| Access | 7. Restrict access by business need to know | Do not give people access "just in case" |
| Authentication | 8. Identify users and authenticate access | Use unique users, strong authentication and MFA where required |
| Physical access | 9. Restrict physical access to cardholder data | Protect offices, devices, media and call-center material |
| Monitoring | 10. Log and monitor system activity | Keep useful logs and review suspicious activity |
| Testing | 11. Test security regularly | Run vulnerability scans, penetration testing and other checks |
| Governance | 12. Support security with policies and programs | Keep policies, vendor oversight and incident response alive |
PCI DSS Compliance Levels 1–4: Find Yours
PCI DSS compliance levels depend on the card network, region, transaction volume, and payment channel. There is no single classification table that applies to every merchant worldwide. The relevant card-network program and acquirer requirements determine which criteria and validation procedures apply.
The tables below illustrate the classifications published in Visa’s UK guidance and Mastercard’s Site Data Protection (SDP) program. They should not be treated as universal thresholds. Always check the current program requirements for your region and acquiring arrangement.
Visa Merchant Levels
According to Visa’s UK security compliance guidance, merchants are classified into four levels based on Visa transaction volume over a 12-month period. The criteria distinguish between transaction volumes across all channels and e-commerce transactions.
| Level | Merchant criteria |
|---|---|
| Level 1 | More than 6 million Visa transactions annually across all channels, or merchants specifically designated as Level 1 under Visa's criteria |
| Level 2 | 1 million to 6 million Visa transactions annually across all channels |
| Level 3 | 20,000 to 1 million Visa e-commerce transactions annually |
| Level 4 | Fewer than 20,000 Visa e-commerce transactions annually, and other merchants processing up to 1 million Visa transactions annually who do not meet a higher-level criterion |
These thresholds reflect the cited Visa guidance. They should not be applied automatically to merchants in other regions without checking the relevant Visa program.
Mastercard Merchant Levels
Mastercard’s Site Data Protection (SDP) Program also uses four merchant levels. Its published guidance calculates transaction volume over the most recent 52-week period and includes combined Mastercard and Maestro transactions.
| Level | Merchant criteria |
|---|---|
| Level 1 | More than 6 million combined Mastercard and Maestro transactions annually, merchants meeting Visa Level 1 criteria, or merchants specifically designated by Mastercard |
| Level 2 | More than 1 million and up to 6 million combined Mastercard and Maestro transactions annually, or merchants meeting Visa Level 2 criteria |
| Level 3 | More than 20,000 and up to 1 million combined Mastercard and Maestro e-commerce transactions annually, or merchants meeting Visa Level 3 criteria |
| Level 4 | Merchants that do not meet the criteria for Levels 1–3 |
Mastercard’s classification can also depend on the merchant’s corresponding Visa level. Therefore, transaction volume alone may not be enough to determine the applicable category.
What Determines Your Validation Requirements?
A merchant’s level does not automatically determine every security control or validation document it needs. The actual payment environment, applicable card-network program, and acquirer’s instructions must also be considered.
Validation may involve an SAQ, AOC, ROC, external vulnerability scans by an ASV, penetration testing, or additional evidence. The required combination depends on the merchant’s environment, assigned validation level, card-network program, and acquirer instructions.
Before starting validation, ask your acquirer to confirm the applicable card-network program, region, merchant level, transaction channels, current program requirements, and required documents in writing.
PCI DSS Certification vs Validation: the Terminology Trap
People often ask about PCI DSS certification or PCI DSS compliance certification. What they usually mean is simple: “What proves we are compliant?” PCI language is more precise. Merchants normally validate compliance. The required validation process depends on the merchant’s environment and the applicable card-network program.
The wording matters because not every “certificate” proves the same thing.
If a provider says, “We have a PCI certificate,” ask what document they mean. Is it an AOC? A ROC? A scan result? A letter? A badge in a portal? What services are covered? What is excluded? Does it apply to the product you actually use?
A generic “PCI certificate” should not be accepted without confirming what assessment was performed, which entity and services were covered, the applicable scope, and the validity period.
Validation: SAQ, AOC, ROC, QSA, and ASV Scans
Validation is evidence. It does not make the environment safe by itself.
- The SAQ (Self-Assessment Questionnaire) is the self-assessment many eligible merchants complete.
- The AOC (Attestation of Compliance) summarizes the assessment result.
- A ROC (Report on Compliance) documents a detailed PCI DSS assessment. The assessment and signing requirements depend on the applicable card-network program. A Qualified Security Assessor (QSA) is an external assessor qualified by PCI SSC to perform PCI DSS assessments.
- An ISA (Internal Security Assessor) is a member of the merchant's staff, certified by PCI SSC to lead internal self-assessment.
- An Approved Scanning Vendor (ASV) performs external vulnerability scans at least quarterly where required by the applicable PCI DSS controls.
A vulnerability scan looks for known issues on exposed systems. Penetration testing goes deeper and asks what could happen if someone actually tried to break in. The common mistake is treating the evidence as the work.
A clean SAQ with the wrong scope is still wrong. A provider AOC covers only the services and environment included in its assessment. A passing ASV scan does not demonstrate compliance with every PCI DSS requirement across the merchant’s environment. Validation is useful when it describes the payment setup you actually run. Otherwise, it is a nice file with a dangerous blind spot.
Universal SAQ Map: Integration Type, Likely SAQ, and Merchant Responsibilities
The right SAQ depends on how card data enters the payment flow and which systems can affect its security. A simple hosted checkout is different from a setup that combines several acquirers, a virtual terminal, backup routing, and phone payments. Each payment channel and integration must be considered when determining the applicable assessment.
The integration type is only a starting point. The applicable SAQ depends on the complete payment architecture and whether all eligibility criteria are met. The final validation path should be confirmed with the acquirer or qualified PCI DSS adviser.
| Integration type | Likely SAQ path | What still needs attention |
|---|---|---|
| Fully hosted payment page with redirect | Often SAQ A, if eligible | Redirects, merchant webpage ASV scans where required, provider AOC, policies |
| Hosted iframe checkout | Often SAQ A, if eligible, but scripts still matter | Script-related eligibility criteria, merchant webpage ASV scans where required, change control, vendor evidence |
| JS library on the merchant domain | Often SAQ A-EP or broader | Web server security, deployment process, scans, script monitoring |
| Direct API with card data passing through merchant systems | Usually SAQ D | Full CDE controls, logging, access, encryption, testing |
| Web-based virtual terminal on an isolated workstation | Often SAQ C-VT if eligible | Workstation security, staff access, no electronic CHD storage |
| Standalone dial-out or imprint terminals only | SAQ B | Paper receipts, device handling, staff process |
| Standalone PTS-approved terminals connected over IP | SAQ B-IP | Terminal isolation from other systems, device inventory |
| Validated P2PE solution listed by PCI SSC | SAQ P2PE | Following the P2PE instruction manual, device inspection |
| MOTO by phone | Depends on capture and storage | Call recordings, staff process, CRM notes, pause-and-resume tools |
| Card data by email | Avoid it; treat as in scope until removed | Email handling, deletion, staff training, documented cleanup |
| Multiple providers and routing | Depends on all paths combined | AOC collection, webhooks, reports, responsibility matrix |
| Merchant stores PAN | Usually SAQ D or ROC path | Encryption, key management, retention, access, monitoring |
What a PCI-Compliant Payment Gateway Covers – and What It Doesn't
A PCI-compliant payment gateway can take a lot of sensitive work away from the merchant. It may provide hosted checkout, iframe checkout, tokenization, provider-side vaulting, secure transmission, payment links, virtual terminal tools, and an AOC for its own environment.
That is valuable. In many cases, it is exactly how a merchant reduces scope. A gateway’s validated environment does not automatically extend to merchant-managed systems and processes. Merchants should review the provider’s AOC and responsibility documentation against their actual payment-data flows to identify any remaining obligations.
Shared Responsibility Should Be Documented for the Actual Setup
PCI DSS responsibilities depend on the services used, the payment-data flow, system access, and contractual arrangements. The merchant should maintain a responsibility matrix showing which controls are performed by each provider, which evidence is available, and which obligations remain with the merchant. The acquirer may define validation requirements, but it does not replace the merchant’s responsibility for its own environment.
What Changed in PCI DSS v4.0.1 for Merchants
PCI DSS v4.0 moved the standard toward more continuous security, clearer service-provider responsibility, stronger authentication, and more flexible ways to meet some controls. PCI DSS v4.0 was retired on December 31, 2024, so v4.0.1 is now the only active version, and requirements 6.4.3 and 11.6.1 became mandatory on March 31, 2025.
For merchants, the biggest practical topic is payment-page security.
Two controls became especially important in e-commerce discussions:
- requirement 6.4.3 – manage and authorize scripts on payment pages;
- requirement 11.6.1 – detect unauthorized changes to payment pages as received by the customer's browser.
For merchants, this is not only a technical detail. Script inventory, script integrity, and change detection can become part of the practical PCI review when the merchant webpage can affect the payment flow.
There is a nuance around SAQ A. In January 2025, PCI SSC removed requirements 6.4.3, 11.6.1, and 12.3.1 from SAQ A and added a new eligibility criterion instead: the merchant must confirm that its site “is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” According to PCI SSC FAQ 1588, this criterion applies to merchants that embed a provider’s payment form (iframe) on their own page, not to redirect-only or fully outsourced setups. A merchant can meet it by applying techniques like those in 6.4.3 and 11.6.1, or by getting confirmation from its PCI DSS-compliant provider that the embedded form protects against script attacks. If the merchant cannot meet the applicable SAQ A eligibility criteria, it should confirm the appropriate validation path with its acquirer or qualified PCI DSS adviser rather than automatically assuming SAQ A-EP applies.
A merchant may not validate those two controls the same way under SAQ A. But if its page sends customers into checkout, scripts on that page still deserve attention. Hosted checkout helps. It does not make the merchant webpage disappear. This area keeps moving – confirm the current position with your QSA or acquirer rather than a saved article.
PCI DSS Compliance Checklist: Step by Step
A practical PCI DSS compliance checklist starts with mapping the actual payment environment, identifying potential exposure to cardholder data, and confirming who is responsible for each applicable control.
- Map the payment environment. List every payment channel and relevant transaction flow: website checkout, mobile apps, payment links, hosted pages, iframes, virtual terminals, phone payments, recurring billing, refunds, backup providers, local payment methods, and secondary acquirers. Identify connected systems, including test environments, admin panels, reporting tools, support platforms, and webhook receivers.
- Identify where cardholder data may appear. Trace cardholder data (CHD) and sensitive authentication data (SAD) through the payment process. Check for PAN in application logs, CRM notes, support tickets, emails, and reporting exports. Make sure CVV is not captured in call recordings or retained after authorization. Review systems that handle card data or could affect its security. Their inclusion in PCI DSS scope depends on their actual role, not simply on whether the business uses them.
- Determine the applicable validation path. Identify the likely SAQ based on the complete payment architecture and eligibility criteria. SAQ A may fit an eligible outsourced e-commerce setup, while SAQ A-EP or SAQ D may apply to other integrations. Confirm the required questionnaire or assessment with your acquirer or qualified PCI DSS adviser.
- Document provider responsibilities and evidence. For each relevant gateway, PSP, processor, hosting provider, token vault, or other service provider, verify which services are covered by its PCI DSS assessment. Obtain current AOCs where applicable, review the scope of validation, and document shared responsibilities. Include backup providers and confirm which obligations remain with the merchant.
- Reduce unnecessary exposure to card data. Use hosted payment pages, suitable iframe integrations, tokenization, and provider-side vaulting where appropriate. Avoid unnecessary PAN storage. Restrict sensitive data in logs, support systems, and exports. Use a secure process for accepting card details by phone, including appropriate call-recording controls. Inventory, authorize, and monitor payment-page scripts where applicable.
- Address security gaps and establish ongoing reviews. Check user access, MFA, system configuration, software updates, change management, vulnerability scanning, and incident-response procedures. Perform ASV scans and other testing where required. Reassess PCI DSS scope when payment integrations, scripts, providers, or internal workflows change.
Do not reuse previous validation answers without checking whether the payment environment and applicable requirements have changed.
PCI DSS compliance requires ongoing security practices, not just annual validation.
Do you have any more questions?
Fill out the form, and we will contact you
*By submitting this application, you consent to the processing of your personal data in accordance with the privacy policy.
Scope Reduction Is a Project, Not a Checkbox
Scope reduction means designing the payment setup so fewer systems can affect cardholder data. Hosted payment pages, iframe checkout, tokenization, end-to-end encryption where appropriate, validated point-to-point encryption in eligible environments, network segmentation, no PAN storage, provider-side vaulting, clean logging rules, and limited admin access can all help.
Scope reduction must be supported by accurate data-flow documentation and clearly defined security boundaries. Changes to integrations, network segmentation, or provider arrangements may affect those boundaries and require reassessment.
PCI DSS With Multiple Providers
High-risk merchants often use more than one provider. That can be smart. One route may work better in one region. Another may serve as backup. A local method may lift approval rates. A second acquirer may protect continuity. Additional payment routes may increase PCI DSS oversight and evidence requirements when they handle cardholder data or can affect the security of the cardholder data environment.
The merchant needs to know which provider handles which payment method, which one touches CHD, which one stores tokens, which one returns masked PAN, which one has a current AOC, which route handles refunds, which systems receive webhooks, and which reports contain payment data.
For multi-acquirer setups, PCI evidence becomes part of payment operations. Approval continuity is useful only if it does not create compliance blindness.
Service Providers Have Their Own PCI Burden
A service provider is not just “a vendor.” In PCI language, a service provider can store, process, or transmit cardholder data for another entity, or affect the security of that data.
Gateways, processors, PSPs, token vaults, hosting providers, fraud platforms, and call-center vendors can all fall into this category depending on what they do.
- Do not stop at "Are you PCI compliant?"
- Ask better questions. Are you a PCI DSS service provider
- Do you have a current AOC?
- Which services are covered? What is excluded?
- What remains our responsibility?
- Can we share your AOC with our acquirer?
- How will you notify us if scope changes?
- Do you support controls related to requirement 6.4.3 and requirement 11.6.1 where applicable?
What Happens If You Do Not Complete PCI Compliance?
PCI SSC writes and maintains the standard. It does not enforce compliance or fine merchants. Enforcement normally moves through payment brands, acquirers, processors, and merchant contracts.
A monthly non-compliance fee is not the same as a breach penalty. The monthly fee is a recurring commercial charge because validation is missing, not because anything has gone wrong yet.
A breach-related cost is different: forensic investigation, deadlines, contractual liability, and much higher costs.
In practice, the cost often moves through this chain: card networks → acquirer → merchant
The merchant may never get a bill directly from the card network. The acquirer can pass costs or obligations down through the merchant agreement. That is why PCI should not be treated as harmless admin work.
PCI DSS and High-Risk Underwriting Are Different Problems
PCI DSS compliance addresses payment-data security. It does not guarantee that an acquirer will approve or continue supporting a merchant’s business model. High-risk underwriting also considers licensing, markets, MCC, chargeback exposure, refund policies, customer verification, prohibited products, traffic sources, and settlement risk.
PCI DSS Compliance and Total Payment Costs
When comparing payment providers, merchants should consider more than transaction fees. The total cost of a payment setup may include PCI DSS assessments, required security scans, integration work, ongoing monitoring, and remediation. These costs depend on the payment architecture, the merchant’s PCI DSS scope, and how responsibilities are divided between the merchant and its service providers.
What BillBlend Helps Merchants Clarify
BillBlend does not make PCI DSS disappear. No responsible provider should promise that.
What BillBlend can help high-risk merchants clarify is the payment architecture around PCI scope: which providers touch the payment flow, which acquirers sit behind the setup, where cardholder data can appear, which integrations can reduce scope, which AOCs should be collected, how routing affects evidence, which checkout components remain under merchant control, and where payment-page scripts create risk.
For high-risk merchants, PCI is rarely a standalone issue. It sits next to approval rate, chargeback control, settlement continuity, routing, and acquirer underwriting.
Talk to BillBlend for a free consultation on your payment setup and what may still remain in your PCI scope.
Frequently Asked Questions
Do I really need PCI compliance?
Yes. If your business accepts card payments, PCI DSS likely applies in some form. A provider may handle the card form, but the merchant may still own website security, scripts, staff access, vendor evidence, and validation.
Can I do PCI compliance myself?
Sometimes. A merchant with a simple outsourced setup may be able to complete the right SAQ without a QSA. A more complex setup may need a QSA, ISA, ASV scans, penetration testing, or outside support. The appropriate validation process depends on the merchant’s PCI DSS scope, assigned level, applicable card-network program, and acquirer requirements.
How do I know if I'm PCI compliant?
To establish PCI DSS compliance, you need to implement the applicable security controls and complete the required validation process. Evidence may include an SAQ or ROC, an AOC, ASV scans, and other assessments where applicable. Confirm the required documents and submission process with your acquirer.
Do I have to pay a PCI compliance fee?
Maybe. Some acquirers and processors charge a PCI program fee or a monthly non-compliance fee if validation is missing. That is separate from the cost of scans, QSA support, remediation, or forensic investigation after a suspected breach.
What happens if I don't complete PCI compliance?
You may face non-compliance fees, acquirer pressure, remediation demands, reserve changes, extra review, or loss of processing access. After a suspected breach, the situation can escalate to forensic investigation and additional costs.
How often is PCI DSS compliance required?
PCI work is continuous. Validation is usually annual, but some activities happen more often: quarterly ASV scans, vulnerability management, access reviews, payment-page monitoring, and provider evidence updates.
