Bug plusieurs notifications pour une seule transaction reussie

Bonjour,

Dans les emails, c'est toujours le numéro de commande qui est affiché et non le numéro de facture. Le numéro de facture est uniquement sur la facture. Donc il est normal que vous ayez 52 sur l'email si le numéro de commande est 52, peu importe la valeur du numéro de facture.

Concernant les emails en doublon, cela indique que Paybox a envoyé la notification de paiement plusieurs fois à votre site.
Je ne vois pas pourquoi Paybox ferait cela pour votre site et pas les autres. Peut être quelque chose à voir avec la configuration du site en particulier ou du compte marchand.
Peut être que le support paybox pourrait vérifier leur logs pour voir pourquoi la notification est renvoyé plusieurs fois.
Après il peut être intéressant de rajouter ce code:
if($dbOrder->order_status == $order_status)
return true;
après la ligne:
$payment_status = 'Accepted';
dans le fichier plugins/hikashoppayment/paybox/paybox.php pour éviter de confirmer la commande si elle l'a déjà été.

Bonjour,

2. Comme je l'expliquais dans mon précédent message, le numéro de facture n'est pas présent dans les emails envoyés par HikaShop.
Donc il est impossible que le numéro de facture soit faux dans les emails puisqu'il n'est pas dans les emails du tout... à moins que vous l'ayez rajouté vous-même, et dans ce cas il y a surement un soucis avec la façon dont vous l'avez rajouté.

3. Si vous confirmez que cela fonctionne, nous pouvons les ajouter dans la prochaine version d'HikaShop et ainsi vous n'aurez rien à faire pour les mises à jour futures.

4. Donc la commande est confirmée mais pas d'email. Dans ce cas, vérifiez le menu Customers>Emails history. Là vous avez tous les emails envoyés par HikaShop. Avez-vous l'email que vous auriez dû recevoir ? Si non, alors l'email n'a pas été généré par HikaShop, soit à cause d'un problème (par exemple, le PDF de la facture n'a pas pu être généré à cause de caractères spéciaux dans le nom d'un produit de la commande) soit car l'email a été désactivé dans Système>Emails. Si oui, alors l'email a été généré et envoyé par HikaShop et soit votre serveur email n'a pas pu l'envoyé, soit le serveur email receveur l'a refusé. Dans ce cas, il faudra se rapprocher de l'hébergeur avec les informations de l'email pour qu'il regarde dans les logs du serveur email pourquoi l'email n'a pas pu être transmis.

5. Regardez dans la section "historique" de la commande. Vous devriez avoir une ligne pour la création de la commande et une ligne pour chaque notification de paiement. Si vous n'avez qu'une ligne de notification, c'est en effet qu'il n'y a qu'une notification de paiement reçue et donc le problème ne vient pas de paybox. Notez que par défaut le plugin PDF ne génère une facture PDF que pour la confirmation de la commande, et donc après la génération du numéro de facture. Cependant, il est possible de configuré le plugin pour générer une facture PDF à la création de la commande, et donc avant la génération du numéro de facture. Dans ce cas, c'est le numéro de commande qui est utilisé en tant que numéro de facture dans le PDF. Si c'est ce qu'il se passe sur votre site, alors le soucis vient des paramètres du plugin PDF qui est mal configuré. Donc vérifiez cela.

Bonjour,

D'après vos nouvelles informations, le soucis est que Paybox ne reçoit pas de réponse à ses notifications de paiement dans les 20 secondes et du coup, il pense qu'il y a eu un problème et renvoi la notification une seconde fois.
Donc le code que j'ai fourni pour le plugin paybox évitera la duplication des emails de notification.
Le fait que le processing de la notification de paiement met plus de 20 secondes vient surement de la communication entre Joomla et votre serveur d'envoi d'emails. Suivant comment la connexion avec votre serveur d'email est faite et suivant la rapidité de traitement du serveur, un envoi d'email peut aller de moins d'une seconde à plusieurs secondes. Et si vous avez des pièces jointes (genre la facture PDF) alors cela ralenti encore plus l'envoi de l'email car il faut transmettre la pièce jointe au serveur d'envoi.
En plus, il y a deux emails envoyés à chaque fois: celui de notification de paiement et cela envoyé à l'utilisateur pour la confirmation de la commande. Donc il est fort possible que cela vienne de là.
Testez le changement de statut d'une commande dans le backend avec envoi de l'email de notification et vous verrez le temps que prend le process, et cela pour un seul email. Si cela met 10 secondes avant d'avoir la fin du processing, alors cela confirmera la théorie.