Cybersecurity for e-commerce and retail, tested from checkout to the payment page

Common threats include account takeover through credential stuffing, skimming scripts on payment pages, checkout and loyalty logic abuse, API abuse, insecure mobile apps, attacks on point-of-sale devices and store networks, phishing of staff, and ransomware. Each targets customer accounts, payment data or stored value, and each needs a different test.

E-skimming is malicious script on a checkout or payment page that copies card data as shoppers type it. We review which scripts load on your payment pages and test the paths an attacker could use to add or change one, such as a compromised third-party script, an exposed admin panel or stored cross-site scripting. Detecting script changes in production is a separate PCI DSS control (Requirement 11.6.1).

Where Requirement 11.4 applies to you, yes. PCI DSS v4.0.1 Requirement 11.4 requires internal and external penetration testing at least once every 12 months and after significant changes, and segmentation testing if you use segmentation to reduce scope. Which requirements apply depends on how your payment pages are built and which self-assessment questionnaire or report you complete. See PCI DSS penetration testing.

No. ioSENTRIX is not a PCI Approved Scanning Vendor (ASV) or Qualified Security Assessor (QSA). We perform the penetration testing required by PCI DSS v4.0.1 Requirement 11.4 and write reports your QSA can review. Quarterly external scans under Requirement 11.3.2 must come from an ASV. See PCI DSS penetration testing.

Both cover payment pages. Requirement 6.4.3 calls for an inventory of payment-page scripts with a written justification for each, and methods to confirm each script is authorized and intact. Requirement 11.6.1 calls for a mechanism that alerts on unauthorized changes to those scripts and to security-impacting HTTP headers. Whether they apply to you depends on how your checkout is built, including whether you embed a third party's payment form, so confirm with your QSA or acquirer.

We place test orders as different customer types and change prices, quantities, coupons, gift card and loyalty values and the order of steps in transit, to find what the server accepts that it should not. Findings are proven on agreed test orders and mapped to the OWASP API Security Top 10 (2023).

A web application penetration test typically takes 1–2 weeks and a red team exercise typically 4–6 weeks, depending on scope. You receive a written scope and timeline before testing starts, so you can plan around peak trading.