Checkout page compromised: what to do first depends on evidence, not panic. A compromised checkout page usually works perfectly. Cards are authorised, orders drop into the admin, the till rings. The damage is a copy made in passing. So if you have been told your payment page may be skimming card data and you are working out what to do, the first thing to understand is that nothing on the site will look obviously wrong, and the clock that matters is not the technical one. It is the evidence clock and the notification clock.
This piece covers the first 24 hours, in order. It separates containment (stop the bleeding) from eradication (remove the implant and close the route), because mixing the two is how merchants destroy the evidence their acquirer will ask for. It stops where removal work properly begins.
Confirm it is real before you touch anything
Three signals arrive first, in roughly this order of frequency.
- Clustered fraud reports from issuers, often on cards that share your BIN ranges and nothing else except a purchase from you.
- A common point of purchase (CPP) letter from your acquirer or a scheme, naming your merchant ID as the one place a set of defrauded cards all appeared.
- A customer saying something odd: a second card form, a page that asked again for the CVV, a payment step that looked slightly different from last time.
Any of the three is enough to start. None of them is proof. A CPP cluster can be a coincidence of volume, and a customer can misremember a 3-D Secure step. So verify before you act, and verify in a way that leaves a record.
Open your checkout in a clean browser profile with no extensions. Record the whole flow with the developer tools network panel open and preserve logging switched on, including the card entry step with test data. Export the HAR file. Save the rendered page source and the source of every script the page loads. Do this before you change a single file. Once you start cleaning, the live evidence of what the page was doing is gone, and you cannot recreate it.
Then ask the question most people skip: was card data even reachable from your page? If you use a provider iframe or hosted payment fields, the card number is typed into the provider’s document, not yours, and a script in your page cannot read it. That narrows things considerably, but it does not clear you. Attackers overlay convincing fake forms on top of the real iframe, take the card details themselves, then pass the customer through to the genuine fields or a plausible error. Check whether the provider’s fields were actually rendering during the incident window, and whether the DOM contained inputs that your platform never created. Our walkthrough on how to tell if your checkout has been skimmed sets out the specific checks, without special tools.
Rule out the dull explanations too. A new marketing tag, a consent platform update, a supplier swapping CDN hosts: all three produce an unfamiliar domain in the network trace and all three are legitimate. Ask the person who added it before you declare an incident.
Contain the bleeding in the first hour without destroying evidence
Containment is about stopping collection today. Eradication comes later. Ranked by customer impact, lowest first:
- Block the exfiltration destination. If the trace shows card data posting to a domain you do not control, block it at the edge or firewall and add it to a Content Security Policy connect-src denial. Orders keep flowing. Collection stops, assuming there is only one destination.
- Move the payment step to your provider’s hosted redirect page. Card entry leaves your document entirely. You lose some conversion and some styling. You keep trading.
- Take checkout offline. The honest option when you cannot tell where the implant sits or how many destinations it has. Expensive, and sometimes correct.
What you must not do first is restore a backup. This is the most common and most costly mistake in the whole sequence. A restore overwrites the file timestamps, the injected code and the modified database rows that an investigator needs in order to date the compromise and establish what was taken. It also tends to reinstate the condition that let the skimmer in: the same unpatched extension, the same end-of-life platform version, the same rogue admin account created three weeks before anyone noticed. Stores that restore and reopen are frequently reinfected within days, and the second infection is harder to date because the first one’s evidence is gone.
Snapshot before you clean. The pack you want, at minimum: a full archive of the web root, a database dump, web server access and error logs covering as far back as you retain them, admin login history, the list of cron jobs and scheduled tasks, and the HAR file from your verification pass. Copy it off the server. Hash it. Note the time you took it.
Then rotate credentials, because the attacker almost certainly still has some. Admin passwords, SSH keys, API keys, deploy tokens, gateway and payment provider keys, and any integration secrets held by agencies or suppliers. Kill active admin sessions rather than trusting the password change to do it. Enforce multi-factor authentication on admin access at the same time, if it is not already there.
Find how it got in: three routes, in order of likelihood
Clean the page without closing the route and the skimmer returns, usually within a week. The route also dictates who else you have to call.
A compromised third-party supplier script. Nothing on your server is touched. The code arrives from a domain you legitimately allow. Ticketmaster UK in 2018 was the textbook case: the malicious code came through a chat widget supplied by Inbenta and loaded on payment pages. The ICO issued a £1.25 million penalty in November 2020 over the failures that allowed it. If this is your route, the fix is a supplier conversation and a script inventory, not a server rebuild.
Injected first-party code. The skimmer lives in your own JavaScript, template files, theme or CMS content blocks, and is served from your domain. The British Airways compromise in 2018 worked this way, with modified code inside the payment flow itself; the ICO fined the airline £20 million in October 2020. Here the server or the deployment pipeline is in scope.
An unpatched platform or extension. Magento 1 reached end of life in June 2020. In September 2020 the security company Sansec reported roughly 2,000 Magento 1 stores compromised over a single weekend, a mass event against software nobody was patching. If your platform or a plugin is unsupported, assume mass exploitation rather than a targeted attack.
Where to look, practically: files modified in the last 90 days sorted by time, with your deployment history to hand; template and layout files; database rows holding CMS blocks, static blocks and header or footer scripts; scheduled tasks; admin user accounts and their creation dates; and extension directories, including ones for extensions you disabled but never removed. Our breakdown of eight high-profile incidents and the three routes in is useful for pattern-matching your findings.
One caution. Magecart is a label for a method, used by many unconnected crews, so the indicators published in one write-up rarely match your case line for line. Treat a known exfiltration domain as a hypothesis worth grepping for, not a signature that returning nothing clears you.
Who you must tell, and by when
Call your acquirer or payment service provider the same day. Not next week, and not after the clean-up. The acquirer and the card schemes decide whether a PCI Forensic Investigator is appointed, and they will tell you what evidence to preserve and what you must stop doing. Merchants who clean everything first and report afterwards routinely find they cannot answer the questions the investigation asks, which makes the outcome worse, not better.
Where personal data is affected, UK GDPR gives you 72 hours from becoming aware to notify the Information Commissioner’s Office, and payment card details attached to a named person are personal data. Note that “becoming aware”starts at reasonable suspicion backed by some verification, not at the moment the investigation concludes. If you are unsure of the scope at hour 60, notify with what you have and update later. That is expressly allowed.
Card schemes run their own account data compromise processes, with their own deadlines and their own evidence expectations, and they reach you through your acquirer. Preserve logs for as long as they ask, which is often longer than your default retention. Set retention to hold before a rotation deletes the week you need.
For customers: be specific about what you know and silent about what you do not. Say which pages were affected, the dates of the exposure window, what data could have been captured, and what you have done. Do not publish a victim count you cannot defend. Tell people to contact their bank and ask for a replacement card, and to check statements rather than wait for an alert. Honest and narrow beats reassuring and wrong, because the second version gets corrected in public.
Work out the exposure window and what was actually taken
The window is the single most useful number you will produce. Build it from file modification times, deployment logs, version control diffs and, where the implant sat in the database, row update timestamps. Cross-check every date, because attackers reset timestamps to blend into a release. A file that claims to predate its own content is a tell.
Then read the skimmer. Obfuscated code is still readable with patience, and the two things you need are plain: which fields it harvested, and where it posted them. A script that lifts the PAN, expiry, CVV and cardholder name is a different notification from one that only scraped the billing address.
Worked example. Timestamps and your deploy log put the injected block on 2 March. You blocked the exfiltration domain on 19 March. Every completed order between those dates is a potentially affected cardholder, and your order report gives you the number. If the implant only ran for logged-in guests, or only on one payment method, the number falls accordingly, and you should say so.
Blocking the destination does not always end collection. Some skimmers pull their payload or push their loot through a blockchain contract or a service that cannot be taken down by a registrar, and some post to endpoints dressed as ordinary analytics so a domain block looks like breaking your own reporting. The blockchain-hosted variants and why takedowns fail are worth reading if your trace points somewhere unusual. In those cases, removing the loader from your page is the only control that works.
Stop the second compromise before checkout reopens
Do not reopen on a promise. Put controls in first, in this order.
Content Security Policy, report-only to begin with. Deploy it with the report-only header, collect violations for several days, and read them. A live payment page switched straight to enforce will block a legitimate tag you forgot about, and the lost orders can exceed the skimmer’s damage. The working CSP setup for a checkout page covers the directives that matter and the ones that do nothing.
Subresource Integrity on third-party scripts. SRI pins the exact file, so a supplier who gets compromised cannot serve you different code. It also means a routine supplier update breaks the hash and silently stops their script loading. Agree a change-notification process with the supplier before you pin, or accept that you will be fixing broken checkouts on a Friday afternoon.
Hosted payment fields. Taking the card inputs out of your DOM removes the largest part of the risk cheaply. It does not stop an overlay form, it does not protect order and address data, and it does not help if the attacker can rewrite the page that renders the iframe. Useful, not complete.
The two PCI requirements an assessor will now ask about. PCI DSS v4.0 requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. In plain terms: an inventory of every script on the payment page with a written reason each one is there, plus detection of unauthorised change to the payment page as received by the browser. An incident is precisely when both get requested. You do not need to buy a platform for 11.6.1; a scheduled job that fetches the checkout, hashes the script list and HTTP headers, and emails you on change satisfies it. Our guide to what 6.4.3 and 11.6.1 ask of your payment page sets out the cheap version. Published standards and supporting guidance are on the PCI Security Standards Council site.
The 24-hour checklist
Hours 0 to 1: evidence and containment
Verify in a clean browser and export the HAR. Save page source and all loaded scripts. Archive the web root, dump the database, pull access and admin login logs, list cron jobs. Then block the exfiltration destination, or switch payment to the provider’s hosted page, or close checkout.
Hours 1 to 4: entry route and credentials
Recently modified files, template and layout files, CMS blocks, scheduled tasks, admin accounts, extension directories. Decide which of the three routes you are dealing with. Rotate every credential and key, kill admin sessions, enforce MFA.
Hours 4 to 12: notifications and exposure window
Acquirer or PSP call, same day, before cleaning. Prepare the ICO notification inside the 72-hour window. Date the implant, read the harvested fields, count completed orders in the window.
Hours 12 to 24: controls and the reopen decision
CSP in report-only, SRI where you have a supplier agreement, script inventory written down, change detection scheduled. Reopen only when the route is closed, the credentials are new and you can see changes to the payment page within minutes rather than months.
The short version
If your checkout page is compromised, what to do in the first hour is capture evidence and stop collection, in that order, and what not to do is restore a backup. Call the acquirer the same day, because that call decides whether a forensic investigator is appointed. Notify the ICO within 72 hours where personal data is involved. Date the implant, use the order count in that window as your working number of affected cardholders, and fix the route in, not just the page. Once containment holds and the notifications are away, the next stage is the methodical clean-up, which is covered in the 72-hour skimmer removal guide.
Frequently Asked Questions
How do I know my checkout page is compromised and not just slow or buggy?
Skimmers do not break payments, so performance problems and a compromise look nothing alike. The signals are an unfamiliar domain receiving data in the network trace, an input field your platform never created, or clustered fraud reports naming your store as the common point of purchase. Record the checkout flow in a clean browser profile and compare the loaded scripts against your own inventory.
Should I take my checkout offline if the payment page is compromised?
Only if lighter containment will not hold. Blocking the exfiltration destination or moving card entry to your provider’s hosted page stops collection while you keep trading. Close checkout when you cannot establish where the implant sits, when there are multiple destinations, or when your acquirer tells you to.
Do I have to report a compromised checkout page to the ICO and my acquirer?
Where personal data is affected, UK GDPR requires notification to the ICO within 72 hours of becoming aware, and card details tied to a named customer count. Your acquirer or payment service provider should be told the same day, since they and the card schemes decide whether a PCI Forensic Investigator is appointed and what evidence you must preserve.
Can I just restore a backup to remove a checkout skimmer?
No, and doing it first is the mistake that causes the most damage. A restore destroys the file timestamps and injected code needed to date the compromise, and it commonly reinstates the unpatched version or rogue admin account that allowed the injection. Snapshot everything, identify the route in, then clean.
How do I work out how many customers had their card details stolen?
Date the implant from file modification times, deployment logs and version control diffs, cross-checking because attackers alter timestamps. Treat every completed order between that date and the moment you contained it as a potentially affected cardholder, and take the figure from your order report. Narrow it only where the skimmer’s own code shows it ran on specific payment methods or fields.