SAQ A Redirect Compliance: A Working Implementation Guide

The PCI SSC's August 2026 FAQ #1588 highlighted a documentation gap causing compliance issues: if your e-commerce site uses redirect-based payment flows instead of iFrames, you're still expected to comply with requirements 6.4.3 and 11.6.1, even though these aren't listed in SAQ A. The Council removed them, then clarified they still apply to non-iFrame implementations. Your acquirer now decides how you document this compliance, and there's no standard approach.

This isn't just theoretical. If you redirect customers to your payment processor using HTTP 30x redirects, meta redirect tags, or JavaScript redirects, you're in scope for script management and change detection controls not listed in your SAQ. Here's how to implement compliant controls and document them defensibly.

What You Need Before Starting

Confirm your payment flow architecture. You're using redirects (not iFrames) if your checkout sends customers to a different domain or uses client-side code to navigate away from your site. Email-based payment links where customers click through to a processor's hosted page also fall under this category.

Identify your acquirer's documentation requirements. Contact your acquirer before building anything. Ask specifically: "How do you want us to document compliance with requirements 6.4.3 and 11.6.1 for redirect-based payment flows?" Some acquirers accept attestation letters. Others want screenshots of your change control process or third-party scan reports. Get this in writing.

Gather your current change management artifacts. You'll need access to your version control system, deployment logs, and any existing change approval workflows. Requirement 6.4.3 addresses unauthorized script changes; you can't comply retroactively if you don't have a record of what changed and when.

Document your third-party scripts inventory. List every script that loads on pages in your payment flow, including analytics, chat widgets, and A/B testing tools. Note the source domain, purpose, and whether it runs before or after the redirect executes. This becomes your baseline for requirement 11.6.1 (change detection).

Step-by-Step Implementation

Build a change authorization process for payment page scripts. Requirement 6.4.3 requires that scripts on payment pages be authorized and managed. Create a documented approval workflow:

1. Maintain a register of authorized scripts in a shared document or configuration management database. Include script source URL, SHA-256 hash, business owner, and approval date.
2. Require pull request reviews for any commit that modifies pages in your checkout flow. Your reviewer checks the script register before approving.
3. Log every deployment to payment-related pages with timestamp, deployer identity, and change description.

If you use a content management system, configure it to require dual approval for changes to checkout templates. If you deploy via CI/CD, add a gate that compares scripts in the deployment artifact against your authorized list.

Implement automated change detection for payment page scripts. Requirement 11.6.1 requires detecting changes to HTTP headers and payment page scripts. Set up monitoring that alerts on unauthorized modifications:

1. Deploy a file integrity monitoring tool that hashes your payment page templates and JavaScript files. Open-source options include OSSEC or Tripwire; commercial alternatives include Qualys FIM or Rapid7 InsightVM.
2. Configure the tool to scan hourly and alert on any change to files in your checkout flow directory structure.
3. Set up Subresource Integrity (SRI) tags for any external scripts you load. Add integrity="sha384-..." attributes to script tags so browsers verify the script hasn't changed.
4. Use Content Security Policy headers to restrict script sources. Set script-src 'self' https://trusted-processor.example.com to prevent unauthorized script injection.

If your pages are served from a CDN, configure the monitoring tool to check both origin and edge copies. Script tampering can occur at either layer.

Configure HTTP response header monitoring. Requirement 11.6.1 also covers HTTP headers on payment pages. Use your web server's logging or a reverse proxy to capture response headers for every request to checkout URLs:

1. Enable verbose logging on your web server (Apache, Nginx, or IIS) for paths matching /checkout/* or /payment/*.
2. Parse logs daily to detect unexpected headers like Content-Security-Policy removals or new Set-Cookie directives you didn't authorize.
3. If you use a WAF or API gateway, configure it to alert on header changes that match patterns associated with payment page tampering.

Create your compliance documentation package. Since requirements 6.4.3 and 11.6.1 don't appear in SAQ A, you'll document compliance separately:

1. Write a brief attestation letter stating you've implemented controls equivalent to 6.4.3 and 11.6.1 for your redirect-based payment flow.
2. Attach evidence: screenshots of your script authorization register, sample FIM alert emails, your CSP header configuration, and a recent deployment log excerpt.
3. Include your payment flow diagram showing the redirect mechanism and where scripts execute.
4. Submit this package to your acquirer alongside your completed SAQ A.

Validation: How to Verify It Works

Test your change detection within 24 hours of implementation. Modify a single character in a JavaScript file on a checkout page. Your FIM tool should alert within its configured scan interval. If it doesn't, check file paths and permissions.

Verify SRI enforcement. Edit the integrity hash on a script tag to an incorrect value, then load the page in a browser. The browser should block the script and log a console error. If the script loads anyway, your SRI tag isn't properly formatted.

Confirm CSP blocks unauthorized scripts. Add a test <script> tag pointing to an unauthorized domain in your checkout template. Deploy to a staging environment. The browser should refuse to execute it and report a CSP violation. Check your browser's developer console for the violation report.

Audit your change approval workflow. Have a colleague attempt to deploy a script change without following your authorization process. If they succeed, your workflow has gaps. Add required approvals or pre-deployment checks.

Maintenance and Ongoing Tasks

Update your script register when you add vendors. Every time you integrate a new analytics tool, chatbot, or marketing tag, add it to your authorized scripts list before deployment. Document the business justification and approval in your change log.

Review FIM alerts weekly. Don't let alerts pile up. Investigate every detected change within 48 hours. If it's authorized, update your baseline. If it's not, treat it as a potential security incident and follow your response plan.

Re-hash your SRI tags when scripts update. When your payment processor or other vendors release new script versions, generate new SHA hashes and update your integrity attributes. Test in staging before deploying to production.

Communicate with your acquirer quarterly. Compliance expectations for redirect flows may evolve as more merchants encounter this documentation gap. Ask your acquirer if they've updated their requirements or if other merchants in their portfolio have adopted different approaches.

Prepare for your next assessment. When your QSA arrives, walk them through your redirect architecture first. Show them your separate documentation package for requirements 6.4.3 and 11.6.1 before they ask. Explain that you're aware these requirements aren't in SAQ A but you've implemented them based on the Council's FAQ guidance.

The Council could resolve this by reinstating requirements 6.4.3 and 11.6.1 in SAQ A with conditional language for non-iFrame solutions. Until that happens, you're documenting compliance in a format your acquirer accepts while maintaining the actual security controls the requirements were designed to enforce.