Card data theft at checkout: how the copying happens

Card data theft at checkout works like this: a piece of malicious code, hidden on a legitimate store's payment page, reads what the customer types (card number, expiry date, security code) and sends a copy to the criminal while the purchase goes through as usual. The store gets paid, the customer gets the order, and nobody notices anything until strange charges show up on a statement.

What happens on the customer's screen

Every payment page is assembled in the shopper's browser from many pieces of code: the store's own, the e-commerce platform's, plugins', and partners' such as analytics, chat or review tools. They all run together inside the same page. That is useful (it is what lets the page warn instantly that a card number is incomplete), but it also means that any code present there can see what is typed into the fields.

The attack exploits exactly that. The criminal gets their own code onto the page, by breaking into the store's admin panel, exploiting a flaw in the platform or a plugin, or compromising a partner that supplies a script. From then on, the script is almost always the same:

1. The customer fills in the card form, as with any purchase.
2. The malicious code reads the fields while they type or when they click pay.
3. A copy of the data is sent to an address the criminal controls, often named to look like a legitimate analytics service.
4. The purchase continues and is approved. For the store and the customer, nothing looks unusual.

The guidance published by the PCI Security Standards Council in March 2025 calls this a silent attack: everything works as expected from both the customer's and the merchant's point of view, so it can go undetected for a long time.

Real cases that show the pattern

The best-documented case is British Airways. According to the decision of the UK data protection authority (ICO), published in October 2020, an attacker got into the airline's network with compromised remote-access credentials and edited a code file on its website. For 15 days between August and September 2018, every customer who typed in card details unknowingly sent a copy to a domain that looked like the airline's, and the booking carried on without interruption. Around 430,000 people may have been affected, and it was a third party, not an internal alarm, that alerted the company. The ICO went on to fine the airline.

In 2019, Visa's payment fraud disruption team described a piece of code of this kind, which it named Pipka. It could be configured to choose which fields to copy (number, expiry, security code, name and address) and it deleted itself from the page right after running, to make investigation harder. Visa found it on at least 17 stores.

This is not an isolated problem. In December 2023, an operation coordinated by Europol with police from 17 countries notified 443 online stores that their customers' card data had been exposed, in just two months of work. In April 2026, the research firm Sansec reported nearly 100 stores carrying code hidden inside an invisible image element, which sent the data to addresses disguised as a social network's analytics.

Why traditional defenses don't see it

Firewalls, server antivirus and fraud screening matter, but they look elsewhere. Fraud screening checks whether a transaction looks legitimate, and it is: the customer is real, the card is theirs and so is the purchase. A firewall protects the way into the server. The copying, however, happens in the shopper's browser, after the page has already left the server.

Two things make it worse. Malicious code tends to imitate well-known tools, so it slips past a quick review. And reviewing the code stored on the store's server does not show what was added later by a partner, by a tag manager or directly on the live page. That is why discovery almost always comes from outside: a bank spotting a cluster of fraud, the card network, a researcher.

What to do in your store

• Know what runs at checkout. List every script loaded on your payment pages, who is responsible for each and why it needs to be there.
• Cut the excess. Marketing, chat and review tools rarely need to be on the page where the card is typed.
• Close the doors. Keep platform, theme and plugins up to date, remove what you don't use and require two-step verification on every admin and remote access.
• Restrict destinations. Configure the page to load code from, and send data to, authorized addresses only.
• Watch the page the customer receives, not just the code on your server: new or changed scripts and data sent to unknown destinations should trigger an immediate alert.
• Have a plan. Decide whom to call (acquirer, payment provider, technical team) if something suspicious appears, and how to inform customers.

These measures are also at the heart of PCI DSS requirements 6.4.3 and 11.6.1, which became mandatory on March 31, 2025.

Proteside was built for this moment: a script on the payment page that checks, in the shopper's browser, who is reading the card fields and where the data is going, and blocks the copy before it leaves. See how card data theft protection works and try it free for 14 days.