Redirection vers Historique de commande selon la langue

[Seta-san]

Bonsoir,

 

J'ai customisé le module ATOS pour que les paiements en livres sterling soient enregistrés sur une banque à Londres.

En gros, pour basculer d'une banque à l'autre selon la devise.

Jusque la pas de problèmes les paiements sont bien enregistrés et les alertes reçues.

 

Cependant, les commandes ne sont, malgré tout, pas enregistrées quand on reçoit le retour du module de la banque.

Quand je fais un paiement en FR ou autre l'enregistrement est pris en compte, mais pas en GB. Les clients sont immédiatement redirigés vers l'historique de commande (vide).

 

Les variables envoyées et les variables de retour sont correctes et identiques peut importe la langue.

 

Voici un petit bout du fichier log concerné

 

Paiement GB

1 "GET /shop/gb/confirmation-commande?id_cart=18420&id_module=200&key=36c357639f6a24dff501a29bd3e2dd0b HTTP/1.1" 302 339 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0"


2 "GET /shop/gb/historique-des-commandes HTTP/1.1" 200 7797 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0"

Ce que je vois :

 

En GB, à réception des variables de confirmation de paiement, le serveur fait une redirection 302 vers l'historique de commande. puis rien.

 

 

 

Paiement FR ou autre

1 "GET /shop/fr/confirmation-commande?id_cart=18420&id_module=200&key=36c357639f6a24dff501a29bd3e2dd0b HTTP/1.1" 200 8219 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0"


2 "GET /shop/themes/alysum/cache/v_224_d88a23f0813338d1c6e24f0320c07321_all.css HTTP/1.1" 200 97265 "http://www.*****.com/shop/fr/confirmation-commande?id_cart=18420&id_module=200&key=36c357639f6a24dff501a29bd3e2dd0b" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0"


3 "GET /shop/themes/alysum/cache/v_41_d4423df0a982b48bb243d3c2d5522599.js HTTP/1.1" 200 122017 "http://www.*****.com/shop/fr/confirmation-commande?id_cart=18420&id_module=200&key=36c357639f6a24dff501a29bd3e2dd0b" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0"


4 "GET /shop/admin5089/index.php?controller=AdminOrders&token=0ce089ee209840eb1578d4ffdab81353 HTTP/1.1" 200 21840 "http://www.*****.com/shop/admin5089/index.php?controller=AdminOrders&token=0ce089ee209840eb1578d4ffdab81353" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0"


5 "GET /shop/admin5089/index.php?controller=AdminStats&token=99875cc3c2fc6070ca7ceb24ea720cbe&ajax=1&action=getKpi&kpi=abandoned_cart&rand=1494423351133&_=1494423351034 HTTP/1.1" 200 751 "http://www.*****.com/shop/admin5089/index.php?controller=AdminOrders&token=0ce089ee209840eb1578d4ffdab81353" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0"


6 etc....

Ce que je vois :

En FR le serveur laisse passer (200) et termine le processus.

 

Ma question est donc la suivante :

Dans quel cas le serveur pourrait faire une redirection 302 vers l'historique de commande juste après un paiement?

Qu'est ce qui lui est demandé exactement pour qu'il réponde soit 302 ou soit 200

 

Merci d'avance pour vos réponses qui j’espère vont pouvoir me guider.

 

 

[doekia]

N'étant pas la même banque (j'ai du mas a comprendre comment tu as fait ça d'ailleurs), ce ne sont sûrement pas les même certificats à utiliser. le certificat (hash) de la transaction étant invalide, l'url retour renvoie une erreur et ne valide pas la commande

[Seta-san]

Merci pour votre retour.

Le certificat change automatiquement pour l'autre banque. Ce n'est pas le même celui du FR qui est traité mais celui fournis pas la banque à Londres. Le hash correspond bien au paramètres envoyés.

Edited May 10, 2017 by Seta-san (see edit history)

[doekia]

Donc tu as modifié ton validation.php pour utiliser le certificat associé dans le cas du paiement de la banque de londres

[Seta-san]

J'ai apporter des modifications dynamiques sur les fichiers validation.php, atos.php, et ajouté des éléments dans la base de données pour y insérer les informations relatives à tout ca. Notamment le 2eme marchand_id. Ca permet au module de piocher le bon certificat avec les bonnes informations. Si les informations ne correspondent pas au hash du certificat, il ne sera pas possible d'envoyer la demande de paiement à la banque. Ca bloque dès le départ.

 

Dans mon cas l'acheminement et la transaction se font correctement.

 

Je me demande si je n'ai pas simplement oublié d'activer quelque chose en rapport avec la langue dans le backoffice (pas trouvé).

[doekia]

sachant que validation.php n'est utilisé que pendant la notification bancaire - ce n'est pas "bloqué dès le départ"

ce sont tes modifs qui déconnent, celle de validation.php qui doit astucer pour reconnaitre la langue puisque celle-ci est en gros ... inexistante pendant ce code

l'url de notif est /shop/modules/atos/validation.php

[Seta-san]

Atos bloque dès le départ la possibilité de payer si la langue et le marchand ID ne correspondent pas au certificat.

Pour la langue dans validation, je l'a récupère grâce à une variable de session qui est défini avant l'acte d'achat. Elle me sert essentiellement à récupérer le bon marchand ID pour la ligne qui en a besoin.

 

Je vais faire un test pour voir ce que la variable "$result" contient dans validation.php après un paiement. J'y trouverais peut être l'anomalie.

[doekia]

J'ai l'impression que tu ne comprends pas la différence entre la soumission et la notification serveur.

Le serveur de la banque appelle ton validation.php (en POST normalement), il n'y a pas de langue sur le backend de la banque, as-tu modifié ton code validation pour switcher de certificat lors de la notification serveur, si oui comment, vérifie que tu ne te soit pas trompé.

 

Quelle version/developpeur de ton atos utilises-tu au départ (avant modif) ?

 

Dans le module atos officiel, validation.php utilise ATOS_MERCHANT_ID pour identifier le fichier parmcom.xxxxxxx à utiliser, comment as tu fait pour détecter l'origine UK et le switch de la valeur ?

[Seta-san]

Bonsoir,

 

Je comprend la différence entre soumission et notification.

Le problème ne vient pas de validation.php

La version d'Atos utilisée est la v3.1.3

 

Pour basculer sur le bon certificat.005 ou le bon parcom.005... j'utilise des variables de sessions que je définis quand le fichier atos.php est chargé par le client.
Je récupère la langue dans l'url et si je trouve GB je rempli mes variables d'un suffix "_gb".

 

Par exemple :

$merchant_id = Configuration::get('ATOS_MERCHANT_ID');

devient

$merchant_id = Configuration::get('ATOS_MERCHANT_ID'.$_SESSION['suffix_gb']);

Ce qui me permet, si je détecte la langue, de récupérer le bon marchand_id dans la base de données ou j'ai préalablement ajouté un champ nommé ATOS_MERCHANT_ID_GB.

Même principe pour le certificat. certif.fr.1111 en certif.en.2222

 

Ma variable $parm finale contient la bonne configuration:

 

Exemple  pour la premiere banque fr

PARM: 
merchant_id=001XXXXXXXXXX 
language=fr 
customer_id=XXXX 
[email protected] 
caddie=12730 
merchant_country=fr 
amount=101 
currency_code=826 
capture_day=0 
capture_mode=AUTHOR_CAPTURE 
pathfile="/var/www/public_html/shop/modules/atos/pathfile" 
normal_return_url="http://www.XXX.com/shop/fr/module/atos/orderconfirmation?id_cart=12730&id_module=200&secure_key=2621ed0f002a4800c3e313ea94a83c92" 
cancel_return_url="http://www.XXX.com/shop/modules/atos/atos_return.php" 
automatic_response_url="http://www.XXX.com/shop/fr/module/atos/validation" 
customer_ip_address=109.xxx.93.xxx 
data="NO_RESPONSE_PAGE_POST=http://www.XXX.com/shop/fr/module/atos/orderconfirmation?id_cart=12730&id_module=200&secure_key=2621ed0f002a4800c3e313ea94a83c92\;" 

Pour la deuxième gb :

PARM: 
merchant_id=0002XXXXXXXXXX 
language=gb 
customer_id=XXXX 
[email protected] 
caddie=12730 
merchant_country=en 
amount=101 
currency_code=826 
capture_day=0 
capture_mode=AUTHOR_CAPTURE 
pathfile="/var/www/public_html/shop/modules/atos/pathfile" 
normal_return_url="http://www.XXX.com/shop/gb/module/atos/orderconfirmation?id_cart=12730&id_module=200&secure_key=2621ed0f002a4800c3e313ea94a83c92" 
cancel_return_url="http://www.XXX.com/shop/modules/atos/atos_return.php" 
automatic_response_url="http://www.XXX.com/shop/gb/module/atos/validation" 
customer_ip_address=109.xxx.93.xxx 
data="NO_RESPONSE_PAGE_POST=http://www.XXX.com/shop/gb/module/atos/orderconfirmation?id_cart=12730&id_module=200&secure_key=2621ed0f002a4800c3e313ea94a83c92\;" 

La bonne banque est appelée et le paiement se fait correctement.

Elle redirige le client vers le bon "normal_return_url", mais comme vous pouvez le voir dans les logs, le site redirige immédiatement le client vers l'historique de commande qui est, bien entendu, vide.

 

La banque indique que le serveur lui renvoi une réponse 200.

 

Il faudrait que j'arrive à définir dans quelle fichier et a quelle ligne, la boutique effectue son contrôle avant de faire l'enregistrement de la commande ou non.
Ca me permettrait peut être de comprendre les critères de validation et de les comparer avec ce qu'il reçoit par la première banque et la deuxième.

Edited May 18, 2017 by Seta-san (see edit history)

[doekia]

la automatic_response_url est appelée par le serveur de la banque qui n'a bien sur pas de SESSION.
cette url http://www.XXX.com/shop/gb/module/atos/validation passe au travers du Dispatcher qui la reconnait et la converti en /modules/atos/validation.php
La langue à ce moment là, est très probablement encore PS_LANG_DEFAULT (config.inc.php)
L'url existe, et le validation.php existe. Le code de retour est donc 200, mais la commande ne s'est pas validé car validation.php a considéré la DATA invalide
Je pense que ton problème est là.
 
 
Capture le retour complet de la banque et rejoue le scénario en mettant des break point au fûr et à mesure des étape.
Tu dois finir par arriver dans PaymentModule::validateOrder() si et seulement si le handshake avec la banque fonctionne.

 

Quand le client à payé, le serveur de la banque valide, et le navigateur de l'internaute revient avec l'url http://www.XXX.com/shop/gb/module/atos/orderconfirmation?id_cart=12730&id_module=200&secure_key=2621ed0f002a4800c3e313ea94a83c92 mais il n'a pas le pouvoir lui de valider le paiement. Ce serait trop facile de trafiquer le contenu pour prétendre avoir payé