A la fin du paiement, le marchand a la possibilité en fonction de différents événements ou statuts (accepté ou refusé), de demander l'appel à une url de notification instantanée (IPN en anglais comme Instant Payment Notification) sur son serveur.
Cette URL que le marchand nous demande d'appeler, est une demande d'exécution de code sur le site du marchand.
Cette URL est très importante:
- il est toujours possible de traiter la commande via l'URL de retour, si l'acheteur revient sur le site marchand.
- Mais si ce dernier ne revient pas sur le site, l'unique façon de notifier le site de la fin du paiement est l'exécution de cette URL.
Le temps de traitement sur le site marchand est à surveiller et doit être le plus rapide possible. En général un serveur bien programmé exécute ce traitement en moins de 2 secondes. Voire moins!
Cela doit être rapide car avant de donner le résultat du paiement à l'acheteur nous attendons la bonne fin de ce traitement sur le site marchand.
Cela veut dire que nous restons à l'écoute du traitement jusqu'à sa bonne fin.
Au bout de 35 secondes, (ce qui est énorme et on nous a déjà demandé d'augmenter ce temps!!!) nous arrêtons d'attendre et nous envoyons un email en temps réel au marchand pour lui indiquer que son temps de traitement est très long.
En langage d'informaticiens, on dirait: "votre serveur rame grave!"
Il est très important de comprendre que ce n'est pas parce que nous arrêtons d'écouter la réponse, que cela arrête le traitement sur le serveur du marchand. Si votre traitement dure 1 mn ou plus, nous ne le savons pas. Nous sommes partis pour donner à l'acheteur le résultat de sa demande de règlement, car au bout de 35 secondes il en a surement marre d'attendre.
Lorsque les marchands reçoivent ce mail, ils appellent fréquemment le support de la plateforme LYRA pour se plaindre de notre solution.
Sauf que le traitement est fait sur votre serveur et pas sur le nôtre.
Donc il appartient au marchand de corriger ou d'améliorer le temps de traitement.
Car l'acheteur attend et pire, pense que notre plateforme de paiement est lente!
Dans le Back Office, pour chaque paiement, nous mettons à jour l'historique des événements.
Pour chaque appel à l'URL de notification, nous indiquons l'heure d'appel et le temps de traitement sur VOTRE serveur. Pas sur le nôtre.
Nous gardons aussi en mémoire les 150 premiers octets que le traitement de l'URL écrit sur le socket.
Nos modules open source essayent d'écrire un message intelligible.
Pour les implémentations propriétaires, nous recommandons d'écrire aussi un message de bonne ou mauvaise fin du traitement.
Donc surveillez vos temps de traitement, réduisez les du mieux possible et lorsque vous avez un time-out, cherchez la réponse sur votre serveur! Le support de la plateforme de paiement ne peut rien faire pour améliorer vos temps de traitement. Dans le cas de plug-ins open source, nous ne sommes pas responsables des temps de traitement de votre serveur. Cherchez le coupable chez un module tiers et surveillez l'impact de chaque modification de votre côté. Cela s'appelle faire de la gestion du changement.