The hardest thing about a skimmer is that a working one gives you no reason to look. The payment succeeds, the order arrives, nobody complains. So the question “has my checkout been skimmed?” almost never gets asked until a bank asks it for you. This is a guide to asking it yourself, in an afternoon, without special tools.
None of the checks below is proof on its own. Together they build a picture, and any one of them turning up something you cannot explain is worth taking seriously.
Look at what the page loads
Open your checkout in a browser, open the developer tools, and go to the network tab. Reload the page and watch what it fetches. You are looking for scripts loaded from domains you do not recognise. Make a list of every host the page talks to and check it against the suppliers you actually use. A skimmer’s giveaway is a request to a domain that looks almost right, a near-miss on a real analytics or payment name, or a host registered recently that you have never heard of.
Then fill in the card fields with test data and watch the network tab as you type and submit. The card details should go to your payment provider and nowhere else. If you see a request carrying the field values, or anything that looks like them, to any other destination, stop and treat it as a live incident.
Read the scripts themselves
In the sources or debugger panel you can see the actual code the page runs. You are not auditing all of it. You are scanning for the shape of a skimmer: code that reads form fields and sends them somewhere, and code that has been deliberately obscured. Long unbroken strings of gibberish, function names assembled from fragments joined together, base64 blocks that get decoded and run, references to card, cvv or the names of your input fields inside a script that has no reason to touch them. Legitimate code is occasionally ugly, but heavy obfuscation on a checkout deserves an explanation.
Compare the scripts to a baseline if you have one. A file on the payment page whose size or contents have changed since your last deployment, with no deployment to account for it, is the clearest single sign there is.
Check the ordinary doors
Look at your admin and hosting logins for access from places or at times that do not fit. Review the list of administrator accounts and confirm you recognise every one. Check for plugins or extensions you did not install, or ones you disabled that are active again. Look at file modification dates in the web root for changes you cannot tie to a release. A skimmer has to get onto the page somehow, and these are the usual routes.
Listen to the outside signals
The earliest warning usually comes from outside. A rise in chargebacks, or a note from your acquiring bank about a common point of purchase investigation, means a card scheme has traced a cluster of fraud back to you. Customers reporting fraud on cards they used with you and nowhere else recently is the same signal arriving a different way. These are not vague worries to file away; they are often the first hard evidence, and they warrant the checks above the same day.
If you find something
Do not quietly delete the offending script and move on. Take the payment page offline or switch payments to a hosted flow first, so no more cards are taken while you work. Preserve what you found, the file, the timestamps, the logs, because you will need them to understand how it got in and how long it ran. Contact your acquirer. Under UK data protection law a breach involving card data will almost always need reporting to the Information Commissioner’s Office within 72 hours, so start that clock in your head immediately. Then find the entry route and close it, because removing the skimmer without closing the door means it comes back.
The short version
You can check for a skimmer yourself: watch what the checkout loads and where it sends the card fields, read the scripts for obfuscation and unexplained change, review admin access and files for the way in, and treat chargebacks or a bank’s call as hard evidence rather than noise. If you find one, take payments offline, preserve the evidence, tell your acquirer, mind the 72-hour reporting clock, and close the route in before you reopen.