PCI DSS SAQ A for European Online Merchants: Who Still Qualifies Under v4.0.1?

PCI DSS SAQ A remains an option for eligible European online merchants that outsource all account data processing to compliant third-party service providers and do not electronically store, process, or transmit account data within their own systems. However, using an external payment provider does not automatically qualify a merchant for SAQ A. Eligibility depends on the payment integration, the merchant's website functionality, applicable PCI DSS requirements, and confirmation from the acquiring bank or payment brand where required.

Under PCI DSS v4.0.1, merchants must pay particular attention to the security of e-commerce payment pages. The revised SAQ A eligibility criteria introduced a specific condition concerning protection against attacks involving merchant website scripts that could affect the e-commerce system. European merchants using hosted checkout pages, redirects, embedded payment forms, or third-party payment platforms should therefore verify their exact payment flow before selecting a Self-Assessment Questionnaire.

Protect cardholder data and strengthen payment security with INTERCERT’s PCI DSS Assessment Services. Connect with our team to discuss your compliance requirements.

What Is PCI DSS SAQ A?

PCI DSS SAQ A is a Self-Assessment Questionnaire designed for merchants that outsource all account data functions to PCI DSS-compliant third-party service providers and meet the questionnaire's specific eligibility conditions. It applies primarily to card-not-present transactions, including online payments, where the merchant does not electronically store, process, or transmit account data in its own environment.

For European e-commerce businesses, SAQ A can be relevant when a payment service provider manages the payment collection and processing functions. The merchant remains responsible for ensuring that its payment arrangements meet the applicable eligibility criteria and that its own website and business practices satisfy the requirements included in the selected questionnaire.

SAQ A is not a general exemption from PCI DSS. Merchants must complete the applicable validation process, retain appropriate evidence, and submit the required compliance documents according to their acquirer's or payment brand's instructions.

Purpose of SAQ A for E-Commerce Merchants

The purpose of SAQ A is to provide a validation route for eligible merchants whose payment processing functions are fully outsourced and whose environments have a limited role in handling account data. Instead of managing the entire payment card processing environment, the merchant relies on a third-party provider to perform the relevant payment functions.

For example, a European online retailer may redirect customers to a payment provider's hosted checkout page. The provider collects the payment details and processes the transaction, while the retailer's website manages products, orders, and customer communications. If the arrangement satisfies every SAQ A eligibility condition, the retailer may qualify for this questionnaire.

However, the merchant must evaluate more than the provider's role. Website scripts, payment page functionality, the handling of payment information, and the provider's PCI DSS status can all affect the merchant's obligations.

How SAQ A Differs from SAQ A-EP and SAQ D

SAQ A is intended for eligible merchants that outsource all account data processing and meet the questionnaire's restricted scope conditions. SAQ A-EP applies to certain e-commerce merchants that outsource payment processing but operate websites capable of affecting the security of payment transactions. SAQ D is a broader questionnaire for merchants that do not qualify for a more specific SAQ or that have more extensive account data responsibilities, subject to the applicable validation framework.

A redirect-based payment arrangement may qualify for SAQ A if all relevant criteria are met. A merchant whose website generates payment forms or directly influences how payment data reaches the provider may fall within SAQ A-EP instead. Merchants that electronically store, process, or transmit account data, or that fail to qualify for another applicable questionnaire, may need SAQ D.

The correct questionnaire depends on the actual payment architecture and the applicable eligibility conditions, not simply on the size of the business or the name of its payment provider.

PCI DSS SAQ A v4.0.1 Changes

PCI DSS v4.0.1 introduced a significant clarification to SAQ A eligibility for e-commerce merchants. The revised criteria address the risk that scripts running on a merchant's website could be manipulated to affect the security of an e-commerce payment transaction.

This distinction matters because a merchant can outsource payment processing while still operating a website that influences the payment experience. An attacker might compromise website content or scripts to redirect customers, alter checkout behaviour, or expose payment information. Outsourcing payment processing does not automatically remove these risks.

Merchants should therefore review the applicable SAQ A v4.0.1 eligibility criteria against their current checkout architecture rather than relying on an earlier questionnaire or a provider's general statement that its payment platform is compliant.

Key Differences Between v3.2.1 and v4.0.1

PCI DSS v4.0.1 is a limited revision of PCI DSS v4.0, rather than an entirely new standard. For SAQ A, the important eligibility development for e-commerce merchants is the explicit focus on protecting payment pages against attacks originating through scripts that could affect the transaction.

Under the earlier PCI DSS v3.2.1 framework, merchants assessed eligibility against the criteria applicable to that version. PCI DSS v4.0 and v4.0.1 brought revised requirements and validation considerations, including greater attention to e-commerce payment page security.

The PCI DSS v4.0.1 SAQ A eligibility criteria require merchants to confirm that their websites are not susceptible to attacks from scripts that could affect their e-commerce systems. The precise wording and applicable validation expectations should be checked against the official questionnaire version being used.

Merchants should not assume that an arrangement accepted under an earlier version remains eligible without review. The current payment setup, applicable requirements, and acquirer expectations must determine the correct validation route.

PCI DSS SAQ A Revised Eligibility Criteria

The revised eligibility criteria focus on whether the merchant outsources all account data processing, avoids electronic storage, processing, and transmission of account data in its own systems, and meets the applicable e-commerce payment page security condition.

For e-commerce merchants, this means examining how the checkout page is created, whether merchant-controlled scripts can influence payment transactions, and whether the selected payment integration meets the questionnaire's specific conditions.

A merchant using a third-party hosted payment page may be eligible, but eligibility is not established solely by the provider's compliance status. The merchant must also satisfy the other SAQ A conditions and follow the validation process specified by its acquiring bank or payment brand.

Why These Changes Matter for Online Merchants

The revised criteria reflect the reality that attackers can target the merchant's website even when payment details are collected by an external provider. Malicious scripts, compromised website components, and unauthorised changes to checkout functionality can expose customers to payment fraud.

For European merchants, these risks are relevant across cross-border e-commerce operations, including businesses serving customers in multiple European Economic Area countries and the United Kingdom. Different payment methods and website configurations can create different security responsibilities, even when the same provider processes transactions.

Reviewing SAQ A eligibility can also reduce the risk of submitting an inappropriate questionnaire. Selecting an SAQ that does not match the payment environment can lead to additional validation work, delays, and questions from the acquiring bank.

PCI DSS SAQ A v4.0.1 Eligibility Criteria

To qualify for PCI DSS SAQ A v4.0.1, a merchant must meet every applicable eligibility condition in the current questionnaire. The central conditions concern full outsourcing of account data processing, the absence of electronic storage, processing, or transmission of account data within the merchant's environment, and the applicable security conditions for e-commerce payment pages.

Merchants should evaluate the actual data flow between their website, payment provider, hosting platform, and other connected services. A payment provider's PCI DSS compliance does not establish that the merchant independently meets every SAQ A criterion.

Core Eligibility Conditions for Merchants

The principal eligibility conditions for SAQ A include the following:

• The merchant accepts only card-not-present transactions, as defined by the applicable questionnaire.
• All account data processing is outsourced to PCI DSS-compliant third-party service providers.
• The merchant does not electronically store, process, or transmit account data on its systems or premises.
• The merchant confirms that its service providers meet the applicable PCI DSS requirements and that the merchant's arrangements satisfy the questionnaire's conditions.
• For e-commerce merchants, the website meets the applicable eligibility condition concerning susceptibility to attacks from scripts that could affect the e-commerce system.
• The merchant meets every other eligibility statement in the current SAQ A and follows the validation instructions issued by its acquirer or payment brand.

These conditions must be considered together. Meeting only some of them does not establish eligibility.

Full Outsourcing of Cardholder Data Functions

Full outsourcing means that the relevant account data processing functions are performed by an eligible third-party service provider rather than by the merchant's own environment. For example, an online retailer may use a hosted checkout service that collects card details and processes payments without exposing those details to the retailer's systems.

Merchants must understand what the provider actually handles. A contract stating that a company uses a payment service provider is not sufficient if the merchant's own website or infrastructure still collects, processes, or transmits account data.

Businesses should also verify the provider's PCI DSS compliance status and determine which responsibilities remain with the merchant. Outsourcing reduces the merchant's direct involvement in payment processing, but it does not eliminate all PCI DSS responsibilities.

No Electronic Storage, Processing, or Transmission of Cardholder Data

SAQ A eligibility requires that the merchant does not electronically store, process, or transmit account data within its own systems or premises. A properly configured hosted payment page can keep sensitive payment information within the provider's environment, provided the merchant's actual transaction flow meets the questionnaire's criteria.

For instance, if customers enter their card details on a payment page operated by a third-party provider, and those details do not pass through the merchant's systems, the arrangement may meet this part of the eligibility test.

Merchants should check website forms, server logs, analytics integrations, customer relationship management platforms, order systems, and payment APIs. Unexpected collection or transmission of payment information through these components can affect eligibility.

The terms used in PCI DSS also matter. Account data includes cardholder data and, where applicable, sensitive authentication data. Merchants should assess the exact data handled by each system rather than assuming that removing the full card number from the main database resolves every issue.

Protection Against Script-Based Attacks on Payment Pages

The PCI DSS v4.0.1 SAQ A eligibility criteria include a condition addressing whether the merchant's website is susceptible to attacks from scripts that could affect the e-commerce system. This is particularly relevant when merchant-controlled website components interact with or influence the payment experience.

Third-party JavaScript, tag managers, advertising scripts, analytics tools, content management systems, and checkout-related plugins can introduce risks if they are compromised or changed without authorisation. An attacker could potentially modify a payment journey, direct customers to a fraudulent page, or interfere with payment-related interactions.

Merchants should review the controls applicable to their website and verify how the current SAQ A criteria apply to their particular integration. Where the required condition cannot be met, the merchant should not assume that SAQ A remains appropriate merely because payment processing is outsourced.

The exact applicable requirements and validation approach should be confirmed using the current PCI DSS v4.0.1 questionnaire and the merchant's acquirer.

Who Qualifies for PCI DSS SAQ A v4.0.1?

European online merchants may qualify for SAQ A when their payment setup meets every eligibility condition in the current questionnaire. Common examples include merchants using a third-party hosted checkout page or a qualifying redirect-based payment flow that keeps account data processing outside the merchant's environment.

However, the technology label alone does not determine eligibility. A redirect, embedded iFrame, hosted checkout, or third-party payment service must be evaluated according to how it is configured and how payment data flows through the merchant's website.

Merchants Using Redirect-Based Payment Pages

A redirect-based payment page sends the customer from the merchant's website to a payment page operated by a third-party provider. The provider collects the card details and processes the transaction, while the merchant typically receives the transaction result and relevant order information.

This model can be suitable for SAQ A when the provider performs all relevant account data processing, the merchant does not electronically store, process, or transmit account data, and every other eligibility condition is satisfied.

Merchants should verify that the redirect destination is authentic, that the website cannot be manipulated to direct customers to a fraudulent payment destination, and that the integration does not introduce additional account data handling within the merchant's environment.

A redirect alone is not proof of compliance. The complete payment flow and the applicable SAQ A criteria determine eligibility.

Merchants Using Embedded iFrames

An embedded iFrame allows a third-party payment provider's payment form to appear within the merchant's checkout page. Customers can enter payment details without leaving the merchant's website, while the provider's system handles the payment information.

An iFrame-based integration may qualify for SAQ A when all applicable conditions are met. The merchant must establish that the payment form and its integration satisfy the questionnaire's criteria and that the merchant's website meets the applicable protection condition concerning script-based attacks.

The distinction between the provider's payment form and the merchant's surrounding page is important. A compromised merchant website could potentially change the checkout experience or influence where customers submit payment information, even if the card details are entered into a provider-hosted form.

Merchants using iFrames should therefore review the actual integration, the scripts running on the website, and the applicable requirements before selecting SAQ A.

Merchants Using Third-Party Payment Service Providers

Merchants using third-party payment service providers may qualify for SAQ A when the provider performs all relevant account data processing and the merchant meets every other eligibility condition.

European businesses may use international payment platforms, local acquiring services, hosted checkout providers, or payment gateways that serve multiple countries. The provider's geographic presence does not determine SAQ eligibility. The relevant factors are the services performed, the data flow, the provider's PCI DSS status, and the merchant's own responsibilities.

Merchants should obtain appropriate evidence of the provider's compliance status and determine which responsibilities remain within their own environment. They should also verify that the payment integration does not cause account data to enter merchant-controlled systems.

Who No Longer Qualifies for SAQ A?

A merchant may not qualify for SAQ A if its payment architecture or website fails to meet any required eligibility condition. Common concerns include handling account data within the merchant's environment, operating an integration that does not meet the applicable e-commerce eligibility criteria, or relying on a provider without the required compliance status.

A business does not necessarily need SAQ D simply because SAQ A is unavailable. The correct questionnaire depends on the merchant's actual payment flow and the eligibility conditions for other SAQs.

Merchants Whose Websites Can Affect Payment Page Security

Merchants whose websites can be exploited through scripts that affect e-commerce payment security must pay particular attention to the revised SAQ A eligibility condition. The relevant issue is whether the website satisfies the applicable criteria, not simply whether the payment form is hosted externally.

For example, a compromised content management system, vulnerable checkout plugin, or unauthorised script change could affect the payment experience. If the merchant cannot meet the relevant SAQ A condition, it should determine whether another questionnaire applies.

Merchants should assess their specific environment against the current PCI DSS requirements rather than assuming that a hosted payment provider removes the website from consideration.

Merchants Using Direct Post or API-Based Payment Methods

Direct post and API-based integrations require careful examination because their data flows can differ substantially from a fully hosted redirect or payment form.

In a direct post configuration, the merchant's website may generate the payment form while the customer's browser sends payment information directly to the payment provider. In an API-based arrangement, the merchant's application may interact with the provider's services in different ways, potentially involving account data within merchant-controlled systems.

These arrangements do not automatically qualify for SAQ A. If the integration causes the merchant's systems to store, process, or transmit account data, or if the merchant fails another eligibility condition, a different questionnaire may be necessary.

The merchant should map the actual transaction flow and confirm the appropriate SAQ with its acquirer. The integration method's name alone cannot establish eligibility.

Merchants Handling Cardholder Data in Their Own Environment

Merchants that electronically store, process, or transmit account data within their own environment generally do not meet SAQ A's corresponding eligibility condition.

Examples may include a merchant application that receives full card details, a database that stores payment card numbers, or a system that routes account data through merchant-controlled infrastructure. Even if an external payment provider performs final authorisation and settlement, the merchant's own handling of the data can change its PCI DSS scope.

Such merchants should evaluate the applicable questionnaire for their actual environment. SAQ D may be relevant for merchants that do not meet the criteria for a more specific SAQ, but the correct validation route must be determined from the current PCI DSS framework and the acquirer's requirements.

Moving from SAQ A to SAQ A-EP or SAQ D

A merchant may need to change questionnaires when its website, payment integration, or account data handling no longer meets SAQ A eligibility criteria.

SAQ A-EP may be relevant to certain e-commerce merchants that outsource payment processing but retain website functions capable of affecting the security of payment transactions. SAQ D may apply when the merchant has broader account data responsibilities or does not qualify for another questionnaire.

The transition should be based on the current payment architecture, not on assumptions about which questionnaire is easier to complete. Merchants should review any changes to checkout technology, payment APIs, hosting arrangements, and third-party integrations before the next compliance validation.

PCI DSS SAQ A Eligibility Requirements for E-Commerce

PCI DSS SAQ A eligibility for e-commerce depends on both the payment processing arrangement and the merchant's website security. A merchant may outsource card data collection while still operating web pages, scripts, or applications that affect how customers reach the payment provider.

For this reason, European online merchants should evaluate the entire customer journey from the product page to payment completion. The review should identify where payment data is entered, which systems receive it, and whether website components can influence the payment transaction.

Checkout Page Setup and Payment Page Integration

The checkout configuration determines how payment details move between the customer, merchant, and payment service provider. A hosted redirect may keep account data outside the merchant's environment, while a merchant-generated payment form or a custom API integration may introduce additional responsibilities.

Merchants should identify whether their website creates the payment form, embeds provider-controlled content, generates payment tokens, or sends payment-related requests through a backend application. Each component should be assessed according to its actual role.

The final decision must reflect the applicable SAQ A eligibility criteria and the merchant's complete payment flow. A simple checkout design is not automatically a compliant one.

Third-Party Scripts on Payment Pages

Third-party scripts can create security risks when they run on pages involved in the payment journey. Analytics tags, advertising scripts, chat widgets, customer experience tools, and marketing integrations may change over time or introduce dependencies outside the merchant's direct control.

Merchants should maintain an understanding of which scripts load on relevant pages, why they are required, and whether they can influence payment-related interactions. Unnecessary scripts should be removed, while necessary scripts should be governed by appropriate security controls.

The revised SAQ A eligibility criteria make payment page security especially important for e-commerce merchants. Businesses must determine how the applicable condition is satisfied in their environment and should not treat third-party payment hosting as a substitute for website security.

Website Hosting and Platform Considerations

Website hosting and e-commerce platforms can influence the security and scope of a payment environment. A hosted commerce platform may provide built-in payment integrations, but the merchant must still establish whether its selected configuration meets SAQ A eligibility conditions.

Businesses using content management systems, custom storefronts, plugins, or externally hosted applications should consider how software updates, administrator permissions, scripts, and checkout settings are managed. Unauthorised changes or compromised components may affect payment security.

Merchants should also review any platform-specific statements about PCI DSS. A platform's compliance status does not automatically establish the merchant's eligibility for a particular SAQ.

PCI DSS SAQ A Eligibility for European Merchants

PCI DSS SAQ A eligibility for European merchants follows the applicable PCI DSS questionnaire criteria rather than a separate European version of SAQ A. Businesses operating in the European Union, European Economic Area, and United Kingdom should evaluate their payment arrangements against the relevant PCI DSS requirements and their acquiring bank's validation process.

European data protection and financial regulations may impose additional obligations depending on the merchant's activities, location, and role. However, GDPR compliance and PCI DSS compliance are distinct. Meeting one framework does not automatically satisfy the other.

Common Payment Setups Among European Online Merchants

European online merchants use a range of payment configurations, including hosted checkout pages, redirect-based payment services, embedded iFrames, digital wallets, and integrations with local or international payment providers.

A retailer serving customers in Germany, France, Spain, Italy, the Netherlands, or other European markets may use the same payment provider across multiple storefronts. However, differences in website configuration, local payment methods, and transaction routing may affect the merchant's PCI DSS responsibilities.

Each payment method should be evaluated according to the information collected, the systems involved, and the applicable eligibility conditions. Merchants should avoid applying one SAQ decision to every storefront without confirming that their payment environments are equivalent.

Cross-Border Sales and Multi-Country Payment Flows

Cross-border e-commerce does not automatically disqualify a merchant from SAQ A. A business selling across multiple European countries may still qualify if its payment environment satisfies the questionnaire's requirements.

However, a company operating separate websites, regional storefronts, local checkout pages, or different payment providers should establish whether each environment follows the same payment architecture. A change in the way account data is collected or transmitted can affect the appropriate validation route.

Businesses should also distinguish between PCI DSS obligations and other regulatory requirements. GDPR, national privacy laws, and applicable financial sector rules may affect how customer information is handled, but they do not replace PCI DSS eligibility criteria.

Role of Acquirers and Payment Brands in Confirming Eligibility

The merchant's acquiring bank or payment brand determines the applicable validation process within its relevant programme. Merchants should confirm which SAQ they are expected to submit, the reporting period, the required Attestation of Compliance, and any additional evidence or deadlines.

A payment service provider may explain its integration and compliance status, but its statement does not necessarily settle the merchant's SAQ eligibility. The merchant must assess its own environment and confirm the required validation route with the relevant acquiring party.

Where the payment architecture is complex or the eligibility criteria are unclear, merchants should seek a formal determination from their acquirer before submitting a questionnaire.

PCI DSS SAQ A Requirements for Online Merchants

PCI DSS SAQ A requirements for online merchants are limited to the requirements included in the applicable questionnaire and the responsibilities arising from the merchant's payment environment. Eligibility for SAQ A does not mean that every PCI DSS requirement applies directly to the merchant in the same way it would to a business processing card data internally.

Merchants must complete the relevant questionnaire accurately, confirm that their service providers meet applicable obligations, and maintain the records needed for their validation process. They should also review changes in their payment environment that could affect their eligibility.

Applicable PCI DSS v4.0.1 Requirements

Merchants should use the current PCI DSS v4.0.1 SAQ A and its eligibility statements to determine the requirements applicable to their environment. The questionnaire should be treated as a defined validation document, not as a substitute for understanding the merchant's payment architecture.

The applicable requirements may address responsibilities associated with third-party providers, the merchant's website, and the security conditions specified in the questionnaire. Merchants should answer each applicable question based on evidence rather than assumptions.

Where a requirement does not apply, the merchant should follow the questionnaire's instructions for recording that determination. If the business cannot meet an eligibility condition, it should confirm whether another SAQ or validation method is required.

Third-Party Service Provider Responsibilities

Merchants must identify the third-party service providers involved in payment processing and understand their respective responsibilities. This may include payment gateways, hosted checkout providers, payment processors, e-commerce platforms, and other services that can affect the security of payment transactions.

The merchant should verify the provider's relevant PCI DSS compliance status and understand which responsibilities remain with the merchant. Depending on the arrangement, written agreements, provider compliance records, and clear responsibility allocations may be relevant to the validation process.

Outsourcing payment processing does not transfer every merchant obligation to the provider. The merchant remains accountable for selecting the appropriate questionnaire and meeting the responsibilities that apply to its own environment.

Vulnerability Management and Secure Systems

Secure website and application management remain important for merchants that rely on third-party payment processing. Vulnerabilities in the merchant's website, plugins, hosting configuration, or administrative systems can create opportunities for attackers to interfere with the payment journey.

Merchants should apply relevant security updates, restrict unnecessary software components, monitor significant changes, and maintain appropriate controls over their web applications. The exact PCI DSS obligations depend on the applicable requirements and the systems within scope.

These practices should be aligned with the merchant's actual environment and the current SAQ A criteria. Businesses should not assume that the limited scope of SAQ A removes the need to maintain secure website operations.

Access Control and Authentication

Administrative access to e-commerce platforms, hosting environments, checkout configurations, and related services should be restricted to authorised users. Strong authentication and appropriately assigned permissions can reduce the risk of unauthorised changes to payment-related pages.

Merchants should review who can modify checkout settings, install plugins, change website scripts, or access payment integrations. Access should reflect business responsibilities, and accounts that are no longer required should be removed or disabled according to the organisation's procedures.

The specific access control requirements applicable to an SAQ A merchant should be determined from the current questionnaire and any other PCI DSS responsibilities relevant to its environment.

PCI DSS SAQ A Payment Processing Requirements

PCI DSS SAQ A payment processing requirements centre on understanding the merchant's payment flow, confirming that all account data processing is outsourced as required, and validating that the merchant meets the questionnaire's eligibility criteria.

A merchant should be able to explain how a customer initiates a payment, where the customer enters card details, which provider receives the information, and what transaction data returns to the merchant. This understanding is essential when determining the appropriate SAQ.

Mapping Payment Flows for SAQ A Merchants

A payment flow describes how payment information moves from the customer to the merchant and the payment provider. Mapping the flow helps identify whether the merchant's website, backend applications, or other systems handle account data.

For a redirect-based transaction, the customer may select a payment method on the merchant's website and then enter card details on the provider's hosted page. The provider processes the transaction and returns a result to the merchant. In another arrangement, an embedded form or API may introduce different technical interactions that require closer examination.

Merchants should document the relevant components, data exchanges, and third-party services. If any system within the merchant's environment receives account data, the business should evaluate how that affects SAQ A eligibility before proceeding.

Validating Payment Service Provider Compliance

Merchants should verify that each relevant payment service provider has the required PCI DSS compliance status. The provider's current compliance documentation should correspond to the services it performs and the role it plays in the payment environment.

Businesses should also establish whether the provider's compliance status covers the relevant service and whether the merchant has responsibilities that remain outside the provider's scope. A general claim that a provider is secure or certified should not replace verification of its applicable PCI DSS status.

Where multiple providers are involved, the merchant should identify their individual roles and confirm the status of each relevant service.

Merchant and Provider Responsibility Matrix

Although a responsibility matrix can be maintained as an internal record, it does not replace the official SAQ or the merchant's validation obligations. Its purpose is to clarify who manages each relevant payment and security function.

The payment provider may manage card data collection, payment processing, transaction authorisation, and certain technical controls. The merchant may remain responsible for website security, access to its e-commerce platform, selecting authorised integrations, monitoring changes, and completing the applicable compliance validation.

Responsibilities vary according to the provider agreement and the technical configuration. Merchants should record the actual allocation of responsibilities and confirm that no required activity has been overlooked.

How to Confirm Whether Your Business Qualifies for SAQ A

A European online merchant should confirm SAQ A eligibility by comparing its current payment environment with every applicable eligibility statement in the PCI DSS v4.0.1 SAQ A. The decision should be based on the actual transaction flow, the systems that handle account data, the payment provider's compliance status, and the applicable website security condition.

A merchant should not select SAQ A solely because its payment provider recommends it or because the business does not store card numbers in its primary database.

Eligibility Review Checklist

Before selecting SAQ A, merchants should verify the following points:

• The business accepts only the transaction types permitted by the questionnaire.
• All account data processing functions are outsourced to PCI DSS-compliant third-party service providers.
• The merchant does not electronically store, process, or transmit account data within its systems or premises.
• The website and payment integration meet the applicable SAQ A e-commerce security eligibility condition.
• The merchant understands the responsibilities retained by its own organisation.
• All applicable eligibility statements in the current SAQ A are satisfied.
• The acquiring bank or payment brand has confirmed the required validation process where necessary.

If any condition remains uncertain, the merchant should resolve the uncertainty before submitting the questionnaire.

Evidence and Records to Retain

Merchants should retain records that substantiate their eligibility and compliance statements. Depending on the environment and the applicable validation process, these may include the provider's PCI DSS compliance records, payment flow diagrams, descriptions of the checkout configuration, relevant provider agreements, and records of website security controls.

The merchant should also retain its completed SAQ, Attestation of Compliance, and related validation records according to the acquirer's instructions and applicable contractual obligations.

Evidence should reflect the actual payment environment during the relevant validation period. If the business changes its provider, checkout integration, or website architecture, it should review whether the change affects SAQ eligibility.

When to Seek Confirmation from Your Acquirer

Merchants should contact their acquiring bank or relevant payment brand when they are unsure which questionnaire applies, when the website architecture does not clearly meet the eligibility criteria, or when payment processing responsibilities are shared across several providers.

Confirmation is particularly important for direct post integrations, custom payment APIs, embedded payment forms, and websites that load scripts capable of affecting the checkout experience.

The merchant should provide a clear description of the payment flow and the systems involved. This allows the relevant acquiring party to determine the appropriate validation route based on the applicable programme requirements.

Common Mistakes When Selecting SAQ A

The most common mistake is treating SAQ A as the default questionnaire for every merchant that uses an external payment provider. Eligibility depends on the complete payment environment and every applicable condition in the current questionnaire.

Merchants can avoid unnecessary validation problems by reviewing their payment architecture, checking provider compliance status, and confirming the appropriate SAQ before submitting their compliance documents.

Assuming Every Redirect or iFrame Setup Qualifies

A redirect or iFrame may reduce the merchant's direct handling of payment data, but neither technology automatically establishes SAQ A eligibility. The merchant must confirm that all account data processing is outsourced as required and that the website meets the relevant security conditions.

For example, a merchant may use a provider-hosted iFrame while retaining scripts on the surrounding page that can affect the payment experience. That configuration requires an evaluation against the current eligibility criteria rather than an automatic approval based on the presence of an iFrame.

Overlooking Third-Party Scripts

Third-party scripts are frequently added to e-commerce websites for analytics, advertising, personalisation, and customer engagement. Over time, these integrations can increase complexity and introduce additional risks to pages involved in payment transactions.

Merchants should maintain visibility into relevant scripts, restrict unnecessary integrations, and manage changes to payment-related pages. They should also determine how the applicable SAQ A condition concerning script-based attacks is met.

Misunderstanding Provider Compliance Responsibilities

A payment provider's PCI DSS compliance status does not automatically establish that the merchant is compliant or eligible for SAQ A. The provider's role, the services covered by its compliance status, and the responsibilities retained by the merchant must all be understood.

Merchants should verify the provider's relevant compliance records, establish the division of responsibilities, and complete the questionnaire appropriate to their own environment.

Preparing for PCI DSS v4.0.1 compliance? Engage INTERCERT for independent PCI DSS Assessment and QSA services to evaluate your payment security controls.

Completing and Submitting SAQ A

Eligible merchants must complete the applicable PCI DSS SAQ A, provide the required Attestation of Compliance, and follow the submission process specified by their acquiring bank or payment brand. The process and deadlines can vary according to the merchant's acquiring arrangements and the relevant payment programme.

Before submitting the questionnaire, the merchant should verify its eligibility, ensure that responses accurately reflect the current environment, and retain the evidence required for the validation process.

Attestation of Compliance Process

The Attestation of Compliance records the merchant's declaration concerning the applicable PCI DSS validation. Merchants should complete the relevant attestation according to the instructions supplied with the questionnaire and the requirements of the receiving party.

The completed SAQ and attestation should accurately reflect the merchant's payment environment. The business should not submit an SAQ A simply because it is shorter than another questionnaire or because a provider has suggested that it may apply.

Where the merchant cannot confirm eligibility or has unanswered questions about its payment architecture, it should resolve those issues before making its compliance declaration.

Annual Validation Expectations

Merchants are commonly required to validate PCI DSS compliance annually, although the precise validation schedule and submission requirements depend on the acquiring bank, payment brand, and applicable programme.

For an eligible SAQ A merchant, annual validation generally involves completing the current applicable questionnaire, providing the required attestation, and meeting the acquirer's submission instructions. Merchants should also review significant changes to their payment provider, website, checkout integration, or account data handling between validation periods.

If a change affects eligibility, the merchant should reassess the appropriate questionnaire rather than waiting until the next annual submission.

Read More:
Minimizing PCI DSS Scope for SoftPOS and Tap-to-Pay Systems
What Are the Requirements of PCI DSS Compliance