Digital card skimming does not touch the card. Nothing is glued to a reader, nothing is inserted into a slot. Malicious JavaScript sits on a checkout page, reads the card number, expiry date and security code as they are typed into legitimate form fields, and posts a copy to a server the attacker controls. The payment goes through normally. The order arrives. Nobody at either end sees a failure, because there is no failure to see.
That is the version of skimming that matters to a merchant, and it is the version almost nothing written for search results explains properly. Most pages on the subject are written for the cardholder: check the reader for wobble, cover the keypad, watch your statement. Useful advice, wrong audience. This is written for the person who has to answer the question “is our checkout safe?”with evidence.
Digital card skimming versus a rigged card reader
Physical skimming needs hardware. A false fascia on a cash machine, a card reader overlay at a petrol pump, or a shimmer: a paper-thin device slid into the chip slot that sits between the card and the terminal and records the data passing through. The thief has to visit the site twice, once to fit and once to collect, unless the device transmits.
Digital card skimming needs none of that. The attacker changes code, once, remotely, and every buyer who reaches the payment step from then on donates their card details. There is no travel, no hardware cost, and no limit tied to a single machine. A single compromised script on a busy checkout out-earns a fortnight of fitting overlays to pumps. The mechanics of the theft at the moment of payment are covered in more detail in card skimming explained.
The vocabulary in your inbox will vary depending on who is writing. Acquirers and payment providers tend to say web skimming or e-skimming. Security vendors say JavaScript skimmer, or formjacking, which is the same thing described from the form’s point of view. Researchers and journalists say Magecart. All four describe the same theft. One variant now hosts its payload on the blockchain, which is why registrar takedowns fail against a skimmer that has no domain to seize.
Magecart is a label, not a gang. The name came from Magento plus cart, coined when researchers first saw the technique concentrated on Magento stores, and it has stuck as shorthand for dozens of separate and unrelated crews using the same method on every platform going. If an acquirer letter mentions Magecart, it is describing a technique, not identifying a suspect. The background to that name is worth reading once, because the confusion leads people to hunt for a single signature that does not exist.
Three routes a JavaScript skimmer takes into a checkout
Every real incident comes in by one of three doors. The door decides the defence, which is why the distinction is not academic.
A supplier script you embed but do not control
Ticketmaster UK, June 2018. The skimmer did not come from Ticketmaster’s code. It came from a JavaScript file served by a third-party chatbot supplier, embedded on pages that included payment pages. The ICO’s penalty notice of November 2020 fined Ticketmaster UK £1.25m and noted that Monzo had flagged suspected fraud among affected customers in April 2018, months before the script was removed. The same ICO penalty notice put the number of customers whose data was exposed at 9.4 million across Europe, around 1.5 million of them in the UK.
A chat widget has no business on the page where card numbers are typed.
A first-party file someone else edited
British Airways, 2018. The code that skimmed the payment page was served from BA’s own infrastructure, having been modified by an attacker who already had access. On the ICO’s own published figures, the original notice of intent was £183.39m in July 2019; the final penalty, issued in October 2020, was £20m, and the ICO’s penalty notice describes unauthorised access running for roughly two and a half months. Newegg was hit the same year by a short injection, a handful of lines added to its checkout, pointing at a look-alike domain.
No external supplier failed here. The file was already trusted, already served from the right place, already allowed.
A platform nobody patched
September 2020. Magento 1 had reached end of life in June that year. According to figures published at the time by Sansec, the Dutch security firm that tracks these compromises, roughly 1,900 Magento 1 stores were skimmed over a single weekend. No targeting, no reconnaissance, no clever supply chain. A known flaw in software that was no longer receiving fixes, exploited at scale.
VisionDirect, Macy’s, Claire’s and Warner Music Group are later variations on these same three routes rather than new categories. The pattern holds; eight of these incidents are set out side by side in this comparison of high-profile attacks and their entry points.
The lesson: route determines remedy. A Content Security Policy that blocks unknown script origins would have stopped the Ticketmaster route cold. It would have done nothing about British Airways, because the malicious code was appended to a file the policy already permitted. Patching would have saved the Magento 1 stores and had no bearing on either of the other two. Merchants who deploy one control and file the job as done are usually covering one route out of three.
How long a skimmer sits on a page before anyone notices
The detection story is depressingly consistent. The merchant hears from an issuing bank, an acquirer, or a customer who has worked out what all their fraudulent transactions have in common. Internal monitoring almost never speaks first, because a working skimmer breaks nothing. Error rates stay flat. Conversion stays flat. Page speed barely moves.
Skimmer authors put real effort into staying dull. Exfiltration goes to a domain that looks like a content delivery network or an analytics host, sometimes differing from a legitimate one by a single character. Data leaves as a query string on an image request, or base64-encoded, so a casual look at network traffic shows a pixel being fetched. Some skimmers geofence, firing only for visitors in particular countries. Many check the URL first and stay dormant until the shopper reaches the payment step, which means a developer clicking around a staging basket sees nothing at all.
If your card fields already sit inside a payment provider’s iframe, the attacker changes tactic rather than leaving. The common approach is an overlay: a convincing fake card form drawn on top of the real one, styled to match, which collects the details, hides itself, and hands the shopper on to the genuine fields to pay for real. The shopper pays twice in effort and once in money, and notices neither.
Stolen card data rarely gets used in bulk straight away. Small-value authorisations come first, testing which cards are still live, often against low-friction merchants such as charities or digital goods. Sorted and validated, the cards are then sold on. Your fraud chargebacks are the tail end of that process, not the start of it.
Signs your payment page is skimming cards right now
None of these checks is proof on its own. Together they give you something better than hope.
- Audit what the checkout actually loads. Open the payment step in a browser with developer tools recording network requests, then compare the list of script origins against the list you believe should be there. Do it as a real shopper would, with items in the basket and the payment step reached. Any domain you cannot name and justify is your first question.
- Read your own first-party files. Skimmers are frequently appended to the end of an existing, legitimate script. Look for obfuscated blocks, long encoded strings, and event listeners attached to card inputs (keyup, blur, change, or submit handlers on the payment form) that no one on your team wrote.
- Check the entry points, not just the page. Admin account list and last-login times. Extension and plugin inventory, including anything installed years ago for a campaign that ended. File modification dates that do not line up with your deployment history. Platform patch level, and whether the version you run is still supported at all.
- Treat outside signals as evidence. A common point of purchase alert from an acquirer naming your store is not noise to be argued with. It is the single strongest indicator available, and it usually arrives before anything you own reports a problem.
The step-by-step version of this inspection, including what obfuscated code tends to look like in practice, is in the guide on how to tell if your checkout has been skimmed.
Hosted payment fields, CSP and SRI: which defence fits your checkout
Hosted payment fields and redirects
Hosted payment fields put the card inputs inside iframes served by your payment provider, so the card number never enters your page’s document object model. Your JavaScript cannot read it, which means an attacker’s JavaScript cannot either. At configuration level, this is the largest single reduction in skimming risk available, and it is usually a day of developer work rather than a purchase. A full redirect to the provider’s own page goes further still, because the shopper leaves your site entirely, at the cost of control over the payment experience. Hosted fields are the reasonable middle: your styling, your page, their inputs.
What it does not do is remove the threat. An attacker who can change your page can still draw a fake form over the top of the iframe, swap the iframe source for one of their own, or simply harvest name, delivery address, email and account password, none of which are inside the provider’s frame. The threat model shifts. It does not vanish. The trade-offs are set out in the piece on hosted payment fields as the cheapest way to cut skimming risk.
Content Security Policy
A Content Security Policy is an HTTP header telling the browser which origins may load scripts and, through connect-src and form-action, where data may be sent. Done properly it blocks the supplier-script route and the exfiltration endpoint at the same time.
CSP on a live checkout fails for boring reasons. Inline event handlers baked into checkout templates years ago. A tag manager or analytics script that injects further scripts at runtime, from origins that change without notice. A payment provider that quietly adds a domain. Start in report-only mode, collect violations across a full trading cycle including a weekend and a promotion, and read them. Teams that skip that step ship an enforcing policy, break the payment step at 9am, and roll it back by 10, after which nobody is allowed to mention CSP for a year. The working checkout policy walkthrough covers the directives that matter.
And CSP is blind to the British Airways route. Code appended to a file your policy already allows runs happily.
Subresource Integrity
Subresource Integrity pins a remote script to a cryptographic hash. If the file changes by one byte, the browser refuses to execute it. Against a supplier whose file should never change, that is precise protection.
The maintenance tail is what the tutorials omit. The supplier pushes a legitimate update, the hash no longer matches, the browser blocks the script, and on a checkout that can present as an outage. SRI is right for genuinely static assets, and it needs a named owner and a supplier change notification arrangement behind it, not a one-off implementation ticket.
Order of work for a small team
Reduce the surface first: remove every script from the payment page that does not need to be there, and move the card fields into hosted fields. Then constrain what remains with CSP, report-only until the reports are quiet. Then pin what is static with SRI. Keep patching underneath all of it, because the Magento 1 stores were not undone by a missing header.
What PCI DSS 4.0 now asks about the scripts on your payment page
Two requirements stopped being future-dated on 31 March 2025, and both are about the payment page specifically.
PCI DSS 4.0 requirement 6.4.3 asks you to manage every script loaded and executed in the consumer’s browser on the payment page: a method to confirm each script is authorised, a method to assure its integrity, and a written inventory with a business justification for each one. Requirement 11.6.1 asks for a change and tamper detection mechanism that alerts personnel to unexpected modifications to the HTTP headers and the content of the payment page, checked at least weekly.
Scope matters here and gets muddled. These requirements bite hardest on merchants completing SAQ A-EP or SAQ D, where the merchant’s own page affects the security of the payment transaction. For SAQ A, the Council published a revised version in January 2025 which removed 6.4.3 and 11.6.1, but added an eligibility condition requiring the merchant to confirm the site is not susceptible to attacks from scripts that could affect the payment page. Read plainly, that is the same question asked in one sentence instead of two requirements. Check the current documents in the PCI SSC document library against your own setup rather than taking a vendor’s word for which form applies to you.
Neither requirement obliges you to buy anything. A script register in a spreadsheet, one row per script, with purpose, owner and review date, satisfies the inventory and justification. A CSP report-only endpoint that someone actually reads gives you authorised-origin monitoring. A scheduled job that fetches the rendered payment page, hashes or diffs it against a known-good baseline, and emails on difference, gives you 11.6.1. Commercial tooling does this with less effort and better reporting, and for a large estate that is money well spent. For a single checkout it is optional. What is not optional is having the evidence when your acquirer asks. The detail of both requirements is broken down in this guide to 6.4.3 and 11.6.1.
The first 48 hours after you confirm a skimmer
Contain, but do not scrub. The instinct is to delete the malicious lines and redeploy from a clean build immediately. Take copies first: the modified files, web server and application logs, admin access records, and a saved snapshot of the rendered payment page including the network request list. Forensics without evidence is guesswork, and card brand investigators will ask for exactly what you deleted at 2am.
Then establish the window. File modification timestamps, version control history, deployment logs and the first appearance of the exfiltration domain in logs give you a start date. Everything from that date to the removal is potentially exposed, which tells you how many transactions and customers are in scope.
Tell your acquirer and payment provider straight away; they may have obligations to the card brands that run on their own clock, and above certain volumes the brands can require an approved PCI Forensic Investigator rather than your own team or agency. Where personal data is involved, and with a skimmer it always is, the UK GDPR deadline is notification to the Information Commissioner’s Office within 72 hours of becoming aware, where the breach poses a risk to people’s rights and freedoms. The ICO sets out what it needs in its guidance on reporting a breach. Customers need telling where there is a high risk to them, in plain language, with the advice to contact their bank.
Rebuild rather than patch over. Rotate every admin credential, API key and integration secret, on the assumption the attacker had them. Rebuild from a known-good source rather than cleaning in place. Cut the extension list down to what is genuinely in use. Patch or migrate the platform if the route in was an unsupported version. And add the detection you did not have, so that the next attempt is found by your own alert rather than by a bank.
The short version
Digital card skimming is code on your page, not hardware on a terminal, and it arrives by one of three routes: a supplier script, a first-party file that was edited, or a platform that was not patched. Each route has its own remedy, so one control is never enough. Move the card fields into hosted payment fields, then constrain the page with CSP starting in report-only, then pin the static third-party files with SRI, and keep the platform current underneath. Write down every script on the payment page with a reason and an owner, and diff the rendered page against a baseline on a schedule; that covers requirements 6.4.3 and 11.6.1 without a purchase order. On the ICO’s own figures, British Airways cost £20m and Ticketmaster UK £1.25m in penalties for breaches of this shape. The script inventory costs an afternoon.
Frequently Asked Questions
What is digital card skimming, and how is it different from skimming at a cash machine?
Digital card skimming is malicious JavaScript on a checkout page that reads card details as they are typed into legitimate form fields and sends a copy to an attacker’s server. Skimming at a cash machine needs physical hardware, such as a card reader overlay or a shimmer inserted into the chip slot. The theft is the same; the scene is code rather than hardware, and one change to a website reaches every shopper rather than every user of one machine.
How would I know if a JavaScript skimmer is running on my checkout?
Load the payment step in a browser with developer tools recording, and compare the script origins actually requested against the list you expect. Read your own checkout scripts for appended or obfuscated code and for event listeners on card inputs that nobody wrote. Check admin accounts, extension inventory, file modification dates and patch level. Take issuer fraud reports and common point of purchase alerts naming your store as evidence, not noise.
Do hosted payment fields stop digital card skimming completely?
No, but they remove the card number from your page, which is the biggest single risk reduction available at configuration level. An attacker who can still modify your page may overlay a fake card form, alter the iframe source, or harvest name, address, email and account credentials. Hosted fields change the threat model rather than closing it, so page integrity monitoring is still needed.
Does PCI DSS 4.0 require me to monitor the scripts on your payment page?
Requirement 6.4.3 requires an inventory of scripts on the payment page with a written justification and authorisation for each, and 11.6.1 requires change and tamper detection that alerts on unexpected modifications, checked at least weekly. Both became mandatory on 31 March 2025. Which self-assessment questionnaire applies to you determines how they are evidenced, and the SAQ A revision published in January 2025 replaced them with an eligibility condition about script susceptibility, so check the current documents against your setup.
What should I do first if I find a skimmer on my payment page?
Preserve evidence before you clean: copy the modified files, the relevant logs and a snapshot of the rendered page. Then remove the code, work out the exposure window from deployment and modification history, and notify your acquirer and payment provider. Where personal data is affected, the ICO must be told within 72 hours of becoming aware if there is a risk to individuals, and credentials, API keys and the extension inventory all need reviewing before you call it closed.