Module de protection des commandes - empêche les commandes en double et les factures ou paiements en double.

12/10/2026
v1.3.2

• La clé produit des modules complémentaires PrestaShop ( module_key ) est requise pour vendre ce produit sur cette plateforme. Rien d'autre ne change.

12/10/2026
v1.3.1

• Pour les validateurs d'extensions PrestaShop uniquement : la description du module doit tenir sur une seule ligne. Si elle est répartie sur plusieurs lignes, le validateur ne la lira pas et le processus de vérification des exigences échouera avec le message « $this >description n'est pas valide ». Le texte reste identique et la boutique ne s'en aperçoit pas.

12/10/2026
v1.3.0

Surveillance des paiements détournés. Ce système est issu d'un cas réel : un attaquant disposant d'un accès FTP a inséré un paiement par carte depuis sa propre passerelle de paiement dans le module Redsys. Pendant des mois, des commandes ont été créées au nom de Redsys, avec une configuration correcte dans le back-office (y compris la table du module) et les fonds crédités sur son compte. Aucune autre action n'est effectuée sur une commande ou un paiement : le système se contente d'enregistrer et d'alerter.

• Nouveau critère payment_mismatch : le numéro de transaction ne correspond pas à celui enregistré par la passerelle pour cette commande. Validateurs par passerelle ( classes/RkrOrderGuardGateway*.php , un emplacement par passerelle). Redsys est vérifié par signature : le Ds_Order commence par le numéro de panier suivi de zéros jusqu’à 8 chiffres et se termine par mmss (ou correspond à l’identifiant de commande à 12 chiffres avec la mention « Créer une commande avant de payer »). Ce critère est respecté, qu’il s’agisse d’un panier différent ou d’une autre commande du même client. Les formats vides ou obsolètes ne sont pas pris en compte. PayPal, PayPlug et Stripe sont vérifiés par format . Cette vérification est effectuée dans actionValidateOrder et enregistrée une seule fois par commande, et non à chaque changement de statut.
• La validation par rapport à la copie du dossier du magasin (plus de 100 000 commandes, vérifiées en moins d'une seconde) confirme que les commandes détournées apparaissent exactement, aucune avant le premier jour de l'attaque, et qu'il n'y a pas de faux positifs parmi les dizaines de milliers de commandes PayPal et PayPlug. Tous les comptes Redsys légitimes à 12 chiffres possèdent mmss valide ; les comptes à 12 chiffres sélectionnés aléatoirement échouent deux fois sur trois.
• Empreinte numérique du module de paiement ( payment_files ) : hachage SHA256 de chaque fichier de code des modules de paiement installés (actifs ou non, l’attaquant ayant désactivé PayPlug pour le dissimuler), ainsi que de ce module et de tous les fichiers individuels du répertoire racine. Vous êtes alerté en cas de modification, d’apparition ou de disparition d’un fichier. Une mise à jour de PrestaShop ne déclenche pas de notification : elle met simplement à jour la version dans la base de données, et l’empreinte numérique est automatiquement reconstruite. La version du fichier est invalide : l’attaquant a installé une version antérieure du module.
• Nouvel écran : Commandes → Suivi des paiements. Ouvrir les alertes (marquées comme examinées), les fichiers par module avec « Accepter les fichiers actuels » et consulter l’historique des numéros de transaction (lecture seule).
• Les notifications s'affichent comme suit : une bannière rouge apparaît sur l'ensemble de l'interface d'administration tant qu'une commande est ouverte, et une notification apparaît sur la page de détails de la commande , où se trouve l'expéditeur. Des notifications par e-mail et via RKR Sentinel sont également envoyées.
• Cron, avec son propre jeton ( /module/rkrorderguard/cron ), vérifie les fichiers et les commandes des sept derniers jours, au cas où certains auraient été créés sans passer par le hook. Sans cron, le back-office effectue cette vérification au maximum une fois par intervalle.
• Ce qu'il ne faut pas faire : vérifier la transaction avec Redsys. Le module Redsys ne permet pas d'effectuer de requêtes et Redsys est un service distinct que chaque banque active pour chaque commerçant. La confirmation se fait manuellement dans le panneau de contrôle.
• Coexistence avec RKR Order Guard Free, qui partage le tableau des incidents et clôture les éléments ouverts d'une commande qu'il considère comme correcte : un paiement détourné reste ouvert jusqu'à ce qu'un employé le marque comme examiné, peu importe qui le clôture.
• PrestaShop 9.1 n'affiche pas displayAdminAfterHeader sur les pages du contrôleur classique : la bannière est également placée à partir de displayBackOfficeHeader , sans être dupliquée.
• Correction d'un bug critique dans PrestaShop 9 lié à la réparation des commandes en double : la restauration du stock appelait ` StockAvailable::dependsOnStock() , qui n'est plus présente dans la version 9. Cette erreur se produisait uniquement lorsque l'annulation n'avait pas automatiquement restauré le stock.
• Vérification des modules complémentaires : tout le HTML est placé dans les modèles Smarty ( views/templates/admin/ ) et les scripts dans views/js/ ; absence Context:: , Tab::getIdFromClassName() et Module::isInstalled()/isEnabled() (obsolètes) ; .htaccess à la racine ; l() sans la sauvegarde Symfony, ce qui a laissé « Traduction introuvable » avec « Non » et « Total » ; la description config.xml est identique à celle de PHP ; PHP CS Fixer et PHPStan (niveau 5) sont exempts de problèmes.

30/09/2026
v1.2.0

Ce défaut présente une variante que la version 1.1.0 n'a pas détectée : lorsque le module de paiement crée la commande APRÈS le paiement, ce n'est pas la facture qui est dupliquée, mais la commande elle-même . Chaque élément reste cohérent en interne (la facture avec ses lignes de commande et son paiement rapproché), c'est pourquoi aucun des trois critères précédents ne l'a signalé. Sur une boutique réelle avec 143 649 commandes : 29 paniers contenant deux commandes, et parmi les 54 commandes les plus récentes, la version 1.1.0 n'en aurait signalé aucune .

• Nouveau critère duplicate_order : Une autre commande est active dans le même panier, avec une référence différente. Cette référence permet de la distinguer d'une commande fractionnée par colis, opération effectuée intentionnellement par PrestaShop, où toutes les commandes partagent la même référence. Par conséquent, un index unique sur orders.id_cart ne constitue pas le tableau approprié. Ce critère est vérifié lors de l' actionValidateOrder , déclenchée par la détection d'une nouvelle commande, et lors de chaque vérification ultérieure.
• Nouvel écran : Commandes → Commandes en double. Vérifiez et corrigez celles déjà présentes dans la boutique, une opération qui nécessitait jusqu'à présent une intervention manuelle. La colonne RKROG_SINCE n'est pas prise en compte : cette date sert au suivi en temps réel, et c'est ici que vous trouverez la précédente.
• La classification est l'élément essentiel de cet écran et provient de order_payment.transaction_id , qui est une donnée centrale indépendante de la passerelle de paiement : A correspond à un paiement et deux commandes (le trop-perçu est annulé, aucun remboursement n'est effectué), B à deux paiements distincts (un remboursement est nécessaire et la décision revient à un opérateur), et C à une situation indéterminée (elle est simplement listée). Seul le cas A est modifié.
• Et ce qu'il ne fait pas, et qui est tout aussi important : si le surplus a une facture numérotée, la facture n'est pas touchée (cela nécessite une correction), si un colis a été expédié, rien n'est touché, la passerelle n'est jamais appelée ni un retour émis, et rien n'est exécuté par lots sans marquage et confirmation.
• La simulation donne exactement les mêmes résultats que l'exécution. La décision finale est prise dans la analizar() `, qui ne produit aucune donnée ; aplicar() exécute uniquement les décisions déjà prises. Le rapport est équilibré par construction ( grupos = reparados + saltados + sin nada ) et un avertissement s'affiche en cas de déséquilibre.
• Le stock est mesuré, et non présumé. Le système central restitue le stock en cas d'annulation, mais uniquement si l'état précédent était pertinent et si le produit n'est pas géré par une administration avancée. Le stock est mesuré avant et après la restitution, et seul le stock non restitué est remis en stock : ajouter du stock par précaution entraînerait un double retour, ce qui est plus préjudiciable que de ne pas le restituer du tout.
• La référence de la passerelle devient la première clé de verrouillage. Sur un serveur n'autorisant qu'une seule requête GET_LOCK par session, seule la première clé est utilisée. Avec le panier d'achat en première ligne, les deux appels à la passerelle verrouillaient des noms différents : aucune exclusion mutuelle n'était possible, et le module était installé, actif, mais inactif. La référence de la passerelle est la seule à parvenir par les deux chemins ; la notification serveur à serveur arrive généralement sans aucun de nos paramètres.
• Journalisation optionnelle des verrous acquis ( RKROG_TRACE , désactivée par défaut). Sans elle, la découverte de ce problème prendrait une après-midi entière : il était impossible de savoir quelle clé avait bloqué une requête.