Payment page client security

Use this as a payment-page evidence pass, not as a generic security checklist and not as PCI certification. The goal is to collect reviewer-ready evidence about whether card data stays out of merchant JavaScript, payment-page scripts are known and justified, and script/header tamper signals are observable.

Scope and non-goals

• Cover browser/client code, checkout page composition, hosted payment iframes/fields, redirects, CSP/SRI/header evidence, logs, storage, analytics, tag managers, replay tools, and payment-page script monitoring.
• Do not decide legal PCI scope, SAQ eligibility, QSA acceptance, or whether a site is "PCI compliant." Say "PCI evidence/risk discussion," not "compliance verdict."
• For generic XSS, token storage, open redirects, or CSP hardening outside payment context, use frontend-security-baseline first.
• For native WebView bridge messages around checkout, pair this with webview-bridge-pages.

Workflow

1. Classify payment architecture. Identify redirect, hosted iframe, hosted fields, wallet, direct merchant card form, saved-card flow, or non-card flow. This determines what frontend code can see.
2. Draw the PAN boundary. PAN/CVV/CVC should not enter merchant-controlled DOM inputs, framework state, logs, analytics, storage, URLs, replay tools, error breadcrumbs, or telemetry unless the project intentionally owns full cardholder-data handling.
3. Inventory browser-executed code on the payment path. List first-party, third-party, inline, dynamically injected, tag-manager, analytics, chat, A/B, replay, and payment-provider scripts that actually execute on checkout/payment URLs. package.json source imports are not enough.
4. Check authorization and justification evidence. Each payment-path script should have an owner, purpose, approved source, and business/technical justification. "Loaded by GTM" is not justification by itself.
5. Check integrity and tamper evidence. Prefer provider-compatible controls: narrow CSP (script-src, connect-src, frame-src, form-action), nonces/hashes for first-party inline code, SRI only where bytes are stable, and change detection/alerts for payment-page scripts and security-impacting headers.
6. Separate risk from compliance claims. Map findings to PCI DSS 6.4.3 / 11.6.1 / SAQ A signals only as reviewer-facing evidence. Escalate ambiguous scope to a payment/security owner.