Savoir traiter un HTML 500 lors de l'appel à l'url de notification

Ce sujet est une source d'appel importante au support.
A la fin du paiement, vous nous demandez d'appeler une URL sur votre serveur afin de transformer le panier en commande.

Dans la majorité des cas, HTML 500 est tout simplement un bug applicatif. Un bug chez vous!

Donc lors de l'appel lorsque nous détectons cette erreur HTML, nous vous envoyons un mail en temps réel pour vous prévenir qu'un problème est intervenu sur VOTRE serveur.

Et votre réflexe est d'appeler le support Lyra. Détecter l'erreur ne veut pas dire en être à l'origine.

Car nos modules ne génèrent pas ce code. Nos modules sont plutôt bien écrits.

Lorsque nous appelons l'URL, nous appelons effectivement dans le cas de Prestashop par exemple, un point d'entrée qui est celui de notre module.
Mais ce n'est qu'un point d'entrée qui va déclencher de multiples traitements sur votre serveur:

  • mise à jour des stocks
  • édition de facture
  • envoi de mails à votre acheteur
  • statistiques,
  • appel transporteur (logistique)
  • etc..
Autant de modules tiers que nous ne maîtrisons pas, et qui pour certains ne sont pas à jour et sont moins bien écrits que notre plug-in de paiement.

Que faire?

Chercher le coupable et pas forcément nous appeler car nous ne sommes pas le support des modules tiers. C'est déjà assez compliqué de gérer nos propres modules sans aller analyser les bugs de nos voisins. 😉

Notre documentation par exemple pour Prestashop vous donne des pistes de recherche. Et la réponse se trouve toujours dans les logs de votre serveur https et de Prestashop. 





En résumé, si vous avez une implémentation propriétaire, analysez vos logs et si vous avez installé un de nos modules de paiement, regardez quel module tiers est en cause. Car dans 99,999% des cas, nous n'y sommes pour rien.

Commentaires