A credit card skimming attack copies your card details at the exact moment you pay, without stopping the payment and without you noticing. The transaction goes through. The receipt prints. The order confirmation arrives. Weeks later the card is used somewhere you have never been.
That quietness is the whole point. Skimming is not a smash and grab. It is a copy made in passing, and the best skimmers are the ones nobody finds for months.
The word covers two quite different crimes that share a goal. One happens at a physical card reader. The other happens inside the code of an online checkout page, and it is the one this site is named after.
Physical skimming: the reader that reads twice
The original skimmer was a piece of hardware. A criminal fits a false front over a cash machine’s card slot, or slides a paper-thin board called a shimmer inside the slot itself, so the card passes through the fake reader on its way to the real one. The fake copies the data on the magnetic stripe or, with a shimmer, intercepts the conversation between the chip and the terminal. A pinhole camera or a false keypad overlay captures the PIN.
Petrol pumps are a favourite target because they sit outdoors, unattended, and often share a universal key. Restaurants have seen handheld skimmers used by staff who swipe a card twice. Chip and PIN made a copied stripe far less useful in the UK, but shimmers were built specifically to get round that, and the stolen data is still cloned, sold in bulk, or used online where a stripe copy is enough.
Digital skimming: the checkout page that leaks
The modern version needs no hardware at all. A digital skimmer is a small piece of malicious JavaScript planted on a website’s payment page. When a shopper types a card number, expiry date, security code and billing address into the form, the script reads those fields as they are entered and sends a copy to a server the criminals control. Then it lets the real payment proceed.
This is the attack known as Magecart, named after the Magento shopping platform where it was first seen at scale, and now used as a label for the whole family of groups and techniques. It is sometimes called formjacking or web skimming. Whatever the name, the mechanism is the same: the page the customer sees is genuine, the padlock in the address bar is genuine, and the merchant’s own systems never see anything unusual, because the theft happens in the customer’s browser before the data is encrypted and submitted.
That last detail matters. Many businesses assume that because their payment processor tokenises card data, or because the form posts over HTTPS, the card number is safe. Neither protects against a script that reads the keystrokes before any of that happens.
How the script gets there
Attackers have several ways in, and most of them are ordinary.
- A vulnerable platform or plugin. An unpatched install, an abandoned extension or a flawed theme lets an attacker write to the site’s files. The skimmer is added to an existing JavaScript file so it looks like part of the furniture.
- Stolen or weak admin credentials. A reused password, or a control panel without multi-factor authentication, lets someone edit the page like any administrator would.
- A third-party script. Checkout pages load code from analytics tools, chat widgets, tag managers and advertising pixels. Compromise one provider and every site loading its script serves the skimmer too. That is a supply chain attack, and it can hit thousands of shops through a single supplier.
- Misconfigured cloud storage. Publicly writable buckets hosting a site’s static files have been found and edited in bulk by automated scanners.
Two cases that changed the rules
In 2018 British Airways disclosed that the payment details of hundreds of thousands of customers had been captured over about two weeks by a script injected into its website and app. The Information Commissioner’s Office fined the airline £20 million in 2020, then its largest penalty, and made plain that the failure was one of basic hygiene rather than exotic attack.
The same year Ticketmaster UK was skimmed through a third-party chat widget that had been placed on payment pages where it had no need to be. When the supplier was compromised, the skimmer came with it. A page is only as trustworthy as every script it loads.
Why skimming is so hard to spot
A well-built skimmer is designed to survive scrutiny.
It only activates on pages with payment forms, so a scan of the homepage finds nothing. It sends stolen data to a lookalike of a real analytics or payment domain, so network traffic raises no alarm. It is obfuscated so the code never contains words like “card” or “cvv”, and some variants switch themselves off when developer tools are open. Because the payment still succeeds, there is no failed transaction, no complaint and no error to investigate.
The first sign is usually external: a card scheme notices that a cluster of fraudulent transactions share one merchant in their recent history and works backwards. By then the skimmer may have been live for months.
Warning signs for a business
None of these prove an attack on their own, but each deserves a look.
- A JavaScript file on the payment page that nobody on the team can account for, or a known file whose size or hash has changed without a deployment.
- Outbound requests from the checkout page to a domain that is not on your list of suppliers.
- Content Security Policy violation reports pointing at an unfamiliar host.
- A rise in chargebacks, or a notification from your acquirer about a “common point of purchase” investigation.
- Admin logins from unexpected locations or at unexpected hours.
- Customers reporting fraud on cards they used with you and nowhere else recently.
What a business should do about it
The Payment Card Industry Data Security Standard caught up with this attack in version 4.0. Two requirements, mandatory since 31 March 2025 for any merchant handling card data, address it directly: every script on a payment page must be inventoried, authorised and checked for integrity, and the page itself must be monitored for unauthorised changes. Those two requirements are a good summary of the defence even for businesses outside the standard’s reach.
Know every script on the payment page. Keep a written list of what loads there and why. Anything without a reason comes off. Chat widgets, marketing pixels and tag managers rarely need to be on the page where the card number is typed.
Pin what you load. Subresource Integrity lets a page declare the exact hash of a third-party script; if the file changes, the browser refuses to run it. A Content Security Policy tells the browser which domains a page may talk to, so a skimmer that tries to send data to a rogue host is blocked and the attempt is reported to you.
Take the card form out of your page. Hosted payment fields, where the card inputs live in an iframe served by the payment provider, mean the sensitive fields are never inside your document at all. A skimmer running on your page cannot read them. This is the single biggest reduction in exposure most small merchants can make, and it usually costs nothing.
Close the ordinary doors. Patch the platform and every extension promptly, remove plugins you no longer use rather than leaving them disabled, put multi-factor authentication on the admin panel and hosting control panel, and give each administrator their own login.
Watch for change. File integrity monitoring on the web root, plus an automated check that fetches the live payment page and compares its scripts against the approved list, catches most injections within hours rather than months.
Have a plan for the day it happens. Know who you would call at your acquirer, how you would take the payment page offline, and how you would tell customers. Under UK GDPR a breach involving card data will almost always need reporting to the ICO within 72 hours.
What a shopper can do
You cannot inspect a website’s code before you buy, but you can reduce how much a skimmer is worth.
- At a cash machine or pump, look for anything that sits proud of the fascia, has mismatched colours, or moves when pulled. Cover the keypad while entering your PIN regardless.
- Prefer contactless, mobile wallets or chip over swiping. A tokenised wallet payment gives a skimmer nothing reusable.
- Use a virtual or single-use card number online where your bank offers one.
- Turn on transaction alerts and read them. Skimmed cards are usually tested with a small purchase first.
- Do not treat the padlock as proof of safety. HTTPS means the connection is encrypted, not that the page is honest.
- Report suspected fraud to your bank straight away. You are protected against unauthorised transactions in the UK, but the sooner the card is stopped, the less there is to unpick.
The short version
A skimming attack copies card details at the point of payment and lets the payment complete, so it leaves no obvious trace. The physical kind hides in the card slot. The digital kind hides in the JavaScript of a checkout page, often arriving through a third-party script or an unpatched plugin, and it reads the card number before any encryption or tokenisation can protect it.
The defence is not clever. It is knowing exactly what runs on your payment page, refusing anything you cannot vouch for, and checking, regularly, that nothing has changed.