Magecart.co.uk is an independent site about one specific crime: the theft of payment card details at the moment a customer pays. It covers the attacks that get called Magecart, the older physical skimming they grew out of, and the people, techniques and failures behind the cases that make the news.
It is written for the people who have to defend a checkout. That means the owner of a small online shop as much as the security team at a large retailer, and it means the agency, the developer and the payment provider in between. If your business takes card payments on a website, this site is about a risk you already carry.
What Magecart is, in one paragraph
Magecart is a label, not a gang. It describes a way of stealing card details by placing a small piece of malicious JavaScript on a website’s payment page. As a shopper types their card number, expiry date and security code, the script copies the fields and sends them to a server the attackers control, then lets the real payment go through. The name comes from Magento, the shopping platform where the technique was first seen at scale, but the attacks now hit every platform. Dozens of separate crews use the method, and they use it in very different ways.
The two explainers on this site go further: What is Magecart? and Card skimming explained.
Why it deserves a site of its own
It is quiet. A skimmer does not stop the payment, so there is no failed transaction, no error and no complaint. The merchant’s own systems see nothing unusual, because the theft happens in the customer’s browser before the data is encrypted or tokenised. Most victims learn about it from a bank or a card scheme, months later.
It is structural. A modern checkout page loads code from a dozen suppliers: analytics, chat, tag managers, reviews, consent banners, advertising pixels. Compromise one supplier and every site that loads its script serves the skimmer. Ticketmaster UK was skimmed through a chat widget it had placed on its own payment page. A merchant can patch everything it owns and still be exposed through something it chose to load.
It is now regulated. Version 4.0 of the Payment Card Industry Data Security Standard added two requirements, mandatory since 31 March 2025, that address this attack directly: every script on a payment page must be inventoried, authorised and checked for integrity, and the page must be monitored for unauthorised change. Most small merchants do not yet know that applies to them.
What this site will do
News. When an incident is disclosed, a plain account of what happened: how the code got in, how long it ran, what was taken and what the regulator said. No press-release gloss, and no speculation dressed up as fact.
Explainers. How the attacks actually work, from a false front on a cash machine to a script that switches itself off when developer tools are open. Written so that a non-technical business owner can follow them, with diagrams you can put in front of a board.
A record. The named cases, in date order, with the route in and the lesson from each. Laid side by side, the incidents sort into patterns that headlines hide. The first eight are here.
Defence. Practical guides for merchants who do not have a security team: how to inventory the scripts on a payment page, what Content Security Policy and Subresource Integrity actually do, why hosted payment fields remove most of the exposure at no cost, and what to do on the day it happens.
The site will practise what it describes. There are no trackers, no third-party fonts and no advertising scripts. Comments are closed, because a comment form is a payment form’s cousin: another way in that nobody is watching.
About me
I am Andrew Mason. I have worked in security for more than twenty-five years, most of it on the side that breaks things in order to fix them: network security and penetration testing first, then data protection. I co-founded RandomStorm, which was sold to Accumuli plc in 2014, and went on to found Pentest People, Data Protection People and DarkInvader, which watches the dark web and an organisation’s external attack surface for early signs of a breach. I am based in Yorkshire.
The credential most relevant to this site is that I am a PCI DSS Qualified Security Assessor. I have assessed merchants against the standard, and I know how often the payment page is the part nobody has looked at. I also hold CISSP and CCIE, I am a CHECK Team Leader, and I have an MBA from Leeds University Business School.
I started writing online in 2007 with a blog about getting things done, and I still keep a personal site. This one exists because card skimming is the attack I see most often misunderstood by the people it affects most. It is not exotic, it is not rare, and it is almost always preventable with ordinary hygiene.