Key points
• The future-dated PCI DSS 6.4.3 and 11.6.1 requirements became effective on 31 March 2025 where applicable.
• SAQ A changed its validation approach: an embedded payment form triggers an eligibility criterion for protecting the merchant page from script attacks.
• FAQ 1588 treats redirects differently from embedded forms, while FAQ 1604 confirms SAQ A ASV scanning for both patterns.
• Applicability and evidence sufficiency must be confirmed for the actual environment with the compliance-accepting entity or assessor.
One-minute decision: embedded form, redirect, or merchant form
Start with the actual architecture. With an embedded iframe or hosted fields, the merchant page surrounds the payment component and can affect the security of the journey. With a redirect, the customer leaves for the TPSP, but the merchant's redirection mechanism still needs protection. If the merchant creates the form and browser-side payment logic, the scope is generally broader than SAQ A.
Do not select controls from the integration label alone. Verify where form elements originate, which scripts execute on the merchant page, who controls the redirect, which systems can alter the page, and which validation method the compliance-accepting entity has confirmed.
- Embedded form: address the SAQ A eligibility criterion for protection from script attacks.
- Redirect: FAQ 1588's embedded-form criterion does not apply, but redirect protection and SAQ A ASV requirements remain separate considerations.
- Merchant-generated form or Direct Post: do not assume SAQ A eligibility without reviewing the architecture and all criteria.
What changed after 31 March 2025
Requirements 6.4.3 and 11.6.1 were future-dated in PCI DSS v4.x and became effective on 31 March 2025 where applicable. They address authorization and integrity of payment-page scripts and detection of unauthorized changes to pages and security-impacting HTTP headers.
On 30 January 2025, PCI SSC announced an SAQ A change: the 6.4.3 and 11.6.1 rows and related targeted risk analysis were removed from the questionnaire, while a site-protection eligibility criterion was added. That is a change to SAQ A validation, not a statement that client-side risk disappeared.
What FAQ 1588 says about embedded payment forms
FAQ 1588 says the SAQ A script-attack criterion applies to merchants whose webpage includes a TPSP's embedded payment page or form, such as an iframe. A merchant can confirm protection either through techniques such as those described in 6.4.3 and 11.6.1, deployed by the merchant or a third party, or through confirmation from the PCI DSS-compliant TPSP or processor that its correctly implemented solution protects the merchant page.
A provider statement should not be treated as a universal certificate. Retain the current TPSP instructions, evidence that the production integration follows them, the responsibility boundary, the integration version, and the accepted applicability conclusion.
Why a redirect does not remove every responsibility
FAQ 1588 excludes redirect-only pages from the specific embedded-form script criterion. That does not put the merchant site outside security controls: compromise of the redirect mechanism can send customers to a fraudulent payment destination.
FAQ 1604, published in June 2026, separately confirms that SAQ A external vulnerability scanning under 11.3.2 and 11.3.2.1 applies to merchant e-commerce webpages using either redirects or embedded iframes. ASV scanning is a vulnerability control, not a replacement for script governance or page-change monitoring.
Evidence to prepare for review
Begin with an architecture diagram and documented scope decision. Link each payment journey to the observed script register, owners, authorization, business justification, integrity method, approved page baseline, detected changes, and response process.
For embedded forms, retain the TPSP confirmation or the merchant's protection model. For redirects, document the mechanism and systems that can alter it and retain applicable ASV scan results. In both cases, evidence must match the production integration and assessment period.
- Related guide: Why an iframe payment form does not remove every client-side risk
- Evidence workflow: How to build a payment page security evidence pack
- Implementation checklist: PCI DSS implementation checklist
A practical two-week review plan
Select one priority checkout, confirm its architecture and validation path, request current TPSP instructions and responsibility confirmation, inventory the scripts that actually execute, and review the existing change-detection process.
Finish with a test sample: one expected release, one unexplained deviation, and the full path from observation to owner decision and retained artifact. That result demonstrates operational readiness better than a general statement of intent.
Questions to ask a vendor before purchase
A buyer should evaluate the operating control rather than the number of dashboard views. Ask the vendor to demonstrate one real payment journey from observation through a closed event and to separate product functions from responsibilities that remain with the customer.
- Which page states and dynamic loaders are actually observed?
- Which data is collected, which is excluded, and how can exclusions be tested?
- How does a baseline version link to a release, owner, and approval?
- What happens when an unknown source appears, and what context reaches the decision owner?
- Can the system export a reproducible sample with stable identifiers, timestamps, and decision history?
- Which scope, authorization, and response obligations remain with the customer?
Turn the evaluation into a leadership decision
The output should not be 'the tool looked good.' Record the payment architecture, validation path, current gaps, selected controls, owners, implementation effort, and residual risk. Give each gap closure evidence and a review date.
Cartelta can be evaluated with one real sample: observed inventory, approved page state, two controlled changes, event routing, and an export for independent review. That criterion compares vendors on evidence and operating outcomes rather than promises.
Practical steps
1
Identify the actual integration type: embedded form, redirect, or merchant-generated flow.
2
Confirm the SAQ/ROC path and applicability with the compliance-accepting entity.
3
Collect scope, scripts, owners, baseline, and existing protection techniques.
4
Obtain and validate TPSP confirmations and applicable ASV scan results.
5
Run a controlled change and retain the complete evidence trail.
Questions on this topic
Did removing 6.4.3 and 11.6.1 from SAQ A cancel the requirements?
No. The questionnaire and validation approach changed for qualifying SAQ A environments. Applicability and acceptable alternative confirmation depend on the architecture, eligibility criteria, and the entity accepting compliance.
Does a redirect mean the merchant page no longer needs protection?
No. FAQ 1588 excludes redirects only from the embedded-form eligibility criterion. The redirect mechanism and systems that affect it still need protection, and FAQ 1604 confirms SAQ A ASV scanning for redirect webpages.
Does TPSP confirmation automatically resolve the iframe criterion?
Confirm that the TPSP is PCI DSS compliant, the statement covers the specific solution, and the production integration follows its instructions. The final validation path should be agreed with the acquirer, payment brand, or assessor.