Jump to content

Commande avec double statut "Paiement accepté" et double paiement [Résolu]


Recommended Posts

Bonjour,

PS version 8.1.6 - PHP : 8.1.29

Sur une de nos boutiques et depuis quelques semaines, de manière aléatoire, certaines commandes sont enregistrées avec un double statut "Paiement accepté", à quelques secondes d'écart, et nous avons également deux paiements, eux aussi à quelques secondes d'écart, et un seul de ces paiements a un numéro de facture. Le clients n'a pas de problème, un seul paiement est bien prélevé, mais la commande ne remonte pas dans le tableau de bord.

image.thumb.png.417299ecdec1e6bce4fdbac0b2fdc8fd.png

image.thumb.png.52b1806083a2fd1d5229351ff0051284.png

Nous avons cru un moment que cela venait du module UpToPay du crédit agricole (version 7.0.5), mais le problème est survenu également avec Paypal. J'ai cherché, un peu partout, sans succès.

Dans les logs, au moment de ces commandes en défaut, nous avons un avertissement "Frontcontroller::init - Cart cannot be loaded or an order has already been placed using this cart" suivi d'une multitude (plusieurs dizaines) d’avertissements du type "Error: parameter "to" is corrupted". Je ne sais pas si c'est lié, mais c'est la seule piste que j'ai !

image.thumb.png.b57920d09eefa8fe8413523a7ad6604f.png

Si quelqu'un a une idée, une suggestion quelconque, je suis preneur, je m'arrache la tête dessus depuis des jours :(

Merci par avance.

Edited by Aspho_Fred (see edit history)
Link to comment
Share on other sites

Vous devez avoir un module accroché sur le HookValidateOrder qui fait ramer la création de commande et donc, les infos ne remontant pas assez rapidement aux modules de paiement, ceux-ci sont répétés.

Le paramètre to corrompu signifie que l'email du destinataire n'est pas valide (surement lié à mailalerts). Vérifiez que vous n'avez pas des mails pourris dans la table ps_mailalert_customer_oos.

Link to comment
Share on other sites

Merci Eolia pour votre réponse rapide...

Je n'ai pas de hook "validateOrder". Par contre, j'en ai d'autres qui pourraient potentiellement poser problème :

image.thumb.png.a10c91900747187e68775679b19c4250.png

image.thumb.png.0c14ec157cf89ceb284be7dff056d268.png

image.thumb.png.555f19e0acbcc390b8db1ac376515300.png

image.thumb.png.e3df9475e9c082d21667a2fae7c806cb.png

image.thumb.png.623799c4b5150f47b2eb0d328959771e.png

Sauf que Prestashop Shipping est désactivé chez nous (il posait problème avec les modules de transport que nous que nous utilisons déjà), et Klaviyo, Paiement comptant, Marketing with Google, PS social with Facebook and Instagram sont également tous désactivés... Donc je ne vois pas quel module poserait problème. Up2pay est notre module de paiement par défaut, utilisé depuis belle lurette (avec des soucis divers comme tout le monde !), Ckeckout, aussi, et MondialRelay également. Pensez-vous qu'un de ces 3 modules pourrait en être la cause ?

Quant à la table ps_mailalert, elle contient plus de 3000 enregistrements (nous sommes en rupture de certains produits depuis un bout de temps et nos clients les attendent avec impatience) et il m'est impossible de voir si des adresses sont bidons ou pas. Par contre, je ne comprends pas bien le lien avec la création de commande. Je pensais que cette table était utilisée (et les enregistrements concernés supprimés) uniquement lorsqu'un produit qui y fait référence revenait en stock. Me trompe-je ?

Tous mes remerciements anticipés pour votre aide, j'avoue y perdre mon latin (que j'ai par ailleurs perdu depuis longtemps :))

Bien cordialement.

 

Link to comment
Share on other sites

Vous avez bien coché la case  des hooks invisibles ?

image.thumb.png.a71f468b01f9d9f1653bba42b506b4a5.png

Le module mailalert est hooké dessus et check les produits / quantités et envoie des mails si des produits sont revenus en stock et que le mail n'aurait pas été envoyé.

Le problème c'est que si une adresse est incorrecte le mail ne sera jamais envoyé donc ça recommencera.

Il faut donc dans ces commandes, récupérer les ID produits et Attributs, trouver les alertes mails qui sont associées à ces id_product et id_product_attribute et virer la lou les fautives.

Link to comment
Share on other sites

"Vous avez bien coché la case  des hooks invisibles ?" 🥴... C'est vendredi !

Alors effectivement, c'est mieux ! Je comprends mieux les accès à la table mailalert... Je vais regarder ça.

Concernant les modules qui ralentiraient le processus de commande, il va falloir que je check.

Il me reste celui de la TVA, Chronopost (ça ne serait pas étonnant), Mondial Relay (heu, pareil en fait !) ou Avis vérifié (qui est un peu une usine à gaz...)

image.thumb.png.bc3f55d4e703854994ec44d149a34143.png

Merci pour tous ces tuyaux, je vais tenter de trouver celui qui nous enquiquine en les désactivant un par un, même si c'est pas facile en PROD des virer les modules de transport...

Je vous tiens au courant, bien entendu. Et merci encore pour cette aide inestimable.

Bonne soirée.

Link to comment
Share on other sites

Cher Eolia,

Merci infiniment pour vos bons conseils, notre problème est résolu... Effectivement, en analysant le contenu de la table mailalert, nous nous sommes rendus compte qu'il y avait des centaines de mail associés à des produits, pourtant en stock ! Je n'en connais pas la raison, mais en purgeant cette table de ces enregistrements, tout est rentré dans l'ordre.

La pertinence de votre analyse nous a permis cette résolution rapide.

Si vous avez besoin de conseils sur la filtration d'eau, nous nous tenons à votre disposition :)

Bien cordialement.

  • Like 1
Link to comment
Share on other sites

  • Aspho_Fred changed the title to Commande avec double statut "Paiement accepté" et double paiement [Résolu]

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...