Commandes fantômes, à 0 € ou emails jetables : que vérifier

Ce que ces commandes racontent

Une boutique piratée laisse des traces métier, pas seulement des fichiers PHP. Une rafale de commandes à 0 € à 4 h du matin, toutes en « traitement », toutes avec `@yopmail` ou un domaine ukrainien alors que vous ne livrez qu'en France : quelqu'un a un accès scriptable au checkout ou à l'admin.

Deux intentions dominent. La première : vérifier que l'API, le webhook ou le back-office répond — un ping déguisé en commande. La seconde : créer des objets (commande, facture PDF, page de confirmation) qui hébergent un lien ou un fichier. Dans ce second cas, l'URL de la commande devient une page de spam ou de phishing indexable.

Un prestataire de paiement peut aussi créer des « tentatives » légitimes (3-D Secure abandonné). Le critère, c'est le motif : même IP, même user-agent, e-mails jetables, montant nul, produits qui n'existent plus. Un seul de ces indices oriente ; deux le confirment.

Zéro euro n'est pas forcément un bug boutique

Un coupon à 100 %, un produit gratuit, un frais de port offert : votre boutique sait déjà faire du 0 €. Avant de crier au pirate, listez les règles promo actives. Un code `TEST` oublié depuis la recette, utilisé 200 fois cette nuit, est un incident de configuration — ou un code que l'attaquant a lu dans un e-mail de staging.

Le 0 € pirate, lui, n'a souvent pas de coupon : le montant est forcé en base, ou passé par une API REST WooCommerce avec une clé trop large. Regardez si le total TTC a été écrit à la main (`order_total = 0` sans `coupon_lines`).

Des commandes à 0,01 € existent aussi : elles passent certains filtres antifraude et valident un flux. Traitez-les comme les 0 € si le reste du profil (e-mail, IP, heure) colle.

• Coupons et règles panier encore actifs.
• Clés API Woo / webservice Presta avec droit d'écriture commandes.
• Modules de paiement « test » restés en production.
• Produits à 0 € que vous n'avez pas créés.

Exporter avant de nettoyer

L'export CSV ou le dump des tables commandes est votre pièce. Dates, montants, e-mails, IP si vous les logguez, identifiants. Sans ça, vous racontez l'incident de mémoire à l'assureur ou à la banque. Avec ça, vous avez un tableau.

Exportez aussi les notes internes et les e-mails transactionnels liés. Un webhook Stripe rejoué, un statut passé de « échec » à « terminé » sans paiement : ça se voit dans les notes, pas dans le total.

Stockez l'export hors du serveur de la boutique. Un CSV dans `wp-content/uploads` se corrompt avec le reste, ou se retrouve en téléchargement public. Le même réflexe que pour la copie du site : ailleurs, horodaté.

WooCommerce : commandes, notes, user agent

WooCommerce range les commandes dans `wp_posts` (`shop_order`) ou dans les tables HPOS (`wc_orders`). Les deux peuvent cohabiter le temps d'une migration. Cherchez les deux. Un nettoyage « dans l'écran Commandes » rate les lignes HPOS si l'UI n'est pas branchée dessus.

Ouvrez une commande suspecte : notes, user agent, origine (`order_attribution` si activé). Un user-agent `python-requests` sur un panier « iPhone » est plus parlant qu'un scan de thème. Les meta `_customer_ip_address` et `_customer_user_agent` sont encore là sur beaucoup de sites.

Les clés REST (`WooCommerce → Réglages → Avancé → REST API`) : toute clé avec le droit `lecture/écriture` que vous ne nommez pas se révoque. C'est l'équivalent boutique d'un admin fantôme.

PrestaShop : paniers, e-mails, employés

Regardez `ps_orders`, mais aussi `ps_cart` : des centaines de paniers abandonnés à la même minute, même IP, c'est un bot. Les commandes validées sans paiement module « gratuit » ou « virement » que vous n'utilisez pas sont un autre signal.

Les employés (`ps_employee`) : un compte `demo@prestashop.com` ou un profil recopié depuis « SuperAdmin ». Croisez avec module de paiement inconnu : poser un module et créer des commandes vont souvent ensemble.

Les e-mails de confirmation PrestaShop peuvent partir vers les jetables. Si votre SMTP est déjà en abuse, ces envois aggravent la liste noire mail. Coupez l'envoi transactionnel le temps du tri si le volume est absurde.

Distinguer test de paiement et kit de transit

Test de paiement : l'attaquant veut savoir si Stripe, PayPal ou votre module maison répond. Les commandes sont courtes, parfois annulées, parfois en échec. Le danger est le skimmer ou le module posé à côté, pas la commande elle-même.

Transit : la page de confirmation, le PDF, ou une URL `/commande/merci/?id=` sert une page tierce. Inspectez ces URL comme un visiteur non connecté. Si vous voyez une pharmacie ou un formulaire bancaire, c'est l'exception : on coupe cette URL tout de suite, comme une fausse page bancaire.

Dans le doute, ouvrez l'URL de thank-you en navigation privée. Le back-office vous montre le métier ; le visiteur voit parfois autre chose. C'est le même réflexe que pour le cloaking Google, appliqué au tunnel.

Ce qu'il ne faut pas supprimer avec

N'effacez pas les vraies commandes du mois pour « faire le ménage ». La comptabilité, les stocks, les litiges PayPal s'appuient sur ces IDs. Filtrez par date, e-mail, montant, puis annulez ou passez en échec les lignes pirates — selon ce que votre expert-comptable accepte.

Ne restaurez pas une sauvegarde boutique d'il y a six mois pour supprimer les fantômes : vous perdez les commandes réelles. Isolez les IDs, traitez-les. Une restauration sale replace aussi le module pirate.

Les comptes clients liés à ces commandes se traitent à part : voir comptes créés en masse. Fusionner les deux gestes dans un `DELETE` trop large est le plus court chemin vers un lundi de réclamations.

• Garder les commandes payées réelles.
• Exporter avant tout statut de masse.
• Ne pas restaurer « la dernière » pour effacer des lignes.

Fermer l'entrée, pas seulement la liste

Révoquez les clés API, les webhooks inconnus, les employés, le module de paiement. Changez le panel d'hébergement avant l'admin boutique. Un employé retiré et un FTP encore ouvert, les commandes reviennent.

Vérifiez que le checkout légitime n'a pas un JavaScript tiers ajouté. Une commande fantôme peut n'être que le bruit ; le skimmer est le fond. Testez le tunnel comme un client, carte de test, mobile.

Si l'hébergeur a parlé de resource abuse, ces créations de commandes (hooks, e-mails, PDF) suffisent à saturer un mutualisé. Croisez avec processeur saturé si le CPU colle aux horaires des commandes.

Après : banque, clients, Google

S'il y a eu un module de paiement inconnu ou un script sur le checkout, le sujet n'est plus « commandes à 0 € ». C'est cartes, PSP, éventuellement information des clients. Calibrez avec le constat, pas avec l'espoir.

Si des URL de commande sont dans `site:votre-domaine.fr` avec des titres hors métier, désindexez le préfixe une fois qu'elles répondent 404. Pas de réexamen Safe Browsing pour de simples lignes admin — sauf page d'hameçonnage encore en 200.

Vous pouvez ouvrir un espace pour faire relire le tunnel. En attendant : export, révocation des clés, mot de passe panel. La liste des commandes attend ; les clés API n'attendent pas.