SAQ A vs SAQ A-EP Under PCI DSS v4.0.1: How Your Checkout Embed Method Decides Your Compliance Burden

Two ecommerce sites can use the same payment processor but face very different PCI DSS obligations because their checkout pages are built differently. A redirect to a processor-hosted page, a third-party iframe, and an embedded JavaScript card form may look almost identical to shoppers while creating materially different security responsibilities for the merchant.

That distinction is central to understanding SAQ A vs SAQ A-EP. The correct Self-Assessment Questionnaire is not determined by a gateway’s marketing name, whether a plugin says “secure checkout,” or whether tokenization happens somewhere in the transaction. It depends on the merchant’s actual architecture and whether every applicable eligibility criterion is satisfied.

A useful way to investigate an ecommerce integration is:

Checkout Architecture → Who Serves the Payment Elements? → Where Does Card Data Flow? → Can Merchant Systems Affect Security? → SAQ Eligibility → Required Controls → Validation

The broad principle is straightforward: the more control the merchant’s website has over the payment page, cardholder-data flow, or systems that can affect payment security, the greater the potential PCI DSS scope and compliance burden.

Think of checkout methods as a conceptual spectrum:

Full Hosted Redirect → Third-Party Hosted iFrame → Embedded Third-Party Components → Merchant-Controlled Payment Page → Direct Card Data Handling

This spectrum is useful for understanding risk, but it is not an SAQ selector. PCI DSS SAQ eligibility must always be evaluated against the current official criteria.

PCI SSC describes SAQs as validation tools for eligible organizations, and its current documentation emphasizes that merchants should confirm eligibility before beginning an assessment and consult the entity receiving the validation when necessary.

What Are SAQ A and SAQ A-EP?

The Self-Assessment Questionnaire A and Self-Assessment Questionnaire A-EP are PCI DSS reporting and validation tools intended for particular payment environments. They are not different security standards, and they are not menus from which an ecommerce merchant can simply select the shortest questionnaire.

PCI DSS establishes security requirements for protecting account data and payment environments. An SAQ identifies a subset of those requirements that may be appropriate when a merchant meets the questionnaire’s exact eligibility conditions.

PCI DSS SAQ A is intended for qualifying card-not-present merchants that outsource account-data processing to PCI DSS-compliant third-party service providers and do not electronically store, process, or transmit account data on their own systems or premises. 

For ecommerce use, the payment-page or payment-form elements delivered to the customer’s browser must meet additional criteria.

The current SAQ A also includes an ecommerce eligibility condition requiring the merchant to confirm that its site is not susceptible to script attacks that could affect its ecommerce systems. 

PCI SSC clarified that this particular script-related criterion applies to ecommerce merchants using an embedded third-party payment page or form, such as an iframe, rather than merchants whose site simply redirects shoppers to a provider-hosted payment page.

Confirms that PCI DSS v4.0.1 SAQs are validation tools, discusses clarified eligibility criteria for SAQ A and A-EP, and tells merchants to verify eligibility with the entity receiving the SAQ.

SAQ A-EP, by contrast, is designed for qualifying ecommerce merchants whose website does not itself receive account data but nevertheless affects the security of the payment transaction or the integrity of the page accepting account data. 

This commonly matters when the merchant supplies part of the payment page, controls how account data is submitted, or otherwise has greater involvement in the browser-side payment experience.

PCI SSC’s guidance makes an important distinction: for SAQ A, payment-page elements must originate only and directly from a PCI DSS-compliant service provider. Under SAQ A-EP criteria, payment-page elements may originate from the merchant website or a compliant service provider, provided all other SAQ A-EP conditions are met.

SAQ A vs SAQ A-EP at a Glance

The difference between SAQ A and SAQ A-EP becomes easier to understand when the architecture is viewed from the customer’s browser rather than from the merchant’s processor account.

A merchant can technically “outsource processing” while still serving code that determines how the customer’s account data reaches that processor. That ability to influence payment security is one reason SAQ A-EP carries broader responsibilities.

Area	SAQ A	SAQ A-EP
Typical ecommerce architecture	Fully outsourced payment collection, commonly a qualifying redirect or third-party-hosted iframe	Partially outsourced ecommerce architecture in which merchant systems affect the payment page or payment-data redirection
Where payment elements originate	For ecommerce eligibility, payment-page/form elements originate only and directly from a PCI DSS-compliant TPSP/payment processor	Payment-page elements may originate from the merchant website or a PCI DSS-compliant TPSP
Merchant website involvement	More limited involvement in payment collection	Merchant website can materially affect payment security
Card data handled by merchant systems	No electronic storage, processing, or transmission under SAQ A eligibility	Merchant website itself must not receive account data under SAQ A-EP eligibility
Systems that can affect payment security	Still relevant, particularly for ecommerce website and script-related eligibility	Broader merchant-controlled environment can be security-impacting and in scope
Relative validation burden	Narrower	Significantly broader
Typical checkout examples	Qualifying hosted redirect or qualifying provider-hosted iframe	Direct Post-style designs, merchant-generated payment pages, or other qualifying partially outsourced browser flows

The words “typical” and “qualifying” matter. A redirect does not automatically produce SAQ A eligibility, and an iframe does not automatically produce SAQ A eligibility. Every applicable condition still has to be satisfied.

PCI SSC specifically warns that all eligibility criteria for the selected SAQ must be met. A merchant can satisfy the payment-page-origin condition yet fail another requirement and therefore be unable to use that questionnaire.

SAQ selection also does not answer every validation question. Payment brands, acquiring banks, payment facilitators, processors, and other compliance-accepting entities can establish how a merchant must validate PCI DSS compliance. PCI SSC recommends confirming eligibility and submission expectations with the entity receiving the SAQ.

What Is PCI DSS SAQ A?

SAQ A is designed around extensive outsourcing. For an eligible ecommerce merchant, account-data processing is handled by PCI DSS-compliant third parties, while merchant systems do not electronically store, process, or transmit account data.

For ecommerce channels, that description goes beyond the common statement that “our processor handles the cards.” The browser architecture matters.

PCI SSC’s guidance states that all elements of the payment page delivered to the consumer’s browser must originate only and directly from compliant third-party service providers for SAQ A eligibility. 

Where a third-party payment page is embedded in an iframe, all fields and web elements associated with capturing payment-account data must remain inside that provider-delivered frame.

Content outside the iframe that is unrelated to payment-data collection does not automatically become part of the payment page. A merchant can therefore host product summaries, branding, navigation, or other surrounding content and potentially remain eligible, provided the payment elements themselves and all other eligibility conditions satisfy SAQ A.

That does not mean the merchant website can be ignored.

The current SAQ A revision added an eligibility criterion requiring relevant ecommerce merchants to confirm that their site is not susceptible to script attacks that could affect the ecommerce system. PCI SSC made this change when it removed Requirements 6.4.3 and 11.6.1 from the current SAQ A validation questionnaire.

Current PCI guidance also confirms that SAQ A ecommerce merchants have external vulnerability-scanning responsibilities under Requirements 11.3.2 and 11.3.2.1. This applies to ecommerce webpages that redirect customers to third-party providers as well as webpages containing third-party payment iframes.

Outsourcing therefore reduces scope; it does not eliminate every merchant responsibility.

What Is SAQ A-EP?

SAQ A-EP occupies an important middle ground between fully outsourced payment collection and direct merchant handling of account data.

The questionnaire is intended for qualifying ecommerce merchants whose website does not receive account data but nevertheless affects the security of the transaction or the integrity of the page through which the customer submits that data. 

PCI SSC’s eligibility criteria describe an environment in which the merchant website controls how customers, or their account data, are redirected to a compliant provider.

One classic example is a merchant-generated payment form where the customer’s browser submits card data directly to a payment provider rather than to the merchant server. The merchant server might never see the primary account number, yet the HTML and JavaScript creating the payment interface are under merchant control.

If attackers compromise that page, they may be able to alter where information is sent, inject scripts, change form behavior, or replace the legitimate payment flow.

That security influence explains why SAQ A-EP contains a much broader collection of PCI DSS requirements than SAQ A. Relevant areas can include secure configurations, vulnerability management, access control, secure development and change management, logging, security testing, payment-page script management, monitoring, and organizational security processes.

SAQ A-EP eligibility still has boundaries. If raw account data reaches a merchant server, database, application, log, proxy, analytics system, or other merchant-controlled component, the architecture may no longer qualify for SAQ A-EP. A broader SAQ or assessment method may then be necessary.

Merchants should not guess the replacement questionnaire. They should re-evaluate the environment against current PCI SSC criteria and confirm the validation approach with the acquiring bank, payment brand, QSA, or other applicable compliance resource.

Why Checkout Architecture Determines PCI DSS Scope

A checkout page is not merely a visual form. It is a collection of HTML, JavaScript, embedded resources, browser requests, APIs, security headers, cookies, payment components, and backend services that together determine where sensitive information flows.

For PCI DSS checkout compliance, several questions matter:

• Who generates the card-number, expiration-date, and security-code fields?
• Which domain actually receives the values?
• Can merchant JavaScript inspect or modify those values?
• Can merchant code replace the payment component?
• Can a compromised plugin alter the destination of the transaction?
• Are payment values copied to logging, analytics, monitoring, or tag-management systems?
• Does the merchant’s backend proxy payment requests?
• Which systems can change the checkout code customers receive?

The answers create a more reliable scope picture than phrases such as “we use tokenization” or “the gateway hosts the card fields.”

A secure architecture review should trace the real payment path:

Customer Browser → Merchant Website → Payment Element → Payment Provider → Processor/Acquirer

Then identify who controls every important transition.

For additional technical context on mapping API flows, protecting credentials, and minimizing the systems exposed to sensitive payment information, the site’s guide to payment API security explains why architecture determines which systems need stronger controls.

Hosted Redirect Checkout

A fully hosted redirect generally follows this pattern:

Merchant Site → Redirect → Third-Party Hosted Payment Page → Payment Provider

The customer browses products and creates an order on the merchant site. When payment begins, the browser leaves the merchant-controlled payment environment and loads a page served by the payment provider.

The customer enters card data on that provider-hosted page, and the merchant may receive only a transaction identifier, status, token, or browser return after payment.

This model can materially reduce merchant ecommerce PCI scope because the merchant is not generating the payment page that captures card data. PCI SSC specifically identifies redirects as one architecture that may be compatible with SAQ A when every SAQ A eligibility condition is satisfied.

However, redirect does not equal automatic SAQ A.

A compromised merchant site could still change the legitimate processor URL, send shoppers to a fraudulent domain, manipulate order parameters, or alter the checkout button. The merchant also has responsibilities associated with its provider relationships and applicable website security requirements.

The technical implementation matters too. A standard server-side redirect to a known provider URL is different from merchant application code dynamically constructing payment destinations from untrusted input.

Hosted checkout also creates product and conversion tradeoffs. Customers leave the merchant page, customization may be more restricted, and the experience depends heavily on the provider. But in return, a greater portion of payment-page infrastructure may be transferred to a specialized third party.

For broader architectural comparisons, this site’s resources on payment API integration practices can help development teams evaluate which parts of a payment workflow should remain under merchant control.

iFrame Payment Integration

An iFrame payment integration keeps the shopper visually on the merchant page while loading a provider-controlled payment page inside an isolated browser frame.

A simplified flow is:

Merchant Checkout Page → Third-Party Hosted iFrame → Customer Enters Card Data → Payment Provider

The surrounding page originates from the merchant, but the sensitive payment fields can originate from a different domain controlled by the payment provider.

At a high level, browser-origin boundaries can prevent ordinary parent-page JavaScript from directly reading cross-origin iframe contents. That separation is one reason a correctly implemented third-party payment iframe can support a smaller PCI scope than a merchant-hosted payment form.

PCI SSC specifically states that an iframe can support SAQ A where all elements associated with capturing payment-account data are contained within the iframe and delivered by a PCI DSS-compliant provider, with all other SAQ A criteria also satisfied.

An iFrame Is Not Automatically SAQ A

The word iframe describes an HTML mechanism, not a PCI classification. Two implementations can both use an <iframe> tag while having completely different security properties.

For SAQ A eligibility, PCI SSC requires the payment-page elements delivered to the consumer’s browser to originate only and directly from compliant third-party providers. If an element involved in capturing or processing account data comes from the merchant website, the implementation does not satisfy that SAQ A payment-page condition.

Merchant teams should therefore determine:

• Who creates the iframe?
• Who serves the fields inside it?
• Are all account-data fields contained inside the provider-controlled frame?
• Does merchant JavaScript generate or alter payment fields?
• Can merchant code redirect card data somewhere else?
• Are custom checkout scripts changing the provider integration?
• Are analytics or session-recording tools interacting with the payment workflow?

A merchant may use an iframe and still have substantial security exposure through its parent page. That is one reason the current SAQ A contains an explicit script-attack eligibility condition for embedded payment-page environments.

Embedded JavaScript, Hosted Fields, and Merchant-Controlled Payment Forms

Modern payment integrations often sit between a traditional iframe and a fully merchant-built form. A payment provider may supply JavaScript that creates isolated fields, injects components, exchanges account data for tokens, or orchestrates checkout entirely inside the browser.

Terms such as hosted fields, embedded checkout, secure elements, or tokenized form can describe useful security designs, but they are vendor terminology rather than universal PCI categories.

Hosted Fields and Embedded Components

A hosted-fields integration commonly places individual provider-controlled fields inside a merchant-designed checkout. The merchant controls labels, layout, order details, buttons, styles, and surrounding JavaScript while the provider controls the sensitive field components.

That design can keep raw account data away from merchant servers. It can also improve customization compared with a full redirect.

But the phrase “hosted fields” does not prove SAQ A eligibility.

PCI analysis must determine whether the payment-page elements satisfy the official origin requirements, whether merchant code can affect payment-data capture or transmission, and whether the merchant receives account data anywhere in the flow.

Tokenization should be analyzed the same way. A token generated by the provider can dramatically reduce the need to store reusable card numbers in merchant systems, but scope analysis must consider the architecture before token creation.

If the customer’s raw card number first enters a merchant-controlled HTML field and JavaScript later exchanges it for a token, the sensitive data has already existed in a merchant-controlled payment context.

Merchant-Controlled Forms and Direct Data Handling

A merchant-controlled payment form presents a different risk profile:

Customer Browser → Merchant Form → Merchant Server → Gateway

Here, card data reaches infrastructure controlled by the merchant before reaching the payment provider. That merchant infrastructure is therefore directly involved in processing or transmitting account data.

Such an environment generally falls outside the eligibility models described for SAQ A and SAQ A-EP, both of which require that merchant systems not electronically receive or handle account data in the ways excluded by their eligibility conditions. 

The merchant should evaluate the appropriate broader validation method rather than assuming SAQ A-EP is automatically the next step.

Direct handling can also create additional exposure through web servers, reverse proxies, application frameworks, debugging middleware, load balancers, observability tools, queues, databases, backups, and error logs.

A payment integration can therefore appear to “send directly to the gateway” while still leaking data into another merchant-controlled service.

JavaScript, Payment-Page Scripts, and Checkout Tampering

Modern ecommerce attacks frequently target the browser rather than the processor. An attacker who compromises a plugin, theme, tag manager, content-management account, JavaScript dependency, or deployment pipeline may be able to manipulate the checkout without breaching the payment provider.

Potential attack paths include:

• injected JavaScript that copies card details;
• altered forms that submit data to an unauthorized destination;
• malicious redirects to imitation checkout pages;
• compromised third-party dependencies;
• unauthorized tag-manager deployments;
• checkout overlays;
• modified security headers;
• malicious plugin updates; and
• scripts added through compromised administrator credentials.

This risk is reflected directly in PCI DSS ecommerce controls.

Requirements 6.4.3 and 11.6.1

PCI DSS Requirement 6.4.3 addresses scripts loaded and executed in the consumer’s browser on applicable payment pages. It requires methods for confirming script authorization, assuring script integrity, and maintaining an inventory with a business or technical justification for each necessary script. 

PCI SSC materials also make clear that this concern extends to third- and fourth-party scripts, not only JavaScript hosted locally.

Requirement 11.6.1 addresses unauthorized payment-page changes. It calls for change- and tamper-detection capable of identifying unauthorized modification to relevant HTTP headers and payment-page content as received by the consumer browser. 

Under the standard, the mechanism is evaluated at least once every seven days or periodically according to a documented targeted risk analysis where that option applies.

These future-dated requirements became effective on March 31, 2025.

There is an important SAQ A nuance. PCI SSC subsequently removed Requirements 6.4.3, 11.6.1, and the associated 12.3.1 requirement from the current SAQ A questionnaire and replaced that validation approach with the script-related SAQ A eligibility criterion. 

PCI SSC explicitly stated that this reporting change does not erase the underlying requirements from PCI DSS itself.

SAQ A-EP retains substantially greater responsibility for payment-page security, including Requirements 6.4.3 and 11.6.1 in the qualifying environment.

SAQ A Changes Under PCI DSS v4.0.1

PCI DSS v4.0.1 did not introduce a completely new PCI DSS standard. PCI SSC described it as a limited revision focused on corrections and clarifications rather than adding or deleting PCI DSS requirements.

The SAQ program, however, continued to evolve.

PCI SSC initially released PCI DSS v4.0.1 SAQs in October 2024. It later revised SAQ A after industry feedback concerning the ecommerce implementation burden associated with Requirements 6.4.3 and 11.6.1.

The current approach removes 6.4.3, 11.6.1, and supporting Requirement 12.3.1 from SAQ A and instead requires eligible ecommerce merchants using embedded provider payment pages to confirm that their site is not susceptible to script attacks capable of affecting their ecommerce system.

That change should not be interpreted as permission to ignore the merchant website.

PCI SSC’s more recent guidance also confirms that current SAQ A ecommerce merchants must satisfy external vulnerability scanning requirements 11.3.2 and 11.3.2.1. This includes merchants using either redirects or embedded provider iframes. Scans used to meet that PCI requirement must be performed using an approved ASV solution.

This is why organizations should avoid old summaries claiming that SAQ A is essentially a provider-management questionnaire with little technical involvement from the merchant.

Current validation is still narrower than SAQ A-EP, but it is not zero-effort ecommerce compliance.

SAQ A-EP Requirements and the Broader Compliance Burden

SAQ A-EP exists because a merchant website can be security-critical without ever storing the customer’s card number.

When merchant-controlled HTML, JavaScript, hosting, redirects, or system components affect how payment data reaches the provider, an attacker may be able to compromise payment security through the merchant environment. PCI therefore applies a broader set of controls to eligible SAQ A-EP environments.

Depending on applicability, these controls cover areas such as:

• network and system security;
• secure configuration;
• vulnerability management;
• malware protections where applicable;
• secure software and change management;
• access control;
• authentication;
• logging and monitoring;
• vulnerability scanning;
• payment-page script governance;
• payment-page change detection;
• security policies; and
• third-party service-provider management.

The key difference is not simply questionnaire length. SAQ A-EP requires teams to know far more about the systems influencing checkout.

A business may need inventories of in-scope components, access reviews, patching processes, security configurations, change records, vulnerability-remediation evidence, script inventories, scanning evidence, monitoring records, and documented policies.

External ASV scanning is also relevant in SAQ A-EP environments. PCI SSC’s SAQ materials include Requirement 11.3.2 for qualifying external vulnerability scans, subject to the requirement’s scope and applicability.

Penetration testing should be treated similarly: determine whether the relevant requirement applies to the merchant’s actual assessment scope rather than assuming that every ecommerce merchant has identical testing duties.

Checkout Architecture Decision Table

A decision table can help teams identify which architectures deserve closer review, but it must not substitute for the official eligibility criteria.

Checkout Method	Where Customer Enters Card Data	Can Merchant Affect Payment Page?	Likely SAQ Direction*
Fully hosted redirect	Provider-hosted page	Merchant can affect the pre-redirect environment, but provider serves payment page	Often investigate SAQ A first
Third-party iframe	Provider-controlled frame inside merchant page	Parent merchant page can still affect surrounding environment	SAQ A may be possible if all criteria are met
Hosted fields	Provider components embedded in merchant checkout	Frequently depends heavily on implementation	Review SAQ A vs SAQ A-EP carefully
Embedded JavaScript form	Merchant page with provider JavaScript/components	Often significant merchant control	Commonly requires SAQ A-EP analysis
Merchant-hosted payment form	Merchant-controlled form or server receives card data	Yes	Usually outside SAQ A/A-EP eligibility; broader scope likely

*Illustrative only. Final SAQ eligibility depends on all current PCI SSC eligibility criteria and acquirer/payment-brand requirements.

A merchant should be especially cautious when a gateway offers several integration modes. The provider’s PCI DSS status can remain the same while the merchant’s responsibilities change considerably between redirect, iframe, hosted-field, JavaScript, and direct API modes.

Who Actually Receives Cardholder Data?

Many scope mistakes disappear when teams stop asking “Who processes our cards?” and ask instead: Which system receives the account data first?

Trace the browser transaction:

Browser → Payment Element → Payment Provider → Processor

Then inspect every intermediate destination.

Ask:

• Does the merchant web server receive the PAN?
• Can merchant JavaScript read the card number?
• Does a reverse proxy terminate the request?
• Does an analytics endpoint receive form values?
• Is card data visible in error-reporting events?
• Does browser storage contain account data?
• Are network logs recording request bodies?
• Does a CDN function inspect POST data?
• Does a tag-management platform receive checkout variables?

Tokenization Does Not Automatically Reduce All Scope

Tokenization is extremely useful because it can replace a sensitive payment credential with a surrogate value that merchant systems can use without repeatedly storing the underlying account number.

But tokenization happens at a particular point in the payment flow.

If raw card data goes directly from a provider-controlled payment element to the provider and the merchant receives only a token, exposure can be substantially reduced. If merchant-controlled code receives the card number first and then submits it for tokenization, the pre-tokenization environment still matters.

For a broader discussion of keeping sensitive data out of unnecessary systems, see the site’s Payment API Security Guide.

Browser Developer Tools and Network Testing

Developers can perform a useful architecture review with ordinary browser tools, provided testing occurs safely.

Use a non-production environment whenever possible and use only payment-provider test credentials and test card numbers intended for sandbox use. Never use real cardholder data merely to investigate PCI scope.

A practical workflow is:

1. Load the checkout in a test browser.
2. Open the browser’s Network and Sources tools.
3. Identify every frame and origin involved in payment.
4. Determine which domain serves the account-data fields.
5. Enter provider-approved test payment data.
6. Inspect which network endpoint receives the test values.
7. Verify that merchant endpoints do not unexpectedly receive account data.
8. Inspect browser storage, application logs, and error-monitoring events.
9. Review analytics and tag-manager requests for accidental payment-data leakage.
10. Save an architecture diagram and test evidence.

Testing should also look beyond the obvious POST request. JavaScript can duplicate data into telemetry, error messages, browser storage, or third-party services even when the primary payment request is correctly directed to the provider.

This technical review is particularly valuable before completing PCI DSS SAQ A or SAQ A-EP because it turns architectural assumptions into observable evidence.

Plugin-Based Checkout, WooCommerce, and Custom Checkout Pages

Payment plugins simplify integration, but a plugin is not a PCI scope certificate.

A single gateway plugin may support several modes: hosted redirect, iframe, hosted fields, embedded JavaScript, or direct API payment collection. Merchants using the same extension can therefore have different checkout embed PCI compliance responsibilities depending on configuration.

Teams reviewing a plugin should document:

• selected integration mode;
• provider-hosted versus merchant-hosted fields;
• plugin version;
• custom template overrides;
• theme checkout modifications;
• custom JavaScript;
• analytics tags;
• tag-manager containers;
• fraud scripts;
• page builders; and
• any code that changes the provider’s default checkout.

A useful WooCommerce example is 3-D Secure. The platform, gateway plugin, payment provider, and issuer authentication components can all participate in the browser experience. This site’s developer guide to 3-D Secure integrations in WooCommerce illustrates why developers need to understand the actual flow rather than treating a plugin as a black box.

Custom Scripts, Tag Managers, CSP, and SRI

Custom checkout code increases flexibility but also expands the number of ways the payment environment can change.

Analytics scripts, advertising pixels, chat tools, personalization platforms, A/B testing code, session-replay tools, and fraud services can all execute beside payment components. Every additional script increases dependency and governance complexity.

Tag managers deserve special attention because a user with publishing privileges may effectively gain the ability to deploy JavaScript to checkout without a normal application release.

Content Security Policy can provide defense in depth by restricting which sources may execute scripts, load frames, or receive network requests. CSP is valuable, but it should not be presented as a stand-alone PCI compliance solution.

Subresource Integrity can help browsers verify certain externally hosted static resources against expected cryptographic hashes. It is not suitable for every dynamically generated or frequently changing script, so its usefulness depends on the resource-delivery model.

A sound deployment process is:

Change Request → Security Review → Test → Approve → Deploy → Monitor

For teams balancing checkout customization with usability, the site’s guide to checkout conversion optimization provides useful context. Conversion changes should still pass security and PCI-scope review before production release.

Inventory the Systems That Can Affect Checkout Security

The statement “card data never hits our server” answers only one scope question.

A modern ecommerce environment may include many systems capable of changing what a customer sees or where the browser sends payment information:

• web server;
• CDN;
• DNS provider;
• ecommerce platform;
• CMS;
• theme;
• payment plugin;
• dependency registry;
• tag manager;
• deployment pipeline;
• source repository;
• cloud control plane;
• administrator accounts; and
• build automation.

Compromise of any one of these components may enable an attacker to modify checkout or redirect customers.

Administrator security is therefore especially important. Use unique accounts, strong authentication, MFA where appropriate, least privilege, secure account recovery, prompt removal of former users, and logging of sensitive administrative actions.

Plugin and dependency management deserves the same discipline. Install software from trusted sources, track versions, address known vulnerabilities, remove abandoned extensions, test updates in staging, and maintain recoverable backups before major platform changes.

These controls improve ecommerce payment security regardless of which SAQ is ultimately applicable.

PCI Responsibility Matrix

Outsourcing payment functions creates shared responsibility rather than transferring every obligation.

Security Responsibility	Merchant	Payment Provider	Shared/Depends
Provider-hosted payment fields		Primary	Merchant must integrate them correctly
Merchant website	Primary		Hosting arrangements may change responsibilities
Payment-page scripts	Often significant	Provider responsible for its components	Depends on architecture and SAQ
Checkout admin accounts	Primary		Provider accounts also need protection
Payment processing platform		Primary	Merchant must use provider appropriately
Transaction logs	Merchant for merchant systems	Provider for provider systems	Depends on data returned and retained
Plugin security	Merchant for installation/configuration	Vendor for supplied code	Shared lifecycle responsibility

Merchants should verify that payment providers are appropriately PCI DSS compliant for the services being used. Current SAQ criteria specifically require that applicable third-party service providers be PCI DSS compliant for the services they provide to the merchant.

An Attestation of Compliance, or AOC, can provide relevant validation information about a service provider, but the provider’s AOC does not become the merchant’s compliance attestation.

The merchant remains responsible for its own environment, integration choices, procedures, applicable requirements, and validation submission.

PCI Compliance, Validation, Merchant Level, and Acquirer Requirements

PCI compliance and PCI validation are related but distinct concepts.

Compliance concerns whether applicable PCI DSS requirements are actually being met.

Validation concerns how an organization demonstrates that status to the entity requiring evidence. An SAQ is one validation method. An Attestation of Compliance accompanies applicable assessment reporting. Other organizations may be required to use different assessment approaches.

Merchant level is also different from SAQ eligibility. Payment brands and acquiring organizations may categorize merchants by transaction volume, risk, breach history, or program rules. Those classifications can affect validation expectations, but they do not change the technical eligibility criteria written into an SAQ.

A technically SAQ A-like architecture therefore does not guarantee that a particular merchant will be permitted to validate using SAQ A.

PCI SSC itself states that it does not determine each merchant’s compliance-validation obligations. Those decisions are made through payment-brand, acquirer, payment-facilitator, processor, or similar compliance programs.

When uncertainty remains, contact the acquiring bank, payment brand, QSA, or appropriate PCI compliance resource before submitting an attestation.

What Happens If You Choose the Wrong SAQ?

Selecting the wrong SAQ can create more than paperwork inconvenience.

If a merchant completes SAQ A while its architecture actually requires a broader assessment, important controls may never be evaluated. The organization could submit an inaccurate attestation while leaving meaningful security risks unaddressed.

Potential consequences include:

• rejected or incomplete validation;
• requests for a new assessment;
• remediation work;
• delayed onboarding or renewal;
• additional evidence requests;
• undiscovered security weaknesses; and
• inaccurate compliance representations.

This does not mean every incorrect questionnaire automatically produces a fine. Enforcement and merchant-compliance consequences depend on the applicable payment-brand and acquiring relationships, contractual obligations, circumstances, and event history.

The better approach is to treat SAQ determination as an architecture exercise rather than an administrative form-selection exercise.

If checkout architecture changes, reassess it.

Moving from direct merchant card handling to a properly implemented provider-hosted checkout can sometimes reduce scope significantly. But scope reduction must result from genuinely changing the data flow and control boundaries—not from renaming components or describing them differently on an assessment.

Hosted Redirect vs Embedded Checkout

Businesses often choose between scope simplicity and checkout flexibility.

Consideration	Hosted Redirect	Embedded/iFrame
User remains on merchant page	Usually no	Usually yes
Merchant customization	More limited	Often greater
PCI scope considerations	Often favorable for SAQ A analysis when criteria are met	SAQ A may still be possible, but implementation details matter
Script-security considerations	Merchant redirect environment still needs protection	Parent-page security becomes particularly important
Integration complexity	Often lower	Frequently higher

Neither approach universally produces better conversion. A well-designed provider-hosted page may outperform a poorly designed embedded checkout, while a polished embedded experience may reduce friction for some businesses.

Organizations should evaluate security, branding, accessibility, mobile experience, conversion, implementation effort, fraud controls, and ongoing compliance together.

SAQ Eligibility Review Workflow

A repeatable SAQ review is more reliable than tribal knowledge about what “usually” applies.

Use this workflow:

1. Draw the complete payment-data flow.
2. List every checkout domain and subdomain.
3. Identify who hosts each account-data field.
4. Identify all scripts executing on checkout.
5. Determine whether merchant systems receive account data.
6. Determine whether merchant code can influence capture or transmission.
7. Compare the environment with current SAQ A eligibility criteria.
8. Compare it separately with current SAQ A-EP eligibility criteria.
9. Record the reasoning and supporting evidence.
10. Confirm the approach with the compliance-accepting entity when necessary.
11. Repeat the review whenever checkout architecture changes.

Two simplified diagrams are useful:

Lower-exposure provider-hosted model

Customer Browser → Merchant Website → Third-Party Payment Element → Payment Provider → Acquirer

Direct merchant-handling model

Customer Browser → Merchant Form → Merchant Server → Gateway

The second path introduces merchant-controlled infrastructure directly into the account-data flow and therefore substantially broadens potential PCI DSS exposure.

SAQ Decision Checklist

Use this checklist as a discussion aid, not as a substitute for the official SAQ.

Question	Yes/No
Is all applicable account-data processing outsourced?
Are payment elements served by the compliant provider?
Does card data ever reach merchant systems?
Can merchant scripts affect payment capture or routing?
Is an iframe used?
Is the surrounding checkout page merchant-controlled?
Are third-party scripts loaded on checkout?
Are all current SAQ A eligibility criteria satisfied?
Does the architecture instead satisfy SAQ A-EP criteria?
Has the validation approach been confirmed where necessary?

Do not stop at the first “yes.” SAQ eligibility is based on satisfying all applicable criteria, and a seemingly minor integration detail can change the result.

Questions to Ask Your Gateway or Payment Plugin Provider

Technical questions produce better answers than “Are we PCI compliant?”

Ask the provider:

• Which SAQ is this specific integration mode designed to support?
• Is the checkout a redirect, iframe, hosted-field implementation, embedded JavaScript form, or direct API integration?
• Which organization serves the HTML fields collecting account data?
• Does card data ever pass through our web server or API?
• Can JavaScript running from our domain access payment-account data?
• Which PCI DSS responsibilities remain with us?
• Is the provider PCI DSS compliant for the services we use?
• Can relevant compliance documentation be provided?
• What changes if we customize the default checkout?
• Can unrelated third-party scripts execute on the checkout page?
• What mechanisms protect or monitor payment-page changes?
• Does switching plugin modes change expected SAQ eligibility?
• Which merchant systems are considered security-impacting?
• Are there integration features that proxy payment data through our infrastructure?

Get answers in writing and compare them with actual browser behavior. Provider documentation is useful evidence, but it does not replace verification of how the merchant has configured and customized the integration.

Common SAQ A vs SAQ A-EP Mistakes

Several recurring assumptions create inaccurate PCI DSS checkout compliance conclusions.

• Choosing SAQ A because the provider tokenizes cards: Tokenization can reduce exposure after the provider receives account data, but it does not define who controlled or received the card data beforehand.
• Assuming every iframe qualifies for SAQ A: PCI SSC explicitly requires closer examination of where the payment-page elements originate.
• Trusting the plugin’s marketing name: “Hosted,” “secure,” and “embedded” are not SAQ classifications.
• Ignoring merchant-side scripts: A compromised parent checkout page may alter the payment experience even if the card fields themselves come from a provider.
• Allowing analytics or monitoring tools to capture sensitive values: Accidental leakage into logs or telemetry can change both risk and scope.
• Relying on PCI DSS v3.2.1 articles: Ecommerce security and SAQ requirements have changed substantially.
• Failing to reassess after checkout changes: A developer can move from redirect to embedded mode, add custom fields, or introduce a proxy endpoint without the compliance team realizing the architecture changed.
• Assuming provider compliance equals merchant compliance: The provider validates its environment. The merchant still has responsibilities for its own implementation.

Checkout Redesign Checklist

Before deploying a new checkout experience, verify:

• payment-data flow;
• SAQ eligibility impact;
• provider documentation;
• payment-element origin;
• plugin configuration;
• JavaScript dependencies;
• third-party scripts;
• tokenization point;
• logging behavior;
• browser storage;
• analytics and error monitoring;
• vulnerability-scanning implications;
• payment-page monitoring requirements;
• administrator access;
• deployment controls;
• provider PCI status; and
• acquiring-bank or payment-brand requirements.

Security should be reviewed before production deployment, not after the annual PCI questionnaire arrives.

Frequently Asked Questions

Conclusion

The difference between SAQ A vs SAQ A-EP is ultimately an architecture question.

Two stores can use the same processor, ecommerce platform, and payment plugin while having different PCI DSS responsibilities because one sends shoppers to a provider-hosted payment page and the other uses merchant-controlled code that affects payment capture.

A helpful guiding principle is:

Full Hosted Redirect → Third-Party Hosted iFrame → Embedded Third-Party Components → Merchant-Controlled Payment Page → Direct Card Data Handling

As merchant control over payment collection and payment-security decisions increases, potential PCI DSS scope and the corresponding validation burden generally increase as well.

But the spectrum is only a conceptual guide. The official eligibility criteria remain decisive.

A redirect does not automatically equal SAQ A. An iframe does not automatically equal SAQ A. Hosted fields do not automatically equal SAQ A. Tokenization does not automatically equal SAQ A. And a PCI DSS-compliant payment provider does not make the merchant automatically compliant.

The strongest process is to map the payment flow, identify who delivers every payment element, inspect which systems can influence checkout, verify whether account data ever reaches merchant infrastructure, inventory relevant scripts and dependencies, compare the results with current PCI SSC documentation, and reassess whenever checkout changes.

PCI SSC’s PCI DSS Document Library should remain the primary source for the current standard, SAQs, instructions, and related guidance. PCI SSC also maintains detailed ecommerce FAQs explaining SAQ A payment-page eligibility and script considerations.

This article provides general educational information about ecommerce payment architecture and PCI DSS validation concepts. It is not a PCI DSS certification, legal opinion, or determination of a particular merchant’s compliance status. Merchants should use current PCI SSC documentation and consult their acquirer, payment brand, payment facilitator, QSA, or other appropriate PCI resource when determining final validation requirements.