Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Processing payment puis rien #97

Open
julienwmx opened this issue Jun 7, 2019 · 8 comments
Open

Processing payment puis rien #97

julienwmx opened this issue Jun 7, 2019 · 8 comments

Comments

@julienwmx
Copy link

Bonjour

Passage d'un site PS 1.6 (ou tout fonctionnait correctement avec ce module depuis des années), update nouveau site sous PS 1.7, installation du nouveau module Tggatos et configuration comme l'ancien

Cela fonctionne, en allant sur le site de la banque, puis le 3DS, au retour sur le site j'ai la page "Processing payment
We are currently processing your payment. It may take a few moments, you can wait here or close this page and wait for our order confirmation email."
Sur l'URL /modules/tggatos/autodispatch/userreturn.pub.php?DATA=202 .....

Il ne se passe rien, la commande ne passe pas en back office (mais le paiement arrive bien en banque)

Dans les logs du serveur j'ai :

PHP Fatal error: Uncaught Exception: TggAtos::decodeCaddieField: cannot json decode caddie field: in /home/ ... /modules/tggatos/tggatos.php:735\nStack trace:\n#0 /home/ ... /modules/tggatos/tggatos.php(799): TggAtos->decodeCaddieField('', NULL)\n#1 /home/ ... /modules/tggatos/controllers/front/ajax.php(47): TggAtos->processResponse(Object(TggAtosModuleResponseObject))\n#2 /home/ ... /classes/controller/Controller.php(281): TggAtosAjaxModuleFrontController->initContent()\n#3 /home/ ... /classes/Dispatcher.php(511): ControllerCore->run()\n#4 /home/ ... /index.php(28): DispatcherCore->dispatch()\n#5 {main}\n thrown in /home/ ... /modules/tggatos/tggatos.php on line 735, referer: https:// ... /modules/tggatos/autodispatch/userreturn.pub.php?DATA=202035

Une idée ?
Config Php ? autre ?

Merci d'avance

@TrogloGeek
Copy link
Owner

Je viens de revoir le code, et cela doit venir du fait que vous utilisez l'option de retour forcé de l'utilisateur vers la boutique, hors de ce que je viens de relire j'ai brisé le support de cette option lors du portage PrestaShop 1.7 en stockant le code ISO-A de devise dans le champ caddie hors ce champs n'est pas disponible en mode retour forcé. Le problème étant que SIPS fonctionne en code ISO-N pour les devises alors que PrestaShop 1.7 (du moins les versions que j'ai étudiées pour la version 5 du module) a abandonné l'ISO-N pour ne conserver que l'ISO-A, je dois donc d'une manière ou d'une autre véhiculer la devise d'une manière compréhensible par PrestaShop dans les mises en paiement SIPS (sans cela, l'utilisateur pourrait modifier la devise associée au panier sur un onglet alors qu'il est parti en paiement sur un autre onglet).

@antoineguilbert
Copy link

Même problème de mon côté avec la même erreur sur le retour de banque forcé. Une solution possible ?

@TrogloGeek
Copy link
Owner

Oui : pour l'instant désactiver le retour forcé qui n'est pas supportable en l'état actuel, il va falloir que je trouve une autre solution pour mémoriser la devise.

@julienwmx
Copy link
Author

Top merci pour l'info :)

J'ai testé et ça fonctionne maintenant !

@julienwmx
Copy link
Author

Bonjour

Avez-vous eu l'occasion de creuser ce problème ?
Car en fait, supprimer le retour forcer fait que l'on ne voit pas passer les commandes des clients qui ne cliquent pas sur le bouton "retourner sur la boutique" après le paiement
Donc la commande n'est pas générée dans le BO PS, les mails ne sont pas envoyés ...

Merci d'avance

@TrogloGeek
Copy link
Owner

TrogloGeek commented Sep 20, 2019

Bonjour, je dois avouer que j'avais complètement occulté ce topic, n'utilisant pas ce module et n'ayant aucun client qui l'utilise je ne fais que du support fin de vie, mais j'aimerais bien régler ce problème toutefois je ne saurais dire quand j'en aurai le temps/courage.
Cela dit vous ne devriez pas avoir à forcer le retour client (je suis personnellement d'ailleurs plutôt contré l'utilisation de cette option), cela signifie que vous avez un soucis dans le traitement de la réponse silencieuse du serveur, généralement à cause d'une redirection forcée https ou d'un filtrage de requête (par exemple OVH bloque les réponses silencieuses parce qu'elles ne contiennent pas d'en tête User-Agent).
Il vous faudrait investiguer sur ce traitement de réponse silencieuse.

@cibles
Copy link

cibles commented Sep 20, 2019

Atos SIPS c'est vraiment pas terrible, en fait. Même les mails récapitulatifs qu'ils envoient sont mal configurés. Beaucoup de serveurs, du coup, ne les acceptent pas.

@julienwmx
Copy link
Author

Bonjour, je dois avouer que j'avais complètement occulté ce topic, n'utilisant pas ce module et n'ayant aucun client qui l'utilise je ne fais que du support fin de vie, mais j'aimerais bien régler ce problème toutefois je ne saurais dire quand j'en aurai le temps/courage.
Cela dit vous ne devriez pas avoir à forcer le retour client (je suis personnellement d'ailleurs plutôt contré l'utilisation de cette option), cela signifie que vous avez un soucis dans le traitement de la réponse silencieuse du serveur, généralement à cause d'une redirection forcée https ou d'un filtrage de requête (par exemple OVH bloque les réponses silencieuses parce qu'elles ne contiennent pas d'en tête User-Agent).
Il vous faudrait investiguer sur ce traitement de réponse silencieuse.

Quel module utiliser pour éviter ça alors ? Toutes nos commandes ne sont pas validées dans le BO, du coup soit on attend que le client rale pour s'en rendre compte, soit on check le compte bancaire voir si il y a des transactions réalisées et ensuite on va rechercher le panier en cours pour le valider en commande :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants