Card skimming explained in one line: it is the copying of payment card details at the moment of payment, without the cardholder noticing, so the details can be used or sold somewhere else. Most explanations of card skimming stop at a plastic overlay glued to a cash machine. That is a real crime and it still happens. In the UK it is now the smaller half of the picture.
Chip and PIN, and then contactless, stripped most of the value out of a cloned magnetic stripe. Card-not-present details did not lose their value at all. A long number, an expiry date, a CVV and a billing address still work on thousands of websites. So the skimmer moved upstream, into the checkout page, where the device is a few lines of JavaScript and there is nothing to feel with your thumb.
This piece sets the two forms side by side: how the data is taken, what the signs are, how quickly anyone notices, and the question the definition pages skip. Who actually pays.
Card skimming explained: one crime, two very different attacks
Both routes attack the same gap. Card data has to exist in readable form for a moment, between the cardholder entering it and the payment being authorised. Encryption protects the data in transit and at rest. It does not protect the keystroke.
The physical route intercepts that moment at the terminal. An overlay reader sits on the card slot and reads the stripe as the card goes in. A shimmer, a wafer-thin board slipped inside the slot, reads what the chip sends. The PIN is captured separately, by a pinhole camera above the keypad or a false keypad laid over the real one.
The digital route intercepts the same moment in the browser. A script on the payment page reads the card fields as they are filled and sends a copy to a server the criminal controls. The payment then completes normally. A fuller walk-through of that mechanism sits in the explainer on how card details are stolen at the moment you pay.
The difference that matters is detection time. A physical skimmer is an object. Somebody can find it, photograph it and remove it. A script has no weight, no residue and no tool marks. It runs for as long as nobody looks.
How physical skimmers still work, and where they turn up
Unattended terminals take the pressure. Cash machines in unsupervised lobbies, petrol pump readers, car park machines, ticket kiosks. Nobody is standing next to them for hours at a time, the enclosures are often opened with common service keys, and a stranger crouching at a pump looks like a stranger paying for petrol.
Staffed tills are harder. Not impossible, but a terminal swap at a counter needs a distraction or an insider, and staff who handle the same device every day tend to notice when it feels different.
The checks available to a cardholder are crude and still worth doing:
- Pull gently at the card slot and the fascia around it. A factory part does not move.
- Look for plastic that does not match the machine in colour, gloss or wear, and for adhesive residue at the edges.
- Check for anything sitting above the keypad that has no obvious purpose, such as a raised strip or a mirror.
- Check the keypad itself. An overlay usually sits proud and the keys feel spongy.
- Cover your hand over the keypad when entering the PIN. A camera without a PIN has very little.
There is a ceiling on this route, and criminals hit it years ago. A cloned stripe is largely dead at a UK chip terminal, so the data goes overseas or into card-not-present fraud. If the end use is card-not-present anyway, why stand at a petrol pump at all.
Digital card skimming: three ways code gets onto a checkout
Skimming code reaches a live payment page by one of three routes. Nearly every documented incident fits one of them.
A compromised third-party supplier script
The merchant is not breached. A supplier is, and the merchant loads the supplier’s JavaScript on the payment page. Ticketmaster UK in June 2018 is the standing example: the code arrived through a chatbot supplier’s script running on the payment flow. The ICO issued a £1.25m fine in November 2020.
Analytics tags, session replay, chat widgets, review widgets, A/B testing tools. Each one is a piece of code you do not write, do not review and cannot patch. A chat widget has no business on the page where card numbers are typed.
Injected first-party code after access is obtained
Here the attacker gets into the merchant’s own estate, through admin credentials, hosting, a build pipeline or an exposed storage bucket, and edits a first-party file. British Airways is the reference case. The compromise on the payment flow ran from 21 August to 5 September 2018, roughly a fortnight. The ICO’s final penalty in October 2020 was £20m, reduced from a notice of intent of £183.39m issued in 2019.
This route defeats controls aimed at third parties. The script is yours, served from your domain, and a content security policy that trusts your own origin will not blink at it.
An unpatched platform
The bulk route. Magento 1 reached end of support in June 2020, and in September 2020 the security firm Sansec reported that around 2,000 Magento 1 stores were skimmed over a single weekend. No targeting, no reconnaissance. Scan, exploit, inject, repeat.
One point that changes how you defend: Magecart is a name for a method, not a group. Unconnected crews reuse the same skimmer families, the same loaders and the same tricks, then swap infrastructure weekly. Blocking one exfiltration domain, or reading one incident report and treating its indicators as a checklist, protects you against the incident that already happened. It does nothing about the next one.
Signs of a payment page skimmer, and why merchants find out last
There is no tell on the surface. The checkout renders correctly, validation behaves, the order completes, the confirmation email arrives. A working skimmer gives nobody a reason to look.
So the first credible signal is usually external. Issuers and acquirers run common point of purchase analysis: when fraudulent cards share one recent merchant, that merchant gets flagged. The Ticketmaster case shows the lag. According to the ICO’s November 2020 penalty notice, banks raised concerns from April 2018, and the malicious code was not identified until June. If your acquirer sends you a fraud report, the correct response that day is a checkout audit, not a reply explaining why it cannot be you.
What to look for yourself, in a browser, on the live site:
- Script origins in the network tab that you cannot account for, especially anything loading only on the payment step.
- Long base64 or hex-encoded blocks inside first-party JavaScript, particularly appended to the end of a legitimate file.
- Outbound requests that fire on field blur or form submit, to a domain that is not your payment provider. Image requests and beacons count.
- Duplicate card fields drawn over the top of your provider’s iframe. The real iframe still exists underneath, which is why the payment succeeds.
- Recent modification timestamps on checkout templates, admin accounts nobody created, and extension or plugin updates that do not appear in your change log.
One caveat that trips people up. Many skimmers check whether developer tools are open, or match the visitor against a device and geography profile, and stay dormant if the conditions look like an inspection. Checking from the office network, on the machine you always use, with devtools pinned open, is the weakest possible test. There is a more detailed procedure in the guide on how to tell if your checkout has been skimmed.
Who pays when card details are skimmed in the UK
The cardholder usually does not, in the end. Under the Payment Services Regulations 2017, a payment service provider must refund an unauthorised transaction, with limited exceptions for fraud or gross negligence by the customer. The consumer loss is disruption, a replaced card, and several days of inconvenience.
The merchant carries the commercial weight. Card-not-present fraud is charged back to the merchant. Add scheme fees, the cost of a forensic investigation if the acquirer requires one, the cost of rebuilding a platform you can no longer trust, and the possibility that the card schemes recover issuer losses through your acquirer, who passes them to you.
Then the regulator. Both UK fines above were issued for security failings that allowed the compromise, not for the theft itself. That distinction matters: the question asked afterwards is what controls were in place and whether they were reasonable for the data being handled.
The quiet cost is the window. A skimmer that runs for a fortnight has taken every card entered in that fortnight. The bill is set by the number of transactions between injection and discovery, not by what happened on the day you found it. Halving your detection time halves the loss. Nothing else in this article has that.
What actually stops each kind of skimming
Physical terminals
Tamper-evident seals with recorded serial numbers, so a swapped unit shows up on inspection. A written inspection routine for unattended devices, performed on a schedule and logged. Photographs of each terminal as installed, for comparison. Staff trained to challenge unannounced engineers and to check the device against the photograph, not against memory.
Online checkouts, cheapest control first
Start by taking the card input out of your page. Hosted payment fields place the card inputs inside the provider’s iframe, in a separate origin your page cannot read. That removes the card number from the reach of your own JavaScript, which is the single largest reduction in risk available for the money.
It is not immunity. Hosted fields do nothing for name, billing address, email and phone, all of which are still typed into your DOM and all of which have value. They also do nothing about a skimmer that hides the iframe and draws a convincing fake card form in its place. Treat hosted fields as scope reduction.
Next, a Content Security Policy, started in report-only mode so you learn what your page actually loads before you break anything. The trap is the tag manager. If script-src allows a tag container plus inline execution, anyone with publishing rights in that container can ship arbitrary code to your payment page, and the policy will permit it. A broad allowance makes the directive close to decorative.
Then Subresource Integrity hashes on third-party scripts, so the browser refuses a file whose contents have changed. SRI is the control merchants abandon fastest, and the reason is mundane: a supplier pushes a routine update, the hash no longer matches, the script fails silently, and somebody removes the attribute to make the problem go away. Pin stable versioned URLs, agree change notifications with the supplier, and write down who refreshes the hash and when.
Finally, the compliance floor. PCI DSS 4.0 requirements 6.4.3 and 11.6.1 stopped being future-dated on 31 March 2025. Read plainly, 6.4.3 asks for an inventory of every script on the payment page with a written reason why each one is there and evidence of its integrity, and 11.6.1 asks for change and tamper detection on that page and its HTTP headers. Neither obliges you to buy a product. A maintained spreadsheet, a CSP report-uri endpoint collecting violations, and a scheduled hash comparison of the checkout page and its scripts will satisfy both, and the detail of that sits in the breakdown of what 6.4.3 and 11.6.1 ask of your payment page. Confirm the current text with your QSA or on the PCI Security Standards Council site before you build the process.
The short version
Physical skimming copies a card at the terminal and needs an object you can find. Digital skimming copies it in the browser and needs a script nobody reads. In the UK the second is where the volume is, because card-not-present data still spends.
Cardholders are usually made whole under the Payment Services Regulations 2017. Merchants absorb chargebacks, fees, investigation costs and regulatory attention, and the size of that bill is decided by how long the code ran.
Take the card fields out of your page. Cut the scripts on the payment page to the ones you can justify in writing. Run a CSP in report-only mode until the reports are clean, then enforce it. Watch the page for change, weekly at minimum. And when an acquirer tells you cards are turning up with your name on them, open the checkout the same day.
Frequently Asked Questions
What is card skimming in simple terms?
Card skimming is copying payment card details at the moment they are used, without stopping the payment or alerting the cardholder. The purchase goes through normally and the copy is sold or used elsewhere, often weeks later. It happens either at a physical terminal, through a hidden reader, or online, through code running on a checkout page.
How is digital card skimming different from an ATM skimmer?
An ATM skimmer is hardware. Someone has to fit it, return to collect the data or its transmitter, and risk it being spotted or removed. Digital skimming is JavaScript on a live payment page, installed remotely, invisible to the shopper, capable of sending data continuously. It also scales: one compromised supplier script can reach every merchant that loads it.
Can you tell if a website checkout has a skimmer on it?
Not reliably as a shopper, because a working skimmer changes nothing you can see. As a merchant you can inspect the payment page in a browser for unfamiliar script origins, encoded blocks inside your own files, and outbound requests firing when card fields lose focus. Remember that many skimmers stay dormant when they detect developer tools, so test from a clean device and session as well.
Who pays for the fraud when card details are skimmed in the UK?
Cardholders are generally refunded by their payment service provider under the Payment Services Regulations 2017, subject to exceptions for fraud or gross negligence. The merchant carries the commercial cost through card-not-present chargebacks, scheme fees, forensic investigation and remediation. Serious security failings can also attract regulatory action, as with the ICO’s £20m fine against British Airways in October 2020.
Does using a payment provider’s hosted fields stop card skimming completely?
No. Hosted fields move the card inputs into the provider’s iframe, out of reach of scripts on your page, which removes the largest part of the risk. Name, billing address, email and phone are still entered on your page. A skimmer can also hide the iframe and overlay a fake card form, so page integrity monitoring is still needed.