Atos - Commandes encaissées et non enregistrées, Cela arrive de temps de temps en temps ... |
Bienvenue invité ( Connexion | Inscription )
Atos - Commandes encaissées et non enregistrées, Cela arrive de temps de temps en temps ... |
14 Mar 2006, 14:26
Message
#1
|
|
Ceinture jaune OSC Groupe : Membres Messages : 59 Inscrit : 5-April 05 Membre no 5384 |
Bonjour,
Je me permets de revenir sur ce point car j'ai approfondi ce probléme. Rappel du probléme : Avec ATOS, certaine commande sont bien validée par le systéme bancaire, mais pas sur le site. Elle reste donc dans le panier. C'est penible, car cela oblige à bien surveiller que chaque transaction bancaire est bien aussi présente dans l'admin du site. Et dans le cas contraire, retrouver le panier non validé dans le site et le validé par un systéme manuel tel que celui proposé par IndiaStarker (que je remerci au passage). Personne n'a apparament trouvé de véritables solutions Pour ma part, j'ai appelé ATOS et en regardant leur log, il me dise que cela vient du fait qu'au moment de la transaction bancaire leur systéme n'arrive pas a acceder à ma page "checkout_process.php". Mais à ce moment mon site était bien disponible (mes logs à l'apui ...) Et en plus il me dise qu'il y a 3 tentatives de 10 secondes. Et en gros, il me dise que c'est comme ça et qu'on peut rien faire ... Je sais qu'on est plusieurs à avoir ce probléme, - Etes vous vous aussi chez OVH ? - Avez vous trouvez une vrai solution ? - Je pense que je vais faire un recommandé à ATOS car je ne vois pas pourquoi il n'arrive pas à acceder à mon serveur alors qu'il y d'autres connections au même moment. On les paye pour assurer un service... Je vous tiendrai au courant de mes avancées ... Ma config: - Cyberplus Atos5.0 - OVH MediaPlan - MS2 -------------------- MS2 - QTPRO 4.2 - Ezier New Fields - featured_products - WYSIWYG_v1.8FR - Contre-remboursement - 3_Sizes_of_product_images_Update - visible_countries_1.1b - products_on_order1.2 - Cyberplus Atos5.0 - Header Tag
|
|
5 Apr 2007, 12:41
Message
#2
|
|
Ceinture jaune OSC Groupe : Membres Messages : 76 Inscrit : 23-March 04 Lieu : PARIS Membre no 2171 |
Salut a tous,
J'ai moi aussi des problemes avec des commandes non enregistrées dans l'admin mais belle et bien payées. - J'ai mis NON SSL dans l'url de retour automatique (fichier (includes/modules/paiment/atos.php CODE $command .= " " . $this->os_info['quote'] . "automatic_response_url=" . tep_href_link(FILENAME_CHECKOUT_PROCESS, tep_session_name() . '=' . tep_session_id(), 'NONSSL', false) . $this->os_info['quote']; - J'ai vérifier l'histoire des cgv qu'il faut valider mais c'est commenté chez moi dans checkout_process ( CODE // check for terms and conditions agreement // if ($HTTP_POST_VARS['agree'] != 'true') { // tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, 'error_message=' . urlencode(ERROR_NO_CONDITIONS), 'SSL')); // } - J'ai augmenter le temps de session dans le fichier funtions/sessions.php Chercher : CODE if (!$SESS_LIFE = get_cfg_var('session.gc_maxlifetime')) { $SESS_LIFE = 1440; } rempalcer par : CODE if (defined('DIR_WS_ADMIN')) { if (!$SESS_LIFE = (SESSION_TIMEOUT_ADMIN + 900)) { $SESS_LIFE = (SESSION_TIMEOUT_ADMIN + 900); } } else { if (!$SESS_LIFE = get_cfg_var('session.gc_maxlifetime')) { $SESS_LIFE = 1440; } } - et enfin j'ai mis en place une astuce que j'ai trouvé pour pouvoir laisser "Utilisation de force des cookies" à TRUE j'ai dupliqué le fichier application_top.php en l'appelant application_top_hsbc.php (c'est la banque) et j'ai virer les ligne concernant la vérif des cookies. Mon fichier checkout_process.php fait appel à application_top_hsbc.php au lieu de application_top.php Remplacer : CODE if (SESSION_FORCE_COOKIE_USE == 'True') { tep_setcookie('cookie_test', 'please_accept_for_session', time()+60*60*24*30, $cookie_path, $cookie_domain); if (isset($HTTP_COOKIE_VARS['cookie_test'])) { tep_session_start(); $session_started = true; } } elseif (SESSION_BLOCK_SPIDERS == 'True') { Par : CODE if (SESSION_BLOCK_SPIDERS == 'True') { Mais j'ai encore quelques soucis de commande non enregistrées. Je suis sur une creload que je modifie depuis 2 ans (multistore, yazu, etc ...) sur un serveur dédiée chez OVH. En épluchant les log je ne trouve aucune trace de retour de la réponse automatique checkout_process sur les commandes qui posent propblèmes, ATOS me dis qu'ils ont une réponse 200 OK ce qui signifie que pour eux mon serveur leur a répondu que c'etait bon. Je pense donc que le probleme vient d'une erreur dans le fichier checkout_process, cad une vérification qui provoque une erreur quand la requete vient de chez atos. C'était le cas avec les cookies, cad quand ATOS interoge checkout_process.php il essaie de lui coller un cookie, chose que le servuer ATOS refuse, donc erreur. Sur ce principe j'ai epluché le checkout_process, mais je ne vois pas d'autre chose dans ce genre qui pourrai provoquer une erreur. Quelques pistes : CODE if (!tep_session_is_registered('customer_id')) { $navigation->set_snapshot(array('mode' => 'SSL', 'page' => FILENAME_CHECKOUT_PAYMENT)); tep_redirect(tep_href_link(FILENAME_LOGIN, '', 'SSL')); } Ce code vérifie si on a bien récupérer la session et qu'on a bien le client, normalement c'est dans application_top.php que cela se fait et vu que l'url de retour automatique d'ATOS passe en parametre le session id je pense que c'ets OK. CODE if (!tep_session_is_registered('sendto')) { tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL')); } Ca je sais pas ce que ca fait ???? si quelqu'un a une idée ... d'apres moi ca vérifie si l'info de session "sendto" est enregistrée en session, sinon ca redirige vers FILENAME_CHECKOUT_PAYMENT mais je sais pas à quoi correspond "sendto". CODE if ((tep_not_null(MODULE_PAYMENT_INSTALLED)) && (!tep_session_is_registered('payment'))) { tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL')); } Ce code vérifie si le moyen de paiement est bien enregistré dans les infos de sessions sinon erreur CODE // avoid hack attempts during the checkout procedure by checking the internal cartID if (isset($cart->cartID) && tep_session_is_registered('cartID')) { if ($cart->cartID != $cartID) { tep_redirect(tep_href_link(FILENAME_CHECKOUT_SHIPPING, '', 'SSL')); } } Ici on vérifie que le caddie en session est bien le meme que le caddie pour eviter qu'on puisse ajouter des produits en simulant une fausse adresse de retour. Je ne suis pas un génie du php donc peu etre que je me trompe, n'hésitez pas à me corriger. J'espère que cela pourra aider certains et que certains pourront m'aider A+ Ce message a été modifié par web_addict - 5 Apr 2007, 13:13. -------------------- Le futur est à l'open source
------------------------------------------------ CRELOAD 6 avec tous les patchs + multi store + CIC + pas mal de modifs à la main |
|
Version bas débit | Nous sommes le : 29th March 2024 - 15:15 |
Ce site est déclaré auprès de la commision Nationale de l'Informatique et des Libertés (déclaration n°: 1043896) |