SELL MORE
BREACH LESS.
Card skimming happens in the customer's browser, and fraud happens through requests your application considers valid. We test the checkout path, the commerce logic, and the scripts you did not write.
THE E-COMMERCE THREAT MODEL
Your checkout page runs other people's code
Analytics, tag managers, chat widgets, personalisation, A/B testing, affiliate tracking. Any of them can read the card field. Client-side skimming works because the compromise happens in a vendor's build and arrives in the customer's browser, never touching your servers or your logs.
Fraud is a business logic discipline
The adversary is not exfiltrating a database, they are buying a television for nine pounds. Discount stacking, refund-before-return, price and currency tampering, gift card enumeration, and inventory races are all sequences of legitimate requests in an unintended order.
Accounts hold stored value
Saved cards, loyalty points, store credit and address books make credential stuffing directly monetisable. Account takeover is a fraud channel here. Rate limiting and bot defence are part of the tested surface.
WHAT DRIVES THE REQUIREMENT
For an ecommerce operation, testing is rarely optional. Card data, acquirer rules and the customer trust behind a checkout all assume the platform has been adversarially tested.
PCI DSS 4.0
Requirements 6.4.3 and 11.6.1 specifically address scripts on payment pages and detection of unauthorised change to them, which is the direct regulatory answer to client-side skimming.
Acquirer and payment partner requirements
Acquiring banks and processors commonly require testing evidence at onboarding and after material change to the checkout flow.
GDPR / UK GDPR and consumer privacy law
Customer records, purchase history, and address data carry notification duties and, in the case of skimming, an extended exposure window before discovery.
Consumer protection and chargeback exposure
Fraud losses from logic abuse land as chargebacks and scheme penalties, which is a commercial obligation even where no regulator is involved.
WHAT WE TEST
Checkout & payment path
- Third-party script inventory and skimming injection paths
- Content Security Policy and subresource integrity enforcement
- Payment gateway integration and callback tampering
- Stored card and tokenisation flow validation
- DOM-based injection in the payment context
Commerce logic & pricing
- Price, currency, and quantity manipulation, including negative values
- Discount stacking, coupon brute force, and promotion replay
- Refund and return sequencing abuse
- Inventory and checkout race conditions
- Gift card and store credit enumeration and transfer
Accounts & customer data
- Credential stuffing resistance and account takeover chains
- Loyalty balance manipulation and transfer
- Session fixation, hijacking, and replay
- Customer PII exposure through APIs, exports, and order lookup
- Guest checkout and order-status enumeration
HOW WE WORK
Machine-speed exploitation across the order lifecycle, not a crawl of the storefront. What counts as a defect versus an intended promotion rule is decided by someone who understands the business.
Commerce surface mapping
Inventory every path an order can take and every script that loads alongside it, across web, mobile, and marketplace channels.
Threat modelling
Two distinct adversaries: the skimming operator working through your vendors, and the fraud operator working through your business rules. They need different tests.
Agentic exploitation
Agent swarms work pricing, promotion, refund and inventory logic in parallel, plus injection in the checkout context, and carry each candidate through to a working exploit. Value extracted is demonstrated, not theorised. Whether an extractable path is a defect or an intended promotion rule is the human call.
Evidence and control mapping
Findings mapped to PCI DSS where the cardholder data environment is in scope, with remediation guidance written for the engineers who own checkout.
WHAT YOU RECEIVE
WHEN COMMERCE BREAKS
Public disclosures worth reading closely. The pattern is consistent: the payment page was compromised through something the retailer did not write and could not see.
British Airways
2018Skimming code was injected into a script served by the payment page and ran for over two weeks before discovery.
Hundreds of thousands of cards taken; a £20M ICO penalty. Server-side logs showed nothing.
Ticketmaster UK
2018A third-party chatbot supplier was compromised, and its widget captured payment data from the checkout page.
The vendor's build pipeline was the root cause. The retailer carried the notification duty and the penalty.
Newegg
2018Fifteen lines of JavaScript added to the payment page shadow-captured card data for over a month.
Detection came from an external researcher, not internal monitoring. Script integrity checking would have caught it on day one.
Magecart campaigns, ongoing
2015-A long-running family of client-side skimming campaigns targeting compromised store platforms, plugins, and hosted script vendors at scale.
The technique persists because most stores still cannot enumerate, pin, or monitor the scripts running at checkout.
FREQUENTLY ASKED
Can you test live checkout without disrupting real orders?+
Destructive and fraud-logic testing runs against staging or processor sandbox credentials. Against production we use non-settling transactions that never reach the acquirer, and agree in advance which actions are off limits. Where a finding needs a real settlement to confirm, we ask first.
How do you test for client-side skimming?+
We enumerate every script loaded in the checkout context and its ultimate origin, test whether Content Security Policy and subresource integrity actually constrain them, look for DOM injection paths into the payment fields, and then simulate a skimmer to see whether anything detects it. Most environments fail the last step.
Do you test the marketplace and mobile channels too?+
If they are in scope. Mobile apps and marketplace integrations frequently reach the same order and pricing APIs with weaker checks than the web front end, because the client is assumed to be trusted. That assumption is usually where the logic findings are.
What do you typically find in commerce environments?+
Pricing and promotion logic enforced client-side or trusted from the request, refund flows that do not verify a return, order and customer objects retrievable by sequential identifier, and checkout pages loading scripts nobody in the business can account for.
Find out what a determined customer can buy for nothing
Tell us how your checkout is assembled and which vendors run inside it. We will scope the engagement around the order lifecycle.