# Suspicious orders or customer accounts are appearing

> Orders placed with different bank cards within minutes, or dozens of customer accounts created the same night: this is almost never a rush of genuine traffic, but an automated test or abuse.

- Source canonique : [https://allaux.fr/en/securite/commandes-comptes-clients-suspects](https://allaux.fr/en/securite/commandes-comptes-clients-suspects)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Split the two scenarios first: a burst of declined payments, or mass account creation. For the former, list the attempts in your payment provider dashboard and the matching IP addresses in the host access log, then temporarily switch off the targeted module. Tell your payment provider before they spot the decline rate themselves.

## Two distinct scenarios, two different causes

- A burst of failed orders within minutes, each with a different card number, often for an identical or very low basket amount
- These attempts arrive at any hour, including the middle of the night, at a frequency no human visitor could reach by typing manually
- The billing name and address change with every attempt, unrelated to the visitor's IP address or apparent location
- Dozens or hundreds of customer accounts created in a single night, with email addresses following a very similar pattern (number sequences, disposable domains)
- None of these orders or account creations is ever followed by normal browsing of the catalogue

## Carding, and why your store gets used for it

A burst of failed orders with different cards matches a known practice called carding: an attacker tests card numbers in bulk to find out which ones are still valid, before reselling or using them elsewhere. I won't detail how those numbers are obtained here, only the observable symptom: your checkout page is being used as a verification tool, not a way to buy. A small merchant is an attractive target for this precisely because their checkout page is often less protected than a large retailer's against repeated automated attempts.

Mass creation of fake customer accounts generally follows a different logic: building up a pool of credentials to later test password combinations reused elsewhere (a technique called credential stuffing), artificially inflating volume for a poorly protected affiliate or referral scheme, or simply bloating a database to slow it down. These two phenomena don't share the same technical cause, but they do share one thing: they exploit the fact that an order or sign-up form accepts automated submissions at a rate no human can reach, with no limit or check.

On PrestaShop, this kind of abuse is sometimes made easier by a flaw in a poorly secured payment or account module, which for instance leaves an entry point reachable without going through the cart's normal checks. I'll stay general on this point, as I don't have a specific vulnerability identifier to cite here: what matters for a merchant is checking whether the module in question has had a recent update, and treating any third-party payment module as a priority area to watch.

## Don't re-enable a suspect module just to keep selling

> If carding is targeting a specific payment module, temporarily disabling it, even if that interrupts some sales, is preferable to leaving a card-testing channel open: the damage to your merchant account and your relationship with your payment provider can far outweigh a day's lost revenue.

## What to check and do

1. **Isolate the orders involved without deleting them** — They serve as evidence for your payment provider and, where relevant, for a report if your merchant account is questioned.
2. **Contact your payment provider** — A spike in declined transactions in a short time is a signal they're also monitoring; reporting it promptly avoids a unilateral suspension of your merchant account.
3. **Set a rate limit on the checkout and sign-up forms** — A maximum number of attempts per IP address within a given window blocks most automated scripts without inconveniencing a genuine customer.
4. **Add an anti-bot check on exposed forms** — A check of this kind, correctly configured not to inconvenience a human visitor, sharply cuts the volume of automated submissions.
5. **Purge the identified fake customer accounts** — After confirming none of them placed a genuine order, these accounts should be removed so they don't distort your statistics or remain exploitable.

## Going further

- **SQL injection explained** — The most commonly exploited flaw against your customer and order database. ([/securite/injections-sql-expliquees](/securite/injections-sql-expliquees))
- **Check if my site is compromised** — Free checks to run before paying for a full audit. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Security service** — Diagnosis, cleanup and closing the flaw on PrestaShop. ([/services/securite](/services/securite))

## FAQ

### Does seeing carding mean my site has definitely been hacked?

Not necessarily. Carding can target a checkout form without any intrusion happening elsewhere on the site, simply because that form is publicly reachable and poorly protected against automated submissions.

### Do failed carding attempts actually cost money?

Yes, indirectly: a high volume of declined transactions damages your acceptance rate with your payment provider, which can lead to extra fees or closer scrutiny of your merchant account.

### Should I notify customers whose genuine orders get mixed in with these attempts?

Only orders actually placed with a real customer's details are affected. Sorting genuine orders from carding attempts is done by cross-checking which payments were actually accepted.

### Can fake customer accounts access other customers' orders?

Normally not, unless a separate flaw exists in the account system. It's worth checking separately if the volume of fake accounts is significant.

### Is a simple rate limit enough to stop this for good?

It cuts the volume sharply, but a determined attacker can spread attempts across multiple IP addresses. That's why it's usually combined with an anti-bot check and ongoing monitoring.