Rapprocher commandes et banque : repérer les paiements que votre boutique croit avoir reçus

Le back-office indique « Paiement accepté » et la commande part vers l'entrepôt. C'est normal, et c'est presque toujours vrai. Mais ce statut est écrit par votre boutique, pas par votre banque : c'est ce que la boutique croit qu'il s'est passé. L'argent est confirmé à deux autres endroits, le tableau de bord de la passerelle et le relevé bancaire, et si personne ne les compare aux commandes, un écart peut durer des mois.

Ce n'est pas une curiosité théorique. Nous avons vu des boutiques avec des commandes « payées » dont l'argent était parti sur le compte de quelqu'un d'autre, des boutiques avec deux commandes pour chaque paiement et des boutiques avec des paiements qui ne sont jamais devenus des commandes. Dans tous les cas, un rapprochement hebdomadaire l'aurait détecté en quelques jours.

Pourquoi commandes, passerelle et banque cessent de concorder

Détournement de paiements

C'est le cas le plus grave. Quelqu'un qui a accès aux fichiers de la boutique —via un mot de passe FTP volé ou un module vulnérable— modifie le module de paiement pour que le client paie sur une passerelle de l'attaquant. La commande est créée au nom du module légitime, le statut est le même que d'habitude et tout semble normal dans le back-office. Une seule différence : dans le tableau de bord de votre passerelle, cette transaction n'existe pas.

La variante simple consiste à changer l'IBAN du virement bancaire dans la configuration. Le client paie, la commande reste en attente, le client assure qu'il a payé, et vous ne trouvez pas le versement.

Notifications en double ou perdues

La passerelle informe votre boutique que le paiement est terminé au moyen d'une notification (IPN, webhook ou retour du client sur la boutique). Si deux arrivent en même temps, vous pouvez vous retrouver avec deux commandes pour un seul paiement, chacune avec sa facture et son stock décompté. Si aucune n'arrive, c'est l'inverse : un paiement sans commande, et un client qui a payé et ne reçoit rien.

Modifications manuelles et remboursements hors de la boutique

• Un employé passe en payée une commande par virement avant d'avoir vu le versement.
• Un remboursement est fait depuis le tableau de bord de la passerelle et la commande reste payée.
• Une rétrofacturation arrive et la commande n'en sait rien.

Des versements qui ne sont pas des commandes

Les passerelles ne versent pas commande par commande : elles règlent par lots et déduisent commissions, remboursements et rétrofacturations. C'est pourquoi on ne peut pas rapprocher la banque directement des commandes ; il faut l'étape intermédiaire de la passerelle.

Les deux rapprochements à faire

Rapprocher, c'est croiser trois sources en deux étapes :

1. Commandes ↔ transactions de la passerelle. Chaque commande payée par carte, Bizum ou PayPal doit avoir sa transaction dans le tableau de bord, pour le même montant. Et chaque transaction encaissée doit avoir sa commande.
2. Transactions ↔ crédits en banque. La somme des transactions d'une période, moins les commissions, remboursements et rétrofacturations, doit correspondre à ce que la passerelle vous a versé.

La première étape est celle qui révèle détournements et doublons. La seconde révèle les commissions inattendues, les retenues et les versements qui n'arrivent pas.

Le rapprochement hebdomadaire, étape par étape

1. Exportez les commandes payées de la semaine avec la référence, le montant total, le module de paiement et le numéro de transaction. Dans PrestaShop, ce numéro se trouve généralement dans le paiement de la commande (table ps_order_payment, champ transaction_id), même si certains modules le stockent dans leurs propres tables.
2. Exportez les transactions du tableau de bord de chaque passerelle pour la même période, avec leur numéro, leur montant et leur statut.
3. Croisez par numéro de transaction, pas par montant. Deux commandes de 49,90 € croisées par montant sont validées même si l'une est fausse.
4. Établissez trois listes : commandes sans transaction, transactions sans commande et montants qui ne concordent pas.
5. Rapprochez les versements de la passerelle des crédits du relevé.
6. Notez ce que vous avez fait de chaque écart. Un écart inexpliqué, plus personne ne s'en souviendra la semaine prochaine.

Virements, paiement à la livraison et Bizum manuel

Avec les moyens de paiement sans notification automatique, la commande passe en payée parce qu'une personne le décide. La règle est simple : on ne la marque payée qu'avec le relevé sous les yeux, jamais parce que le client envoie une capture du justificatif, qui se falsifie en une minute. Et vérifiez de temps en temps que l'IBAN affiché par votre boutique sur la confirmation de commande et dans les e-mails est bien le vôtre.

Signes qu'un détournement est en cours

• Des numéros de transaction d'une forme différente de celle habituelle pour cette passerelle.
• Une passerelle qui verse moins que ce qu'indiquent les commandes.
• Des clients qui disent avoir payé et dont le paiement n'apparaît dans aucun tableau de bord.
• Des fichiers du module de paiement avec une date de modification qui ne correspond à aucune mise à jour.
• Des changements dans la configuration des passerelles que personne dans l'équipe ne se souvient d'avoir faits.

Pourquoi c'est aussi une question de boutique à jour

Le détournement de paiements suppose d'écrire sur votre serveur. Les voies les plus courantes sont des identifiants FTP ou du panneau d'hébergement volés et des modules avec des vulnérabilités connues que personne n'a mis à jour. Une boutique avec PrestaShop, PHP et des modules à jour, et des comptes d'accès vérifiés, complique beaucoup la tâche de l'attaquant. Le rapprochement détecte le problème ; la mise à jour réduit le nombre de fois où il se produit.

Checklist

• Rapprochement commandes ↔ passerelle chaque semaine, par numéro de transaction.
• Rapprochement passerelle ↔ banque à chaque versement.
• Virements marqués payés uniquement avec le relevé.
• Vérification régulière de l'IBAN et des clés des passerelles dans la configuration.
• Alerte quand les fichiers des modules de paiement changent.
• Registre de chaque écart et de sa résolution.

Comment le résoudre dans PrestaShop

RKR Order Guard empêche les commandes en double quand deux notifications de la passerelle arrivent en même temps et passe en revue l'historique pour trouver celles que vous avez déjà, en les classant selon qu'il y a un ou deux paiements : la commande en trop passe en Annulé et son stock est réintégré, et les remboursements sont décidés par une personne. Il surveille aussi les paiements détournés à deux niveaux : il vérifie le numéro de transaction de chaque commande (par signature chez Redsys, par la forme de l'identifiant chez PayPal, PayPlug et Stripe) et conserve l'empreinte des fichiers de vos modules de paiement pour vous alerter s'ils changent sans mise à jour. L'alerte s'affiche sur la fiche de la commande, là où se trouve la personne qui va l'expédier. RKR Security Alert complète la surveillance : il garde un instantané de la configuration, des modules et des employés, marque comme critiques les changements dans les passerelles de paiement même s'ils sont faits en SQL direct et vous prévient par Telegram.