Statut commande reste inchangé après paiement CB

  • Posts: 93
  • Thank you received: 4
  • Hikamarket Multivendor Hikaserial Standard Hikashop Business
1 month 5 days ago #364543

-- HikaShop version -- : 5.1.1
-- Joomla version -- : 5.2.1
-- PHP version -- : 8.3.13

Bonsoir,

J'ai un GROS souci... et c'est plutôt urgent...

Suite à la migration de Joomla 4 vers Joomla 5 (avec changement de serveur), les statuts de commandes restent en "créés" et ne changent pas en "Confirmés" après que le paiement par carte bancaire ai été effectué par le client et validé par la banque.
Le souci est que les clients ne reçoivent pas leurs bons cadeaux...

Tout fonctionnait bien sous J4...

Je ne sais pas par où commencer...

Info complémentaires :
Hikamarket 5.0.0 (mis à jour après migration vers J5)
Hikaserial 5.0.0
Plugin de paiement bancaire : HikaShop Atos SIPS V2 payment
Version BDD 8.0.36 (Tables checkées - Tout semble OK)


Merci d'avance pour votre aide

Please Log in or Create an account to join the conversation.

  • Posts: 83024
  • Thank you received: 13403
  • MODERATOR
1 month 5 days ago #364544

Bonjour,

La première chose à faire, c'est d'activer l'option "debug" de votre méthode de paiement dans le menu Système>Méthodes de paiement.
Ensuite, attendez le prochain paiement, et allez dans la configuration HikaShop et utilisez le bouton de l'option "payment log file" dans la section "Files" pour accéder aux informations de débug.
Normalement, vous aurez les informations envoyées par le plugin après une ligne "Data sent to Atos Sips:".
Et après la ligne ""Data recieved from Worldline SIPS:" vous aurez les informations reçues par le plugin suite au paiement.
Il est possible que vous ayez ensuite des messages d'erreur pointant le problème.
Par exemple, si vous avez le message "status already there !", alors cela indique que l'option "status vérifié" dans la méthode de paiement est sur "créée" au lieu d'être sur "confirmée" et donc le plugin n'a rien à faire car le statut de la commande est déjà celui demandé dans les options de la méthode de paiement.
Il est aussi possible que vous n'ayez pas de messages d'erreur ensuite. Normalement, dans ce cas cela veut dire que le plugin a donné la main à HikaShop pour la confirmation de la commande. Et si le statut de commande reste inchangé, cela indique qu'il y a dû y avoir une erreur PHP suite à cela. Dans ce cas, vous voulez regarder le log d'erreur PHP du serveur qui devrait contenir un message d'erreur fatal pointant l'endroit où le problème est. Cela pourrait être un plugin qui n'a pas été mis à jour, un vieil override d'email, etc.
Il est aussi possible que vous n'ayez pas du tout de ligne "Data sent to Atos Sips:". Là, cela signifie soit que la notification de paiement en provenance du serveur d'ATOS SIPS n'arrive pas jusqu'au plugin. Et dans ce cas, c'est plus coton pour trouver le problème. Soit c'est un plugin système qui bug, soit la requête n'arrive même pas jusqu'au site web et est bloquée par quelque chose au niveau de l'hébergement.

Please Log in or Create an account to join the conversation.

  • Posts: 93
  • Thank you received: 4
  • Hikamarket Multivendor Hikaserial Standard Hikashop Business
1 month 4 days ago #364554

Bonjour et merci pour votre réponse ultra rapide :)

Option debug de Paiement activéé et checkée après une commande payée.
Pas de message d'erreur et pas de "status already there !"

La transaction contient bien :
Data sent to Atos Sips:

Et fini par :
Data recieved from Worldline SIPS :
11.20.24 09:59:53 - atossips
Transaction Result :
Response from Worldline SIPS Transaction approved or processed successfully
/Worldline SIPS authorisation Id :XXXX

Donc je me suis tourné vers l'error log, et là je suis tombé sur ces lignes :
[Wed Nov 20 10:59:20.107306 2024] [authz_core:error] [pid 1282231:tid 1282265] [client 193.56.46.18:0] AH01630: client denied by server configuration: /home/XXXXXX/www/index.php

L'IP 193.56.46.18.0 est l'IP indiquée dans chaque commande confirmée (avant le transfert) (voir pièce jointe).

J'imagine donc que c'est l'IP de retour de la banque qui ne peut donc pas confirmer le paiement et que le souci vient de là.
Vous en pensez quoi ?

Donc, j'ai checké AdminTools, mais cette IP semble ne pas être bloquée à ce niveau là.
J'ai désactivée l'option "Redirect index.php to the site's root" au cas où, mais je ne suis pas sûr que cela serve à quelque chose.

Je vais donc demander à mon hébergeur si il y a quelque chose à faire au niveau serveur.

Please Log in or Create an account to join the conversation.

  • Posts: 93
  • Thank you received: 4
  • Hikamarket Multivendor Hikaserial Standard Hikashop Business
1 month 4 days ago #364555

La pièce jointe B)

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 93
  • Thank you received: 4
  • Hikamarket Multivendor Hikaserial Standard Hikashop Business
1 month 4 days ago #364563

Bon, voici la réponse de mon hébergeur :

"Le serveur renvoi donc une erreur 403 (forbidden) lors de l'appel. La 403 peut être émise par une configuration serveur ou par votre application web. Dans le cas présent, elle est renvoyée par le serveur à cause de la configuration présente dans le fichier /home/XXX/www/.htaccess."

voici le type de ligne rencontré dans les access log
193.56.46.18, 193.56.46.18 - - [20/Nov/2024:14:28:38 +0100] "POST /index.php?option=com_hikashop&ctrl=checkout&task=notify¬if_payment=atossips&tmpl=component&lang=fr&Itemid=1019 HTTP/1.1" 403 199 "-" "Java/1.8.0_412"

Du coup, comme le HTACCESS est généré via Admin Tools, j'imagine que c'est un problème de config dans Admin Tools, mais quoi ? Je ne vois pas quoi modifier :/

Vous n'avez jamais rencontré ce type de souci avec Admin Tools ?

Please Log in or Create an account to join the conversation.

  • Posts: 83024
  • Thank you received: 13403
  • MODERATOR
1 month 4 days ago #364561

Bonjour,

Alors, l'erreur "AH01630: client denied by server configuration" pointe en effet vers une configuration serveur qui bloquerait l'adresse IP:
stackoverflow.com/questions/18392741/apa...server-configuration
Cependant, si c'est le cas, alors le log de paiement d'HikaShop ne devrait pas contenir le "Data recieved from Worldline SIPS" ni le "Transaction Result" car le serveur bloquerait le serveur de PayBox avant d'arriver à HikaShop.
Donc, il y a quelque chose qui n'est pas logique entre les deux logs.

Je ne suis malheureusement pas familier de Admin Tools. Peut être une copie du contenu de votre .htaccess permettrait d'y voir plus clair ?

Aussi, l'erreur "AH01630: client denied by server configuration" vient du log d'accès ou du log d'erreur d'apache, pas du log d'erreur de PHP. Je vous recommande plutôt de regarder le log d'erreur PHP pour chercher des messages avec le texte "Fatal error".

Last edit: 1 month 4 days ago by nicolas.
The following user(s) said Thank You: antidotcom

Please Log in or Create an account to join the conversation.

  • Posts: 93
  • Thank you received: 4
  • Hikamarket Multivendor Hikaserial Standard Hikashop Business
1 month 4 days ago #364565

Bonsoir Nicolas,

J'ai finalement résolu le problème grâce à vous et à mon hébergeur :)

Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403.

La Solution :
Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java".
Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java"
Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess.

Voilà,
Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :)

Encore merci pour votre aide

Bonne soirée

The following user(s) said Thank You: Philip

Please Log in or Create an account to join the conversation.

Time to create page: 0.067 seconds
Powered by Kunena Forum