A fake payment form skimmer does not listen to your checkout. It replaces it.
That distinction matters more than it sounds. Most card skimming code sits alongside a real payment form and copies what is typed into it, keystroke by keystroke, or grabs the field values at the moment of submit. A fake form skimmer does something different. It removes or hides the payment element your provider renders, drops a visually identical set of inputs into your own page, and collects the card itself. The attacker owns the form. Labels, validation rules, error messages, the lot.
Which is why this attack class defeats the control most merchants believe has already solved the problem for them.
What a fake payment form skimmer is, and why it is not a normal skimmer
A conventional skimmer is a passenger. It needs a real form to read from, and it is limited to whatever that form asks for. If your provider’s integration never requests the cardholder name, a listening skimmer never gets the cardholder name.
Replacement removes that limit. Whoever writes the fake form decides what the shopper is asked for, so CVV, cardholder name, billing address and expiry can all be requested in one pass, even where the genuine integration would never ask. The error text is theirs too, and that is the part that makes the trick work.
The flow is usually the same. The shopper reaches the payment step and types the card into the fake fields. The data goes out to the attacker. The page then shows a soft failure, something along the lines of a declined transaction or a session timeout, or it simply reloads. Second time round, the genuine payment element is there. The shopper pays. The order completes, the confirmation email arrives, the goods ship.
Nothing looks wrong because nothing is wrong, from the shopper’s side. Same domain in the address bar, same padlock, same fonts and spacing as the rest of your site, and a successful purchase at the end of it. There is no phishing domain to spot and no certificate warning. The payment succeeds. So does the theft.
Akamai documented a version of this in November 2020: a skimmer that rendered its own credit card form and sent the captured data out over WebSockets. Sansec reported a related pattern in December 2020, a fake payment page presented ahead of genuine checkout, seen across stores running Shopify, BigCommerce, Zen Cart and WooCommerce. Four platforms, one technique. Platform choice is not a defence here.
Why hosted payment fields and payment iframes do not stop this on their own
An embedded payment element, whether that is a full iframe or a set of hosted fields, protects one specific thing very well. The card input lives on the provider’s origin. Your JavaScript cannot read it, cannot attach listeners to it, and cannot see the value. That guarantee holds. Hosted payment fields remain the cheapest way to cut skimming risk, and they keep your PCI scope small when the page around them is intact. For the routes attackers use when that page is compromised, see the UK merchant’s playbook on digital card skimming.
The words doing the work in that sentence are “when the page around them is intact”.
The parent page still decides whether the provider’s element is rendered at all. Script on your checkout can remove the frame, hide it with a single style change, or never call the provider’s initialisation function in the first place. Injected code then writes plain inputs into your own document, styled to match. Card data typed into those inputs is first-party data on a first-party page, and the provider’s protection is simply not in the picture.
Almost nobody monitors whether the element actually loaded. That is the gap. Merchants check that payments are going through, and payments are going through, because the fake form hands the shopper back to the real one on the second attempt. The swap runs quietly until an issuer or acquirer starts reporting fraud clustered on your store.
A full redirect to the provider’s own hosted page closes this off more firmly, because the card is typed on an origin you do not control and cannot inject into. The trade-off is real: an off-site step costs conversion, and marketing teams resist it. If you keep the card entry on your own page, accept that you have taken on responsibility for proving the page is unmodified.
How the fake form gets onto a checkout page
The routes in are the familiar ones, and they have not changed much in seven years.
- Compromised supplier code loaded directly into checkout. Ticketmaster UK in 2018 is the reference case: malicious code reached the payment page through a third-party chatbot script. A chat widget has no business on the page where card numbers are typed.
- Injected first-party JavaScript. British Airways is the other shape of the same problem, where the code sat inside the merchant’s own JavaScript after the attacker gained access to it. Nothing third-party to blame and nothing external to block.
- Unpatched or end-of-life platforms. In September 2020, Sansec reported roughly 2,000 Magento 1 stores skimmed over a single weekend. Software past its support date is an open door with a sign on it.
- Admin and extension entry points. Stolen admin credentials, a malicious or abandoned plugin, or a CMS block that permits raw script tags. Template editors that accept arbitrary HTML are a standing invitation.
The injection is usually conditional, and this is the detail that wastes the most investigation time. Code is written to appear only on checkout URLs, only for shoppers, and to suppress itself for logged-in administrator sessions or for IP addresses it has seen before. A quick look from the developer’s own browser proves nothing at all. The routes into the best-known incidents repeat with enough regularity to plan against.
Signs of a payment page skimmer on your own checkout
None of these checks is proof on its own. Together they get you to an answer in an afternoon, without special tools.
Start with the DOM. Open the payment step and inspect the card fields. You are looking for inputs inside a cross-origin frame belonging to your provider. Plain inputs sitting in your own document, where the integration documentation says there should be a frame, is the whole finding. Check also whether the provider’s frame exists but has been pushed out of view or given zero height.
Then watch the network panel through a test submit. Look for POST requests to hosts you do not recognise, image or beacon requests carrying long base64-looking query strings, and any WebSocket connection opened from the payment page. Card data leaving over a WebSocket is exactly what Akamai described in 2020, and it will not appear as a normal form submission in your logs.
Compare the fields on screen against what your provider’s integration genuinely renders. An extra CVV box, a cardholder name field that should not be there, or a billing address block that the provider never asks for are all worth chasing. Then confirm the payment still triggers the 3-D Secure step it should. A flow that used to redirect for authentication and now does not has changed for a reason.
Take double-entry reports seriously. Shoppers or your support team describing a first attempt that failed and a second, identical attempt that worked is the signature of this attack more than any other single signal. The same goes for outside signals: fraud reports from your acquirer clustering on your store, an unusual chargeback pattern, or small-value card-testing spikes.
Audit from a clean browser profile, signed out, as an ordinary shopper. Do it on mobile as well as desktop, because targeting by user agent is common. If you want the full sequence, the site has a longer walkthrough of how to tell whether a checkout has been skimmed.
Controls that break a fake payment form
Content Security Policy past script-src
Most merchant policies restrict script sources and stop there. Against this attack, that leaves the exfiltration path wide open. WebSocket traffic is governed by connect-src. A raw form POST to an attacker endpoint is governed by form-action. Both directives are routinely absent.
Form-action deserves particular attention because it does not fall back to default-src. Omit it and the browser will happily post your customer’s card details anywhere the injected markup points.
The directive that matters most here is frame-src, because it pins which origins may render a payment frame. A worked starting point for a checkout page, deployed in report-only mode first:
- Default-src ‘self’
- Script-src ‘self’ https://js.provider.example
- Frame-src https://js.provider.example https://3ds.provider.example
- Connect-src ‘self’ https://api.provider.example wss://api.provider.example
- Form-action ‘self’ https://checkout.provider.example
- Report-uri /csp-report
Replace the placeholders with the exact origins in your provider’s integration documentation, including any separate host used for 3-D Secure. Ship it as a Content-Security-Policy-Report-Only header on the live checkout, collect violations for a week or two until you understand the noise, then promote it to enforcement. Report-only on a live payment page breaks nothing, which is why there is no excuse for not having it. The working checkout CSP setup covers the header plumbing in more detail, and Mozilla documents the directive behaviour clearly in the MDN Content-Security-Policy reference.
One limit, stated plainly: frame-src controls which origins may be framed. It does nothing about an attacker deleting your provider’s frame entirely and using first-party inputs instead. Pinning needs pairing with something that notices the frame is gone.
What Subresource Integrity cannot cover here
Subresource Integrity is widely misread as the fix for this. It is not. Hash pinning covers scripts you reference on purpose, and only those. A newly injected inline script is not covered. A modified first-party bundle is not covered, because you will rebuild the hash from the modified file. And SRI will break your checkout the moment a supplier updates their file without telling you, which is the failure mode nobody plans for.
Use it where it fits, on static third-party files you deliberately load, and read the honest account of what SRI does and does not pin before relying on it for compliance evidence.
Remove the ability to inject, then backstop it server-side
Keep a minimal script inventory on the payment page. No tag manager container on checkout, ever; a container is a mechanism for injecting arbitrary JavaScript, which is the thing you are trying to prevent. Review extensions properly, cut dormant admin accounts, and require multi-factor authentication on admin and deployment access. Where a tag manager container already sits elsewhere on the site, auditing every tag inside it is the next task, a process covered in detail separately.
Server-side, verify that the payment token you receive was issued by your provider rather than trusting whatever the browser posted. Alert on orders where the expected payment element never reported loading. A failed-then-succeeded pattern on the same card within a few minutes is worth a report someone reads.
Turning PCI DSS 4.0 requirements 6.4.3 and 11.6.1 into a working routine
Requirement 6.4.3 asks that every script loaded and executed in the consumer browser on a payment page is authorised, has its integrity assured, and appears in a written inventory with a justification for being there. Read plainly, that is a list of what belongs on your checkout. An injected fake form is obvious against a list.
Requirement 11.6.1 asks for detection of unauthorised change to payment page HTTP headers and content as received by the browser, with personnel alerted at least weekly, or at a frequency set by a documented targeted risk analysis. Both requirements have been mandatory since 31 March 2025, and 11.6.1 reads as though it were written for this exact attack. Current text sits in the standard itself, available from the PCI Security Standards Council document library; the site also has a plainer breakdown of what 6.4.3 and 11.6.1 ask of a payment page.
The cheap setup satisfies both. A CSP reporting endpoint that writes violations somewhere durable, plus a scheduled headless fetch of the checkout that records the script list, the frame origins and the response headers, then diffs them against the last known-good snapshot. Alerts go to a mailbox a human actually opens. That diff is the compliance evidence and the detection control at once, and it costs a small server job rather than a licence.
If you find one
- Preserve evidence before cleaning. Copy the injected code, server logs and access logs first. Deleting the script destroys the only record of how it arrived.
- Rotate admin, API and deployment credentials, and review every active session.
- Notify your acquirer, and assess your position under UK GDPR for reporting to the Information Commissioner’s Office and informing affected customers.
- Find the entry route. Removing the code without closing the door means the same skimmer returns within days.
The short version
A fake payment form skimmer replaces your payment element rather than reading it, which is why hosted fields and a payment iframe do not stop it by themselves. Extend your checkout CSP to frame-src, connect-src and form-action, not script-src alone. Do not lean on Subresource Integrity for this. Snapshot the script list, frame origins and headers on a schedule, diff them weekly, and send the alert to someone who will read it. The technique is quiet and the payment still succeeds, so the only reliable signal is the one you build yourself.
Frequently Asked Questions
What is a fake payment form skimmer?
It is card-stealing code that removes or hides the genuine payment element on a checkout page and replaces it with a lookalike form the attacker controls. Because the attacker writes the fields and the error text, it can request details the real integration never asks for, such as CVV and cardholder name. After capturing the card it usually shows a soft error and hands the shopper to the real payment form, so the order completes normally.
Can a skimmer beat hosted payment fields or a payment iframe?
Yes, by not attacking them at all. Hosted fields keep card input on the provider’s origin and out of reach of your JavaScript, and that protection holds. What it does not cover is the parent page, which still decides whether the provider’s element is rendered. Code on your checkout can delete the frame and substitute its own inputs, and very few merchants monitor whether the element loaded.
How can I tell if my checkout is showing a fake card form?
Inspect the payment step and confirm the card inputs sit inside a cross-origin frame belonging to your provider rather than being plain inputs in your own document. Watch the network panel during a test submit for unexpected POSTs, beacon requests with long encoded strings, and WebSocket connections. Treat reports of a declined first attempt followed by a successful second attempt as a strong signal, and always audit from a clean, signed-out browser profile on mobile as well as desktop.
Does Content Security Policy stop a fake payment form?
A policy that covers frame-src, connect-src and form-action removes most of the useful exfiltration routes and pins which origins may render a payment frame. A script-src-only policy does not, which is the common mistake. CSP will not prevent an attacker deleting your provider’s frame, so pair it with change detection that notices the frame has gone.
What do PCI DSS 4.0 requirements 6.4.3 and 11.6.1 require on my payment page?
6.4.3 requires an inventory of every script running in the shopper’s browser on the payment page, with authorisation, written justification and integrity assurance for each. 11.6.1 requires detection of unauthorised change to the payment page content and HTTP headers, with alerts at least weekly or at a frequency justified by a targeted risk analysis. Both became mandatory on 31 March 2025, and a scheduled diff of script list, frame origins and headers satisfies the practical part of each.