eCommerce Security: Don’t Host Your Own Payment Pages or Forms

If you sell online, the single best security decision you can make is not to collect, transmit, or store cardholder data on your own infrastructure. Don’t host your payment pages or forms. Push that risk—and the compliance scope that comes with it—to a specialized, PCI-certified provider.

Why Self-Hosted Payment Forms Are a Bad Idea

• They massively expand your attack surface. Any compromise on your site—theme/plugin exploit, admin takeover, supply-chain script injection—can lead to a card skimmer (Magecart/web-skimming) harvesting every keystroke.
• They increase PCI DSS scope and cost. Touching Primary Account Number (PAN) anywhere on your servers drags your whole stack into scope: systems, networks, logging, change control, segmentation, scans, pen tests, and more.
• They’re fragile by design. Modern sites include dozens of third-party scripts (analytics, chat, A/B testing). Any one of them can be abused to silently insert malicious code into your checkout.

What “Don’t Host Payments” Actually Means

Use a payment model where the card data never traverses your servers:

• Hosted Payment Page (HPP / redirect): Your checkout button sends the user to the PSP’s domain (e.g., pay.example-psp.com). The form, JavaScript, and submission all live there. You get a success/failure result and an order token back.
• Hosted Fields / Tokenized Elements (iFrames): Card number, expiry, and CVC inputs are provided by the PSP as isolated iFrames. Keystrokes go directly from the browser to the PSP; you only receive a token. Your origin never sees PAN.

Compliance note: Fully hosted redirects and true PSP-hosted fields commonly qualify you for lighter PCI SAQ categories (often SAQ A). Implementations that render forms on your domain and post PAN to the PSP typically fall under SAQ A-EP and bring substantially more controls. Confirm scope with your QSA and PSP.

Patterns We Recommend

1) Full Redirect (Hosted Payment Page)

• Pros: Simplest to secure; minimal PCI scope; skimmers on your site can’t see the payment form.
• Cons: UX shift to another domain; need careful handling of order state and webhooks.

2) PSP-Hosted Fields (Tokenization via iFrames)

• Pros: Native checkout UX on your domain; PAN never touches your origin; generally light PCI scope.
• Cons: Requires disciplined front-end integration; CSP and frame policies must be correct.

If You Absolutely Must Handle Forms (Not Recommended)

Sometimes legacy constraints force your hand. If you’re in that situation, treat the payment path like a hazardous materials zone:

• Isolate the checkout origin: Use a separate hardened subdomain and segmented infrastructure. No shared admin, plugins, or CI/CD with your marketing site.
• Lock down third-party code: Strict Content-Security-Policy with allow-listed script sources; use require-trusted-types-for 'script' where possible. Remove non-essential tags from checkout.
• SRI for static assets: Add integrity + crossorigin to all third-party JS/CSS you must keep.
• Form hardening: Disable autocomplete for card fields, enforce HTTPS + HSTS, and never log request bodies or headers that could contain PAN.
• Continuous integrity checks: Monitor DOM/script changes, compare deployed assets to known hashes, and alert on drift.
• Edge protection: Put a WAF in front, rate-limit sensitive endpoints, and challenge automation. Block known bad ASNs and use reputation feeds.
• Operational discipline: 2FA everywhere, least-privilege access, signed releases, and auditable change windows for checkout code.

Defending Against Web-Skimming (Magecart)

• Reduce cardinality of scripts: Fewer dependencies = fewer places to hide skimmers.
• Lock CSP for payments: Separate CSP policy just for the checkout route; block inline/eval; allow only your PSP and essential CDNs.
• Monitor exfiltration patterns: Alert on POSTs/XHRs to unexpected domains, base64 beacons, or image src “pings” on payment steps.
• Instrument RUM: Capture JS errors and unusual timing on the payment page; skimmers often introduce subtle performance changes.

Incident Response (If You Suspect a Skimmer)

1. Freeze checkout by switching to full PSP redirect immediately.
2. Rebuild from trusted sources: Verify hashes for all third-party libraries and theme assets.
3. Rotate keys/credentials (admin, CI/CD, PSP webhooks, JWT secrets).
4. Notify your PSP and follow applicable regulatory/customer notification requirements.
5. Increase logging at the edge and review outbound requests from checkout sessions.

Quick Checklist

• Use hosted payment pages or PSP-hosted fields; avoid merchant-hosted card forms.
• Tokenize everything; never store PAN/CVC; prefer network tokens where available.
• Apply strict CSP + SRI on checkout; remove non-essential third-party scripts.
• Segment infrastructure; enforce least privilege and signed releases.
• Put a WAF/CDN in front; enable bot controls, rate limits, and anomaly detection.

Bottom line: don’t host payments. Push card data handling to providers built for it, and keep your energy focused on product and customer experience.