A Customer Told You Their Card Was Cloned

One report is not evidence

Card details are compromised constantly, from data breaches, physical terminals, and other sites, and any given person may have used dozens of places recently.

The customer is telling you because you are the transaction they remember, which is understandable and is not information about you.

So the correct response is to take it seriously, check properly, and not conclude anything from a single report.

What changes the picture is a second one, which is why recording the first matters even when you find nothing.

The one scenario that involves your site

Worth understanding, since it is specific and most businesses have never heard of it.

Code can be injected into a checkout page that copies what somebody types into the card fields and sends it elsewhere, while the payment itself proceeds normally.

The customer completes the purchase, receives the goods, and nothing appears wrong to anybody.

It is invisible on the page, invisible in the transaction records, and can run for months.

That is the scenario a report should prompt you to rule out, and ruling it out is an hour's work.

What to check

• Scripts loading on the checkout page.
• Whether card fields are hosted by the provider.
• Recently modified files.
• Unexpected administrator accounts.
• Anything unfamiliar in the site's code.
• Whether other reports exist that nobody logged.

The second is the most important and is a structural question rather than an investigation: if the card fields are served by your payment provider rather than by your own page, this scenario is largely closed off.

Look at what the checkout page loads

The practical check, and it needs no expertise.

Open the checkout page and use your browser's developer tools to list every script the page loads.

You are looking for anything you cannot account for: a script from a domain you do not recognise, or one that resembles a familiar name with a small difference.

Compare against another page on the site, since a script loading only on checkout is unusual and worth explaining.

Ask whoever maintains the site to account for each one, which is a reasonable request and one a competent developer can answer quickly.

Do this even if the answer is that everything is fine, since knowing what should be there is what makes a future check possible.

A worked example

A small shop received a report from a customer whose card had been used fraudulently a fortnight after ordering.

The owner checked the scripts on the checkout page, found four, and could account for three.

The fourth was from a domain resembling a well-known analytics service with one letter different.

It had been added about two months earlier through a compromised administrator account, and it was copying the card fields, which the shop was collecting on its own page rather than through the provider.

They moved to a hosted checkout, removed the script, changed everything, and contacted the customers who had ordered in that window.

The single report had been correct, which is the reason the hour is worth spending even though most reports are not.

Hosted fields close this off

The structural answer, and the reason it exists.

Where the card fields are provided by the payment provider, embedded in your page but served and controlled by them, the details never pass through your site.

Injected code on your page cannot read what is typed into them, which removes this scenario almost entirely.

It also reduces your obligations considerably, since you are no longer handling card data at any point.

Most providers offer this and many small shops are set up the older way because that was the default when the site was built.

If you are collecting card numbers in fields on your own page, that is worth changing regardless of whether anything has gone wrong.

What to say to the customer

Since the conversation matters as much as the investigation.

Thank them for telling you, which most people would not have bothered to do.

Say plainly that you are checking, and that you will tell them what you find either way.

Do not assert that it cannot have been you before you have looked, which is the instinctive response and is not a claim you can yet make.

Advise them to contact their bank if they have not, since that is the thing that actually protects them.

And come back to them afterwards, briefly, whatever the answer, since a customer who reports something and hears nothing assumes the worst.

Record it either way

The step that makes the second report useful.

Note the date, the customer, when they ordered, and what you checked and found.

One report is noise. Two reports from customers who ordered within the same period is a pattern, and you can only see it if the first was written down.

Without a record, the second report is treated as another isolated one, which is how these run for months.

Keep it somewhere anybody handling enquiries can add to, since the reports may come to different people.

Check the reports against your own dates

The analysis that turns two reports into something actionable.

Note when each customer ordered rather than when the fraud occurred, since the ordering date is what points at a window.

Two customers who ordered within the same few weeks is a much stronger signal than two who ordered a year apart, even if the fraud happened at the same time.

Compare that window against anything you changed on the site: a plugin installed, a script added, a supplier given access.

That comparison frequently identifies the cause in minutes where a general search of the site would take a day.

The counter-case

Do not over-react to a single report.

The overwhelming majority have nothing to do with the business receiving them, and rebuilding a checkout on the strength of one is disproportionate.

Telling other customers about a compromise you have not established would be alarming and unfounded.

And where you do find something, this stops being a website problem: there are notification obligations and a provider to inform, and that needs proper advice rather than a checklist.

Check the scripts, confirm the fields are hosted, record the report, and act properly if a second arrives.

What to do

1. Thank them and say you will check.
2. List the scripts on the checkout page.
3. Account for every one.
4. Confirm the card fields are hosted by the provider.
5. Check for recent file changes and new accounts.
6. Record the report and what you found.
7. Get proper advice if anything turns up.

Step four is the one that closes the scenario permanently, and it is a change to how payment is taken rather than an investigation you have to repeat.

What you should be holding at all is covered in a customer asking what you hold about them.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.