Un vendredi soir, le client d’une boutique WooCommerce nous signale une facture de passerelle de paiement anormalement élevée pour le mois, alors que le chiffre d’affaires réel n’a pas bougé. En creusant les journaux de commandes, le tableau est clair : plus de deux cents tentatives de paiement en une heure, toutes avec un montant inférieur à cinq euros, toutes échouées, chacune avec un numéro de carte bancaire différent. Ce n’est pas un pic de trafic légitime. C’est du card testing.
Symptôme : ce que révèlent les journaux de commandes
Le card testing consiste, pour un fraudeur, à vérifier en masse la validité de numéros de carte bancaire volés en les soumettant à un vrai formulaire de paiement, en général sur des montants faibles pour limiter les blocages automatiques de la banque émettrice. Un site marchand devient alors, sans le vouloir, un outil de validation pour des cartes volées revendues ailleurs sur des marchés clandestins. Les symptômes typiques dans WooCommerce :
- Un nombre inhabituel de commandes au statut « échouée » sur une courte période, largement supérieur au taux d’échec habituel du site.
- Des montants de commande faibles et récurrents, souvent le prix du produit le moins cher du catalogue.
- Des adresses de livraison ou de facturation incohérentes entre elles ou avec l’adresse IP d’origine.
- Un volume de requêtes vers la page de paiement bien supérieur au trafic normal du site sur la même plage horaire.
Diagnostic : confirmer qu’il s’agit bien de card testing
Avant de réagir, il faut confirmer le diagnostic pour éviter de bloquer par erreur un pic de commandes légitime (soldes, campagne publicitaire réussie). Une requête directe en base, via WP-CLI ou phpMyAdmin, permet de croiser rapidement le nombre de commandes échouées par adresse IP source, information généralement disponible dans les méta-données de commande ou les journaux de la passerelle de paiement :
wp wc order list --status=failed --after="1 hour ago" \
--format=csv --fields=id,date_created,total,billing_emailUn grand nombre d’adresses e-mail de facturation différentes, associées à la même plage d’adresses IP ou au même user-agent, sur un intervalle de temps très court, confirme le schéma d’une attaque automatisée plutôt qu’un afflux de vrais clients.
Diagnostic complémentaire côté passerelle de paiement
La plupart des passerelles de paiement sérieuses (Stripe, PayPal, les principales solutions françaises) proposent un tableau de bord de détection de fraude qui signale explicitement les schémas de card testing détectés de leur côté, avec un taux de refus par carte anormalement élevé. Ce signal, croisé avec les journaux WooCommerce, confirme définitivement le diagnostic avant de mettre en place des contre-mesures qui pourraient gêner de vrais clients si le diagnostic était erroné.
Correctif : limiter le débit de tentatives de paiement
La première parade consiste à limiter le nombre de tentatives de paiement autorisées par adresse IP ou par session sur une fenêtre de temps donnée, au niveau du serveur web ou d’un pare-feu applicatif, plutôt que dans WooCommerce lui-même qui n’est pas conçu nativement pour cette fonction. Sous nginx, une zone de limitation dédiée à la page de paiement :
limit_req_zone $binary_remote_addr zone=checkout:10m rate=5r/m;
location = /checkout/ {
limit_req zone=checkout burst=3 nodelay;
# ... reste de la configuration
}Correctif : un captcha au moment du paiement, pas avant
Ajouter un captcha (Cloudflare Turnstile, hCaptcha, reCAPTCHA) directement à l’étape de paiement du tunnel de commande, plutôt qu’uniquement sur les formulaires de contact ou d’inscription, bloque l’essentiel des scripts automatisés qui alimentent les tentatives en masse. WooCommerce propose des points d’accroche (woocommerce_review_order_before_submit) pour insérer ce contrôle juste avant la validation finale de la commande, sans perturber le reste du parcours d’achat pour les clients légitimes.
Correctif : les règles de la passerelle de paiement elle-même
- Activer les règles de détection de fraude proposées nativement par la passerelle (Stripe Radar ou équivalent), qui bloquent automatiquement les schémas de card testing reconnus à l’échelle de milliers de marchands, pas seulement du vôtre.
- Définir un montant minimum de commande acceptable côté passerelle si le catalogue le permet, pour rendre le test de carte moins intéressant économiquement pour le fraudeur.
- Activer la vérification AVS (Address Verification System) et le contrôle du cryptogramme visuel (CVV) systématique, qui filtrent une partie des tentatives utilisant des numéros de carte partiels ou générés.
Prévention : réduire la surface d’attaque en continu
Une fois l’attaque en cours stoppée, la vigilance ne s’arrête pas là : le card testing cible en priorité les boutiques identifiées comme peu protégées, souvent repérées justement par un premier test réussi. Un suivi régulier du taux d’échec de paiement, avec une alerte automatique en cas de dépassement d’un seuil défini pour le site, permet de détecter une reprise de l’attaque avant qu’elle ne prenne l’ampleur de la première fois.
Sur ce dossier, la combinaison limitation de débit plus captcha au paiement a fait chuter les tentatives de plus de deux cents par heure à moins de cinq en une journée. La facture de passerelle du client est revenue à la normale dès le mois suivant.
En résumé
Le card testing ne vise pas à voler l’argent du marchand directement, mais à utiliser sa page de paiement comme outil gratuit de validation de cartes volées, avec un coût réel en frais de transaction et en risque de blocage par la passerelle. Repérer le schéma dans les journaux de commandes, confirmer le diagnostic côté passerelle, puis combiner limitation de débit, captcha ciblé au paiement et règles anti-fraude natives de la passerelle couvre l’essentiel des cas rencontrés sur WooCommerce.
