PCI DSS 4.0 Update: New SAQ A Eligibility Criteria

Updated on: Mar 21, 2025 14 Minute Read

The Payment Card Industry Security Standards Council (PCI SSC) has issued FAQ 1588 to clarify eligibility criteria for Self-Assessment Questionnaire A (SAQ A). This FAQ specifically addresses e-commerce merchants that outsource payment card processing through embedded payment pages or forms like iframes.

According to the clarification, merchants using iframes must now either:

Implement security techniques to protect against malicious scripts, or
Obtain confirmation from their PCI DSS-compliant vendor that the embedded payment form includes such protections.

These security techniques may include those defined in PCI DSS Requirements 6.4.3 and 11.6.1, such as:

Allowing only authorized scripts to run on the website
Setting up alerts for unauthorized changes to scripts and website headers
Using tools to verify scripts haven’t been tampered with

Merchants can deploy these controls directly or through a third party. If relying on the payment processor’s protections, merchants must verify they’ve implemented the iframe exactly according to the vendor’s instructions.

While the FAQ officially applies to PCI DSS version 4.0.1 (effective April 2025), its guidance remains relevant to current requirements. The FAQ distinguishes between merchants using iframes and those who fully outsource payment functions or redirect customers to vendor websites, noting different eligibility requirements for each scenario.

Merchants should collaborate with their payment processors to receive guidance on secure implementation. Payment card networks maintain transaction volume thresholds that determine whether a merchant qualifies for SAQ A or must undergo a full PCI DSS assessment by a Qualified Security Assessor.

Payment processing security: embed forms vs. redirects

Payment processing architectures using embedded forms (iframes) and redirect methods require different security approaches because of their distinct interaction models with merchant websites.

With embedded forms, the payment interface exists directly within the merchant’s webpage, creating a shared context where malicious scripts on the merchant’s site could potentially access payment data through cross-frame scripting attacks, DOM manipulation, or event listeners. While these forms appear visually integrated, they create security boundaries that attackers might exploit.

Redirect methods transfer customers to a separate processor-controlled domain, establishing natural security boundaries that isolate the payment process. Browser security models prevent merchant-site scripts from accessing the payment page after the redirect occurs, providing inherent isolation.

Understanding SAQ A eligibility requirements

Merchants must thoroughly understand the eligibility criteria for SAQ A to ensure compliance while maintaining secure payment processing environments. The PCI Security Standards Council’s FAQ 1588 creates distinct requirements based on implementation type, with specific security obligations for merchants using embedded payment forms.

Compliance options for iframe implementations

Merchants using iframes for payment processing have two compliance paths to qualify for SAQ A:

Option 1: Implement technical protections

Merchants can deploy security techniques referenced in PCI DSS Requirements 6.4.3 and 11.6.1, including:

Script management controls that permit only authorized scripts
Alert mechanisms for unauthorized changes to scripts and website headers
Verification tools to confirm scripts haven’t been tampered with
Change and tamper-detection mechanisms for payment pages

These controls can be implemented directly or through a contracted third party, but must effectively protect against scripts targeting payment card data.

Option 2: Obtain processor confirmation

Alternatively, merchants can obtain formal confirmation from their PCI DSS-compliant payment processor that their embedded payment solution already includes built-in protections against script attacks. This confirmation must verify that the processor’s solution, when implemented according to their exact instructions, provides adequate safeguards. Merchants choosing this option must document that they’ve followed the processor’s implementation guidelines precisely.

The technical distinction between embedded forms and redirects explains the varying SAQ A eligibility criteria. While iframe implementations require these script protections, merchants who fully redirect customers to processor websites are exempt from this specific requirement due to the natural security boundaries created by the redirect process.

Key considerations

For both options, the technical controls must address common attack vectors such as cross-site scripting, formjacking, and web skimming that target payment data. The specific implementation details may vary based on the merchant’s technical environment and the payment processor’s solution architecture.

Merchants often choose to obtain confirmation from their payment processor rather than implementing their own security measures due to practical constraints. Resource limitations frequently drive this decision. Implementing technical controls specified in PCI DSS Requirements 6.4.3 and 11.6.1 requires specialized security expertise that many merchants don’t have in-house. These requirements involve complex script management, change detection mechanisms, and alert systems that demand ongoing maintenance.

Cost considerations

Cost considerations play a significant role in security decisions. Building, testing, and maintaining script protection systems demand substantial investment in security tools, monitoring solutions, and personnel. By leveraging protections already built into payment processors’ solutions, merchants can avoid these direct costs while still meeting compliance requirements.

Risk transfer

Risk transfer motivates many merchants. When payment processors explicitly confirm their solutions include script attack protections, they assume some responsibility for the payment process security, shifting part of the burden to entities specializing in payment security.

Technical complexity reduction

Technical complexity reduction appeals to many organizations. Script attack vectors evolve rapidly, requiring constant vigilance and updates. Payment processors typically employ dedicated security teams with deeper expertise than most merchant organizations can develop internally.

Accelerated compliance timelines

Accelerated compliance timelines are another compelling factor. Implementing comprehensive script protection controls can take months, whereas obtaining processor confirmation often takes just days or weeks.

Finally, merchants with multiple payment integrations across different websites or brands might choose processor confirmation to ensure consistency across their payment ecosystem without implementing custom solutions for each property.

Payment security responsibility in embedded payment forms

The use of embedded payment forms creates a shared security model between merchants and third-party service providers (TPSPs), with clear boundaries of responsibility.

Merchants are responsible for:

Security of their websites and the iframe hosting environment
Web server security and access controls
Webpage integrity that loads the payment form
Protection against script attacks (per FAQ 1588)

TPSPs are responsible for:

Security of the payment form itself
Processing and transmission of payment card data
PCI DSS compliance for their payment infrastructure
Controls to prevent form compromise or manipulation

This division creates security interdependency where vulnerabilities on either side can compromise the overall payment process. The merchant-TPSP relationship typically formalizes these responsibilities through contractual agreements specifying security requirements, incident response procedures, and liability allocation.

Regulatory frameworks acknowledge this shared model. PCI DSS allows merchants using embedded payment forms to qualify for SAQ A, but only if they meet specific eligibility criteria related to script protection.

Compliance considerations and business impact

The eligibility requirements for SAQ A differ significantly between merchants using embedded payment pages versus redirect methods, with embedded implementations facing stricter security criteria.

Merchants using embedded payment pages (iframes) must meet an additional script protection requirement that redirect users don’t face.

According to FAQ 1588, merchants with embedded payment forms must verify their sites aren’t vulnerable to script attacks targeting e-commerce systems. This requires either:

Implementing technical controls aligned with PCI DSS Requirements 6.4.3 and 11.6.1
Getting confirmation from their payment processor that the embedded solution includes script attack protections

In contrast, merchants using redirect methods (HTTP 30x redirects, meta redirect tags, or JavaScript redirects) are specifically exempted from this requirement. The FAQ clearly states this:

“SAQ A eligibility criteria does not apply to e-commerce merchants with a webpage that redirects customers from the merchant’s webpage to a TPSP/payment processor.”

Both implementation types share common baseline eligibility criteria:

Neither can electronically store, process, or transmit payment card data on their systems
Both must use PCI DSS-compliant third-party service providers for all payment processing functions
Both must verify their service providers’ compliance status

As explained in the “Payment Processing Security” section, the technical differences between these implementation methods create distinct security boundaries, which explains the variation in requirements. The natural isolation provided by redirects eliminates many of the attack vectors present in embedded implementations.

For merchants using embedded payment forms, SAQ A now includes additional security controls in PCI DSS v4.x specifically targeting common e-commerce breaches. These include requirements for:

Managing payment page scripts
Performing external vulnerability scans
Implementing change and tamper-detection mechanisms

Merchants who incorrectly self-assess their eligibility for SAQ A versus SAQ A-EP face significant consequences beyond administrative corrections. SAQ A-EP contains approximately 140 PCI DSS requirements, while SAQ A includes only about 24. A merchant incorrectly using SAQ A might fail to implement over 100 security controls, creating substantial vulnerabilities in critical website security measures like vulnerability scanning, penetration testing, and change management controls.

Factors driving merchants to redirect methods

Explicit exemption from script protection requirements: FAQ 1588 clearly states that the script protection eligibility criterion “does not apply to e-commerce merchants with a webpage that redirects customers from the merchant’s webpage to a TPSP/payment processor.” This creates a straightforward compliance path without the need for technical script protections or formal processor confirmations.

Resource constraints: Implementing and maintaining script protection controls demands technical expertise in web security that smaller merchants typically lack. The redirect approach completely eliminates this requirement, allowing merchants with limited IT resources to achieve SAQ A eligibility without specialized knowledge.

Cost considerations: The technical controls needed for script protection in iframe implementations often require additional security tools, monitoring solutions, and potentially third-party security services. Redirect methods eliminate these costs while still maintaining SAQ A eligibility.

Risk reduction: With iframe implementations, merchants retain partial responsibility for payment environment security. Redirect methods create clearer security boundaries, with the payment processor assuming more complete responsibility for payment page security, reducing the merchant’s overall risk exposure.

Compliance verification simplification: Proving compliance with script protection requirements involves complex technical documentation and potentially third-party assessments. Redirect methods create a more straightforward compliance story that’s easier to document and verify during assessment processes.

Consequences of incorrect SAQ classification

Contractual violations with acquiring banks can trigger penalties. Merchant agreements require accurate PCI DSS compliance validation, and using an incorrect SAQ constitutes a breach of terms. This may result in:

Fines
Increased transaction fees
Termination of payment processing capabilities

Some acquirers conduct regular reviews that might catch these misclassifications.

Strategic reasons for choosing SAQ A-EP

Merchants might deliberately choose SAQ A-EP instead of pursuing SAQ A eligibility in several scenarios:

Technical architecture requirements: Often drive this decision when merchants need direct control over the payment page experience. They might require custom payment form styling, complex checkout flows with dynamic pricing calculations or integration with inventory systems that modify transactions in real time.

Business differentiation goals: This can necessitate a more complex path, especially for merchants in markets where the checkout experience significantly impacts conversion rates. High-volume merchants may determine that customization benefits outweigh additional compliance costs when small conversion improvements translate to substantial revenue gains.

Risk management considerations for SAQ A-EP

Comprehensive security approach: Risk management strategies sometimes favor SAQ A-EP’s comprehensive security approach. Merchants handling sensitive customer data beyond payment information may implement these more rigorous controls as part of their broader security program. For these organizations, maintaining a single stricter standard creates less operational complexity than managing two different security frameworks.

Vendor dependency concerns: Push some merchants toward SAQ A-EP. Organizations wanting to maintain control over their payment infrastructure choose this approach for the flexibility to switch providers or integrate with multiple processors simultaneously—options that are limited with the fully outsourced SAQ A model.

Compliance program maturity: Can make SAQ A-EP manageable. Merchants with established security teams may find the incremental effort minimal compared to organizations without such resources, making architectural changes for SAQ A eligibility unnecessary or impractical.

Industry trends and strategic planning

Payment processors are adapting their offerings to help merchants meet clarified SAQ A eligibility requirements, particularly regarding script protection for embedded payment forms:

Documentation and attestation

Many processors now provide formal attestation documentation confirming their iframe solutions include built-in script attack protections. These attestations directly address FAQ 1588 language, giving merchants concrete evidence to satisfy eligibility criteria without implementing their own controls.

Implementation guides

Enhanced implementation guides now detail security requirements for merchants using embedded payment forms, including specific code snippets, configuration parameters, and best practices. Some processors require merchants to formally acknowledge these requirements before granting access to embedded payment solutions.

Technical enhancements

Technical enhancements to iframe implementations include stronger security headers, content security policies, and frame-ancestor restrictions that prevent unauthorized script execution. These strengthened controls make embedded payment forms more resistant to common attack vectors like cross-site scripting and formjacking.

Implementation timeline considerations

Implementation timeline pressures can drive migration to redirect methods. As PCI DSS v4.0.1 approaches its April 2025 effective date, merchants may find that implementing redirect methods requires significantly less time than building or verifying script protection controls for iframe implementations. This allows them to achieve compliance more quickly with reduced technical effort.

Challenges to consider

The clarification of script protection requirements reveals several significant gaps in merchants’ current security practices:

Lack of script management processes

Many merchants have no formal script management processes whatsoever. FAQ 1588’s reference to PCI DSS Requirement 6.4.3 emphasizes the need to inventory and authorize all scripts running on payment pages. Numerous merchants lack any systematic approach to tracking which scripts are present, their origins, or functions.

Missing change detection capabilities

Change detection capabilities are frequently missing from merchant environments. The requirement for tamper-detection mechanisms (Requirement 11.6.1) shows many merchants have no automated way to identify when scripts or HTTP headers on payment pages have been modified, leaving malicious code injections undetected.

Unexamined third-party script dependencies

Third-party script dependencies often go unexamined. Merchants regularly integrate code from analytics providers, marketing tools, and other third parties without proper security reviews, creating potential attack vectors.

Documentation gaps

Documentation gaps become evident when merchants try to obtain confirmation from payment processors about script protection features. Many lack proper implementation records or have modified standard implementations in ways that compromise security.

Overlooked client-side vulnerabilities

Vulnerability scanning practices frequently overlook client-side components, with merchants focusing solely on server-side vulnerabilities while neglecting threats like cross-site scripting and formjacking.

Transaction volume conflicts with SAQ eligibility

High-volume merchants may meet all technical eligibility criteria for SAQ A but still be prohibited from using it based solely on their transaction counts. Card networks maintain specific volume thresholds—typically 1-6 million transactions annually—above which merchants must undergo a full PCI DSS assessment regardless of their technical implementation.

Growth-stage business challenges

Growth-stage businesses face particular challenges when they implement an SAQ A-eligible payment architecture early, only to cross volume thresholds as they grow. This forces them to either:

Undergo a full assessment, or
Redesign their payment implementation

Both options are costly and provide minimal security benefits.

Seasonal business complications

Seasonal businesses experience compliance inconsistencies when they technically qualify for SAQ A but exceed transaction thresholds during peak seasons. This creates:

Shifting compliance requirements throughout the year
Complications for long-term planning

Multi-brand merchant scenarios

Multi-brand merchants with shared payment infrastructure encounter complex scenarios when different brands have varying transaction volumes. If one brand exceeds thresholds while others don’t, merchants must decide whether to:

Maintain different compliance approaches across brands, or
Standardize the most stringent requirements

International merchant challenges

International merchants struggle with conflicts when operating across regions with different card brand dominance. Since volume thresholds vary by network, these merchants face uncertainty about which assessment approach applies to their overall operations.

Mixed payment channel issues

Merchants with mixed payment channels face unique challenges when their combined volume exceeds thresholds, forcing a full assessment despite neither channel individually requiring one.

Payment compliance strategy

1. Conduct a comprehensive assessment

Assess current payment architectures against new eligibility criteria to identify compliance gaps. Examine both technical implementation and transaction volumes across all channels to determine whether simplified or full assessments are required.

2. Implement a formal script management processes

Align with PCI DSS Requirement 6.4.3 by creating an inventory of scripts on payment pages, establishing approval processes for changes, and implementing controls to prevent unauthorized script execution.

3. Deploy change and tamper-detection mechanisms

Address key requirements in both simple and comprehensive assessments. Monitor for unauthorized modifications to scripts, content, and headers, with immediate alerts sent to security personnel when issues are detected.

4. Establish strategic processor relationships

Engage directly with payment processors about their compliance roadmaps and thoroughly document implementations. This proactive approach creates valuable evidence for assessments while enabling merchants to anticipate future requirements rather than reacting to changes. Documentation should include configuration details, security features, and formal confirmation of script protection capabilities.

5. Evaluate alternative payment architectures

Consider strategic options if requirements become more stringent. Assess whether redirect methods, hosted payment pages, or emerging technologies might offer more sustainable compliance paths for your specific needs.

Building clear security requirements into contracts with payment processors and service providers creates necessary accountability.