The Golden Rule: Scope Reduction via Hosted Fields & Tokenization
The most critical architectural decision in payment engineering is minimizing the Cardholder Data Environment (CDE). If raw Primary Account Numbers (PAN) or CVVs touch your application web servers or databases, your entire infrastructure falls under the full 300+ requirement PCI DSS audit (SAQ D), requiring dedicated physical hardware, network segmentation firewalls, and continuous penetration testing.
PCI DSS v4.0 SAQ Scoping & Compliance Burden Matrix
| Assessment Tier | Architecture Pattern | CDE Scope | Requirements Burden | Primary Developer Security Responsibility |
|---|---|---|---|---|
| SAQ A (Recommended) | Hosted iframes / Redirect (Stripe Elements, Braintree Drop-in) | Zero card data touches merchant infrastructure | ~31 Requirements | Enforce checkout script inventory, SRI, CSP, and Requirement 6.4.3 / 11.6.1 tamper alerts |
| SAQ A-EP | Direct POST from merchant-hosted form fields | Merchant web servers control checkout page DOM | ~191 Requirements | Extensive server hardening, WAF protection, automated ASV scanning, code reviews |
| SAQ D (Merchant) | Custom API endpoint receiving raw PAN/CVV payloads | Full backend infrastructure in CDE | 300+ Requirements | End-to-end HSM encryption, physical data center audits, quarterly external ASV pentests |
By implementing SAQ A with hosted iframe fields, the customer's browser transmits payment details directly to the payment gateway over a segregated, cross-origin iframe. Your application only receives an opaque, single-use token (e.g., tok_1N...), reducing compliance overhead by over 85%.
PCI DSS v4.0 Requirement 6.4.3: Checkout Script Integrity
Requirement 6.4.3 was introduced specifically to combat Magecart and supply-chain skimming attacks. It mandates that on any webpage where payment card data is entered (the checkout origin):
- Documented Business Justification: A written, audited technical justification must exist for every single script executing on the checkout page.
- Script Integrity Verification: All static scripts must be protected using Subresource Integrity (SRI) hashes or automated integrity monitors to verify that third-party CDNs have not been tampered with.
- Restricted Execution via Content Security Policy (CSP): The checkout page must enforce a strict CSP that explicitly allowlists only the verified payment processor origin and prevents unauthorized script execution.
# Production Content Security Policy for PCI DSS v4.0 Requirement 6.4.3
# Restricts script execution on checkout exclusively to authorized payment processor origins
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://js.stripe.com; frame-src https://js.stripe.com https://hooks.stripe.com; connect-src 'self' https://api.stripe.com; object-src 'none'; base-uri 'self';" always;PCI DSS v4.0 Requirement 11.6.1: Tamper Detection Mechanisms
Requirement 11.6.1 requires organizations to deploy a mechanism that alerts security teams to unauthorized modifications to the HTTP headers and script content of payment pages:
- Evaluation Frequency: Systems must inspect payment pages at least once every seven days or dynamically in real time.
- CSP Violation Reporting: Deploy CSP reporting directives (
report-to/report-uri) that stream telemetry to your SIEM whenever a rogue script attempts to inject into the checkout DOM or open unauthorized network connections. - Synthetic Checkout Probes: Run automated headless browser tests that verify script checksums and HTTP response headers on production checkout flows.
Requirement 11.3: Approved Scanning Vendor (ASV) Quarterly Scans
Requirement 11.3 mandates that organizations perform external vulnerability scans at least once every 90 days and after any significant infrastructure change. Scans must be conducted by an Approved Scanning Vendor (ASV) and achieve a passing score (zero vulnerabilities with CVSS >= 4.0).
Between mandatory quarterly audits, development teams should continuously verify fix regressions using the Wescequre Scan Diff Engine and track remediation progress directly in the Vulnerability Manager.
Prohibited Data: Never Store Sensitive Authentication Data (SAD)
Under PCI DSS Requirement 3.2, software applications are strictly prohibited from storing Sensitive Authentication Data (SAD) after payment authorization, even if encrypted:
- Never store the Card Verification Value (CVV/CVC/CVV2) under any circumstances.
- Never store the full content of the magnetic stripe or chip data.
- Never store the PIN or PIN block.
Storing CVV numbers in your database or in log files is an immediate, catastrophic compliance violation that triggers mandatory merchant revocation.
Common Mistakes to Avoid
❌Allowing marketing analytics, tag managers, or chat widgets on the checkout page
Why it happens: Marketing teams deploy Google Tag Manager or Hotjar sitewide.
Why it matters: Every script running on the checkout page has access to the DOM and can steal payment details. Violates PCI DSS Requirement 6.4.3.
Correct approach: Completely isolate checkout pages. Strip Google Tag Manager, analytics, and third-party chat widgets from the payment URL.
❌Logging raw credit card numbers or CVV codes in application debug logs
Why it happens: Developers log raw HTTP request bodies (`console.log(req.body)`).
Why it matters: Direct violation of PCI DSS Requirement 3.2; exposes unencrypted cardholder data to log aggregators.
Correct approach: Redact all 16-digit card numbers and 3-digit CVVs before any request data hits logging middleware.
Troubleshooting Guide
Problem: Payment gateway throws 'Invalid Card Token' on checkout
Possible Causes:
- Client-side JavaScript submitted form data before the hosted iframe finished tokenization.
How to verify: Inspect network waterfall in DevTools; verify token exchange finishes before form POST.
How to fix: Disable submit buttons until the payment processor's SDK fires the completion event with a valid token.
Actionable Checklist
Wescequre Platform · Compliance Diff
Security Regression & Diff Engine
Track scan-over-scan vulnerability status, verify fixes, and export evidence reports for SOC 2, ISO 27001, and PCI DSS.
Includes: Scan-to-scan vulnerability state diffs · Remediation verification audit logs · Exportable compliance summary reports
Frequently Asked Questions
While PCI DSS v4.0 was released in March 2022, the specific new requirements for checkout script integrity (6.4.3) and tamper detection (11.6.1) were designated as best practices until March 31, 2025, after which they become fully mandatory for all audits.
Yes. Using SRI hashes (`integrity="sha384-..."`) on static scripts guarantees that if a script is modified on a CDN, the browser will refuse to execute it. For dynamic scripts (like `js.stripe.com/v3`), automated CSP reporting and inventory management systems are required.
PCI DSS explicitly mandates TLS 1.2 or TLS 1.3 with forward-secrecy cipher suites across all endpoints transmitting payment data. See our [TLS/SSL Configuration Guide](/guides/vulnerability-scanning/tls-ssl-configuration).
Authoritative Sources & References
- PCI Security Standards Council: PCI DSS v4.0 Resource HubPCI SSC (official)View Source
- PCI SSC: Self-Assessment Questionnaire (SAQ) Instructions and GuidelinesPCI SSC (official)View Source
- OWASP: Client-Side Security & Digital Skimming (Magecart) DefenseOWASP (technical)View Source
Related Guides
Continue exploring related technical architecture and defensive guides
GDPR · compliance
GDPR Compliance for Developers: Architecture & Engineering Checklist
Developer blueprint for GDPR: personal data schemas, Article 17 right-to-erasure workflows, cryptographic shredding patterns, and audit log compliance.
SOC 2 · compliance
SOC 2 Compliance for SaaS: Trust Services Criteria Guide
Engineering blueprint for SOC 2 Type II readiness: automated CI/CD branch protection, centralized immutable audit logs, RBAC, and disaster recovery testing.
TLS · SSL
Modern TLS/SSL Configuration for Web Applications
Master enterprise TLS hardening: TLS 1.3 vs 1.2 differences, Perfect Forward Secrecy ciphers, OCSP stapling, CAA DNS records, and automated Certbot renewal.