Ecommerce payment-page security: prevent e-skimming before card data reaches the processor

An ecommerce merchant can outsource the card form and still have a website capable of compromising the payment journey. Malicious scripts, altered redirects and vulnerable plugins can skim card data before or during checkout, so payment-page security needs to cover the merchant's own webpage as well as the processor.

E-skimming attacks target the page around the payment form

PCI SSC's payment-page guidance focuses on attacks in which malicious scripts or unauthorised changes capture payment information or redirect customers during ecommerce checkout. A merchant can use a secure third-party processor and still expose customers if its own website is compromised.

This is especially important where third-party JavaScript, tag managers, analytics and marketing tools execute on checkout pages. Every script adds functionality but also increases the number of components that can affect the customer's browser session.

PCI DSS v4.0.1 added stronger payment-page controls

PCI SSC's guidance for requirements 6.4.3 and 11.6.1 addresses managing payment-page scripts and detecting unauthorised changes to HTTP headers and page content. The requirements became effective in 2025 for entities to which they apply.

Merchants should work with their acquirer or assessor to determine scope. Do not copy a technical control from another merchant without understanding whether the business uses a hosted page, redirect, embedded iframe or fully integrated card form.

Create an inventory of scripts allowed to run on checkout

List each script, owner, purpose, source and reason it is necessary. Remove abandoned plugins and tags. A script added for a short marketing campaign should not remain indefinitely with access to the checkout page.

Use change control so new scripts require review before production. The objective is not to ban JavaScript; it is to know what executes around payment and to detect unexpected code. A merchant that cannot list its checkout scripts will struggle to recognise malicious additions.

Redirect and iframe models still leave merchant-side work

PCI SSC's current SAQ A guidance confirms that merchants using redirects or embedded third-party iframes can still have obligations relating to the security of the ecommerce webpage. The merchant's page can influence where the customer is sent or what code runs around the payment element.

Keep the hosted-payment provider's compliance evidence, but also patch the content-management system, ecommerce platform, plugins and administrator accounts. Outsourcing the card fields narrows card-data handling; it does not outsource the entire website.

Use vulnerability scanning and change detection where required

PCI SSC clarified in 2026 that SAQ A ecommerce merchants can have Approved Scanning Vendor requirements even when payment processing is fully outsourced. Merchants with broader scope can have additional internal and external testing obligations.

Review failed scans rather than filing them. A vulnerability in an internet-facing marketing plugin can be relevant if the same site controls checkout. Keep remediation evidence and rescan where the compliance process requires it.

Have a checkout incident plan before customers report fraud

If an unexpected script, redirect or checkout modification is discovered, preserve evidence and involve the payment provider, acquirer and security team immediately. Consider whether card data or authentication information could have been exposed during the affected period.

Maintain deploy logs, administrator access records and third-party script history so investigators can determine when the change occurred. Fast rollback is important, but deleting the evidence before understanding the breach can make the incident harder to contain and report.

Use a checkout change log that records deployment date, developer, reason, scripts added or removed and rollback plan. A payment-page incident becomes much easier to investigate when the security team can compare today's code with a known approved state. This is especially valuable for businesses using several agencies or marketing tools that can modify production pages.

Minimise administrator privileges around ecommerce systems. A compromised content-management account can be enough to inject malicious JavaScript even when the payment form is hosted elsewhere. Require multi-factor authentication, remove dormant users and separate developer access from everyday marketing access where the platform permits. Payment-page security is partly a web-governance problem, not only a card-processing problem.

Test the customer's path after major changes. Verify that the checkout redirects to the expected provider, the TLS certificate and domain are correct, no unexpected scripts execute and the confirmation page returns to the merchant normally. A short controlled test after deployment can catch broken or suspicious behaviour before customers do.

Maintain a dependency list for third-party scripts and plugins that can affect checkout. If a vendor announces a vulnerability, the merchant should know immediately whether that component runs on payment pages and who can disable or patch it. Asset inventory turns generic security news into an actionable decision.

Use content-security and browser-security controls where appropriate with developer guidance, but do not treat one header as complete protection. Payment-page security combines approved scripts, change detection, vulnerability management and access control. Defence in depth matters because attackers often exploit the weakest website component rather than the card processor.