Version imprimable du sujet

Cliquez ici pour voir ce sujet dans son format original

Forum osCommerce-fr _ Modules de Paiement et de Livraison _ Atos - Commandes encaissées et non enregistrées

Écrit par : fdj 14 Mar 2006, 14:26

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 http://www.oscommerce-fr.info/forum/index.php?showtopic=28229&hl=
(que je remerci au passage).
Personne n'a apparament trouvé de véritables solutions sad.gif sad.gif

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 ... blink.gif

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

Écrit par : xavkick 15 Mar 2006, 03:18

salut,

j'ai exactement le même soucis que toi et bizarement la même config.
Je suis chez OVH avec un media plan

Nous venons de changer d'hébergement car nous pensons que cela ne peut venir que du temps de réponse de chez OVH qui des fois est tres lent.
Pendant ces 5 derniers jours mon problème s'est accentué.

J'ai donc installé la même boutique schez icodia.
Donc nous pourrons voir si cela vient de hcez OVH.

xav

Écrit par : fdj 15 Mar 2006, 09:11

OK, trés bien on se tient au courant.


Oui, ca peux venir du media plan qui parfois est un peux lent.

Perso,
Toute la période de Noel s'est bien passer alors que le site a connu une grosse activité.

Début fevrier, quelques commande perdu,
Mais ce 13 mars au matin, 4 commandes coup sur coup, et la ce n'est plus gérable ....


Je vais appeller OVh voir ce qu'il en pense.

A trés bientôt


Écrit par : manmachine 15 Mar 2006, 17:01

Avant de taper sur votre hébergeur , comment avez vous configuré le retour vers votre boutique ?

C'est une requete automatique via socket ou le client doit appuyer su un bouton " retour boutique " ?

Écrit par : xaglo 15 Mar 2006, 17:51

non manmachine, je te rejoins que cela ne sert à rien de dauber son hébergeur et qu'il vaut mieux essayer de trouver la solution avec lui. Mais il y a effectivement (du moins il y a eu) un soucis ATOS <-> OVH

Tu connais ATOS, c'est une requête automatique qui permet la mise à jour panier. J'ai aussi eu des soucis de mise à jour: vendredi dernier, 5 transactions sur 5 non mises à jour et 3 sur 6 samedi.

Je suis aussi en contact avec eux

à suivre

Écrit par : Gnidhal 15 Mar 2006, 21:00

Bonjour xaglo wink.gif
J'interviens dans ce post car ces problèmes sont peut-être à rapprocher des soucis FTP d'OVH.
Pour info le message d'Octave (OVH) sur la mailing-list"Hosting" qui est le dernier en date d'une série sur la semaine : (reproduit ici car cette liste est ouverte sur abo)

CITATION
Bonjour,
D'après les messages de nos clients et suite aux modifications de cette nuit, le fonctionnement a été à nouveau correct pour l'ensemble des clients. C'est à dire que le probleme est lié à la configuration des liaisons ADSL chez certains fournisseurs d'accès. En gros, même si MTU est officielement 1500, le packet passe par des liaisons ADSL/LNS où ce MTU n'est pas de 1500. Normalement, il n'y a pas de probleme, mais pour une raison qu'on ne connait pas, dans ce cas là le packet devient "failed". Nous avons donc forcé la longeur de packets sur les serveurs FTP à 900 (oui très très bas) ce qui permet au packet de passer par tous les reseaux ADSL/IP/LNS sans devoir d'être decoupé (il passe entierement). Et là ça fonctionne correctement.
.../...


J'en tire que si les paquets sont trop gros, ya un problème de transfert. Ce soucis posé pour le FTP peut très bien s'étendre à d'autres services si le problème est généré par un routeur par exemple. (déduction perso)

Donc si ya pb, OVH travaille dessus.
Et c'est tant mieux! smile.gif

Cela dit, vous pouvez contacter Octave au travers de la mailing-list "Hosting" (voir les modalités d'abo sur le site OVH) pour lui faire part de ces malfonctions. Elles ont peut-être un rapport.

Écrit par : xaglo 15 Mar 2006, 22:19

oui, je suis aussi abonné à la mailing liste mais je n'avais pas vu de rapprochement possible. Je vais essayer de les relancer de ce coté là aussi.

Coté support rien de concret sad.gif

Écrit par : xaglo 15 Mar 2006, 22:54

par contre, coté réponse la mailing list, impressionnant!!! 6minutes pour répondre à 22h30 chapô

CITATION(xaglo)

Bonjour,
Ces dysfonctionnements pourraient-ils avoir un rapport avec le soucis
qu'à ATOS à se connecter aux serveurs d'OVH?
J'ai une boutique en ligne où je traite le retour ATOS après paiement.
Ce script fonctionne bien dans 99% des cas, seuls quelques rares cas de
retour "failed" seulement. Or vendredi 5 sur 5 paiement n'ont pas été
mis à jour!!! et samedi 3 sur 5.
merci d'avance pour la réponse


CITATION(OVH)
non. on a le même genre des problemes avec atos et d'autres
paiements securisé regulierement.


bien tenté Gnidhal wink.gif

je vous laisse la conclusion de notre échange avec eux:
CITATION(OVH)
atos fait une requete url mais aussi envoit un email. il faut
le parser. nous en plus, on check leur site. bref, 3 checks ...

La réponse ne plaira pas à tous le monde mais au moins ça a le mérite de la franchise:
ATOS n'est pas sûr, rien n'empêchera la multiplication des contrôles

Écrit par : fdj 16 Mar 2006, 10:50

OK, merci, on y voit un peux plus clair (à peine).

Mais, je ne n'ai jamais voulu taper sur mon OVH, ni sur personne d'autres,
je suis àla recherche de la vérité biggrin.gif
je souhaite juste savoir clairement d'ou ça vient (d'ATOS, D'OVH, de la configuration de la boutique, ....) smile.gif

Je ne me satisafait pas de la réponse des techniciens d'ATOS au téléphone qui me disent on a un FAILED lors de l'acces a la page CHECKOUT_SUCCESS (réglé en réponse automatique depuis toujours ...).
Cette tentative d'ATOS d'acces dure 20 secondes (dixit leurs techniciens).

Hors quand je consulte les logs du serveur de ma boutique, le site était bien accessible au moment de ces appels ???
Donc, pourquoi ATOS n'y accederait pas ?

Et Pourquoi de septembre à janvier pas une commande perdu (avec un trés grosse activité en décembre!)
Et alors que c'est un peux plus calme on en perd de plus en plus.

Il y a bien quelque chose qui c'est passé excl.gif
Avec tous les logs que l'on a dans nos systémes informatique on doit bien étre capable de trouver d'ou ca vient.

Perso, je pense que cela vient plus d'ATOS que D'OVH mais j'en suis pas sur.
Je souhaite juste envoyer un recommandé pour la forme à ATOS pour avoir une réponse précise de leur part et pour enclencher un réflexion. Au téléphone, il sont un peux "légers" et donne l'impresion de s'en moquer.

Par contre, si OVH dit que cela vient d'eux :

CITATION

non. on a le même genre des problemes avec atos et d'autres
paiements securisé regulierement
.

ET je n'étais au courant de tout ce processus :
Un mail ? Un retour de OVH ? ATOS ne m'en à jamais parler ?
CITATION
atos fait une requete url mais aussi envoit un email. il faut
le parser. nous en plus, on check leur site. bref, 3 checks ...


Sinon, Est ce que les Boutiques hébérgés chez d'autres hebergeurs qu'OVH ne connaissent pas du tout ce probléme. ??

Jusqu'à présent j'étais trés content d'OVh, mais si le nombre de commandes augmentent encore et que cela se produit de plus en plus, ce ne sera plus gérable.
Je devrais absolument trouver une solution.

Encore merci à vous tous,
JF

Écrit par : xaglo 16 Mar 2006, 11:52

CITATION(fdj @ 16 Mar 2006, 10:50 AM) [snapback]163287[/snapback]
Mais, je ne n'ai jamais voulu taper sur mon OVH, ni sur personne d'autres
Ne le prend pas mal, la remarque de manmachine ne t'était pas adressée, les messages concernés ont été supprimés wink.gif

Sinon, entièrement d'accord avec ton analyse. comme toi je n'ai eu des erreurs de mise à jour que exceptionnellement jusque là. Mais les 100% de vendredi dernier et les 50% de samedi sont difficiles à accepter.

De savoir si cela existe chez d'autres hébergeurs, à la lecture des forums, je pense que l'on peut dire oui. Qu'OVH soit l'hébegeur numéro 1 explique certainement que les critiques se concentrent sur eux.

Personnellement, je trouve un peu "léger" de la part d'ATOS de ne faire la tentative de mise à jour que pendant 20'' de refaire une tentative une heure après ne leur coùterait rien. Mais bon, quand tu vois le dinosaure qu'est ATOS, je crains qu'il faille faire avec... ce serait comme leur demander de nous faire une interface d'administration un peu plus ergonomique que l'horreur qu'il nous proposent laugh.gif

Enfin, pour les réponses de la mailing liste d'OVH, ils ont l'honneteté de nous confirmer ce que l'on craignait déjà: une seule confirmation d'ATOS n'est pas suffisante pour être considérée comme sûre. Sur le fait que les dysfonctionnement anormaux de ces derniers jours soient imputables à eux, ou à ATOS, ou à un problème de liaison ATOS <-> OVH, je crains que l'on ne sache jamais.
CITATION
atos fait une requete url mais aussi envoit un email. il faut
le parser. nous en plus, on check leur site. bref, 3 checks ...

Ils parlent là du mail qu'envoi ATOS

à suivre

Écrit par : fdj 16 Mar 2006, 15:09

CITATION
Mais bon, quand tu vois le dinosaure qu'est ATOS, je crains qu'il faille faire avec... ce serait comme leur demander de nous faire une interface d'administration un peu plus ergonomique que l'horreur qu'il nous proposent


C'est vrai, ça fait longtemps que j'avais pas vu cette admin (je m'occupe pas de la compta ...), mais on pourrait au minimun pouvoir trier les colonnes par dates !!!
Ils doivent bien avoir un ingenieur capable de faire un "order by" biggrin.gif

Et, on pourrait quand même leur mettre un peux la pression car je pense qu'il profitent du monople qu'ils ont et je me demande si c'est bien légal.
Du coup ils font vraiment le service minimun.
Mais, je compte ecrire un POST Ssur ATOS avec quelques anecdotes ....

Pour revenir à notre probléme,
Apparament on est tous toucher en même temps (vendredi et samedi), c'est un PISTE smile.gif .

Vous avez tous des MEDIA PLAN sur OVH ?

Si oui, cela viendrait probablement du serveur OVh,
Si NON cela viendrait plus de chez ATOS.

Et on peut se tenir au courant, si a on un nouveau FAILED.

Écrit par : NuTz 5 Apr 2006, 10:53

Bonjour,

J'ai également ce problème depuis quelques mois, j'ai contacter Atos qui m'a dis comme a tout le monde apparemment: le serveur ne reponds pa a la requete du leur.

J'avais le Mediaplan chez OVH, étant très lent à certains moment, je pensais que ca pouvait etre le problème.
Or je vens de passer sur un serveur dédié avec 100Mbps. Le cas ne se présentais plus jusqu'a hier, 1 commande non validée, et 3 aujourd'hui.

En fouillant j'ai vu un post qui parlait d'une contribution qui permet de ratrapper le coup:
http://www.oscommerce-fr.info/forum/index.php?showtopic=21090&hl=
Ca ne résout pas le problème mais je pense que ca peut etre une bonne alternative.
Au moins on evite de predre des commandes et de se faire une mauvaise publicité.

Je n'ai pas encore testé cette contrib, je pense le faire d'ici peu. Si qq'un l'a deja testé je veux bien connaitre leurs avis.

Écrit par : patv 24 May 2006, 11:40

CITATION(NuTz @ 5 Apr 2006, 11:53) [snapback]168013[/snapback]


Je n'ai pas encore testé cette contrib, je pense le faire d'ici peu. Si qq'un l'a deja testé je veux bien connaitre leurs avis.

Bonjour,

Je viens me rendre compte que je rencontre moi aussi ce problème de transaction enregistrée, mais pas de commande dans l'admin.
C'est en fait un client qui se plaignait de ne pas avoir eu de confirmation de commande qui m'a fait m'en apercevoir (transaction datée du 21/05/06).
Je ne sais pas encore s'il est le seul ou si d'autres commandes sont passées aux oubliettes, il faut maintenant que je me tape toute les transactions sur le serveur ATOS cry.gif
Heureusement que ma boutique n'est en fonctionnement que depuis 10 jours confused.gif
Je suis également intéressé de savoir si quelqu'un a testé la contrib citée ici...

Écrit par : armoise 23 Jun 2006, 22:42

Bonjour à tous,

Merci pour ce post très intéressant car je rencontre ausi ce problème (240 plan ovh)

Des semaines se sont écoulées....

Avez vous résolus ce problème ATOS et de validation des commandes ?

Bien cordialement,

Écrit par : kinesio 28 Jun 2006, 09:30

Bonjour,

Je suis chez OVH mais j'utilise le système de la banque populaire laorraine champagne.
J'ai eu ce problème pendant un moment, il y a logtemps.
J'avais en gros 1 paiement sur 10 qui ne passait pas dans l'admin, heureusement que j'avais la confirmation par mail de la BP pour savoir qu'une transaction était passée.

Voici ce que j'ai fait et je n'ai plus eu le problème, mais j'ai des doutes sur la méthode car ça me paraît trop simple et quand je vois les dinausores de l'informatique qui se sont penchés sur le post, j'ai des doutes sur ma méthode mais bref.

Après avoir parcouru tous les posts, j'avais allongé mon temps de session en le passant à 2400 secondes mais je ne sais plus dans quel fichier.
Et surtout dans l'admin/session tout est sur false.
Ce qui m'a obligé à installer tout l'arsenal ultimate seo etc...

Depuis que tout est sur false, je n'ai plus eu de problèmes et ça depuis au moins 8 mois.

J'espère que ma solution peut-être la votre

Bon courage.

Écrit par : armoise 28 Jun 2006, 16:36

Bonjour Kinesio,

Je travaille avec des cookies ...

Le pbs vient peut être de là. Peut être aussi que les " grosses pointures du forum" wink.gif sont passées à coté d'une chose aussi simple; Ni atos, ni OVh simplement un problème de temps de sessions. Ce qui me semble logique

Proverbe chinois. C'est sous la lampe qu'il fait le moins clair...

Attendons voir les réponses

Écrit par : jolilola 8 Aug 2006, 20:55

Bonjour,

je reviens sur le post car depuis 1 semaine j'ai le même probléme et ce soir je me suis rappelé que j'avais modifier les cookies en le forçant en mettant tru.
je viens de mettre sur false et je vous dit demain si cela a marché...

a plus

Écrit par : oneill 9 Aug 2006, 21:28

Ultimate SEO provoque ce genre de désagrément et pas que chez OVH.
Solution : éviter de rewriter les url de retour.

Écrit par : jolilola 10 Aug 2006, 08:20

Bonjour,

comment fait-on pour ne pas rewriter les url retour?

merci d'avance

Écrit par : oneill 10 Aug 2006, 19:06

CITATION(jolilola @ 10 Aug 2006, 09:20) [snapback]187876[/snapback]

Bonjour,

comment fait-on pour ne pas rewriter les url retour?

merci d'avance


Pour installer Ultimate SEO vous avez modifié la fonction tep_href_link()
CODE
// Ultimate SEO URLs v2.1
// The HTML href link wrapper function
if (SEO_ENABLED == 'true') { //run chemo's code
  function tep_href_link($page = '', $parameters = '', $connection = 'NONSSL', $add_session_id = true, $search_engine_safe = true) {
        global $seo_urls;................

Il suffit donc de récupérer l'ancienne fonction d'origine, de la rebatiser tep_href_link_atos(), de l'ajouter dans html_ouput en plus de celle de SEO et de faire appel à elle dans le module atos au niveau des urls de retour en remplaçant tep_href_link par tep_href_link_atos.

Et hop... !

Écrit par : jolilola 10 Aug 2006, 21:32

merci beaucoup pour l'info.

en attendant j'ai remis sur true la fonction forcer les cokies et cela semble remarcher comme avant...

merci

Écrit par : maxime 18 Aug 2006, 08:25

Bonjour,

Si les sessions étaient en cause, on verrait quand même dans les log d'apache quelle chose comme ça me semble-t-il :

CODE
193.56.46.18    -    -    [05/Jul/2006:19:20:40    +0200]    POST /checkout_process.php?osCsid=291b1d95918ec88df3335f8699092073 HTTP/1.0    302    0    -    -    -


Or chez moi, je n'ai rien de tel lorsque le problème se produit. Il n'y a probablement pas qu'un problème de session avec la solution ATOS cry.gif

Je précise que je ne suis pas chez OVH ...

Écrit par : polo 18 Aug 2006, 10:19

CITATION(kinesio @ 28 Jun 2006, 10:30) [snapback]181823[/snapback]

Bonjour,

Je suis chez OVH mais j'utilise le système de la banque populaire laorraine champagne.
J'ai eu ce problème pendant un moment, il y a logtemps.
J'avais en gros 1 paiement sur 10 qui ne passait pas dans l'admin, heureusement que j'avais la confirmation par mail de la BP pour savoir qu'une transaction était passée.

Voici ce que j'ai fait et je n'ai plus eu le problème, mais j'ai des doutes sur la méthode car ça me paraît trop simple et quand je vois les dinausores de l'informatique qui se sont penchés sur le post, j'ai des doutes sur ma méthode mais bref.

Après avoir parcouru tous les posts, j'avais allongé mon temps de session en le passant à 2400 secondes mais je ne sais plus dans quel fichier.
Et surtout dans l'admin/session tout est sur false.
Ce qui m'a obligé à installer tout l'arsenal ultimate seo etc...

Depuis que tout est sur false, je n'ai plus eu de problèmes et ça depuis au moins 8 mois.

J'espère que ma solution peut-être la votre

Bon courage.



Salut Kinesio !!

Dis moi quand tu dits dans session/admin que tu met tous sur Flase, moi aussi j'ai mis sur False sauf l'option "Récréer une session" est-ce un problème ? cette options sert à quoi ? moi je suis sur serveur dédié OVH sur SPPLUS et j'ai eu également ce même type de soucis , j'ai du installer 2 contrib, une pour reprendre les commande échoué et une autre pour me connecter sur le compte du client.

Voila rolleyes.gif

Écrit par : oneill 18 Aug 2006, 11:50

Il ne faut pas recréer de session (donc on met false) sinon quand on revient de la banque, on ouvre un autre session alors qu'on devrait finir la première.

Écrit par : idachour 7 Dec 2006, 22:18



Salut oneil ,

peux tu me donner plus de precision sur les modif qu'il faut faire sur ce fichier,

ca serais vraiment sympa smile.gif

Écrit par : oneill 7 Dec 2006, 22:36

En fait tu récupères la fonction tep_href_link() d'origine (celle d'avant l'install de SEO) tu la remet en plus de la nouvelle en changeant son nom (tep_href_link_xxx() par exemple ) et il te suffit de l'appeler lorsque tu ne veux pas faire de rewriting comme pour les url de retour du serveur de banque.

Écrit par : idachour 8 Dec 2006, 09:46

Ok o'neil

je vais de suite essayer....

merci cool.gif

Écrit par : idachour 8 Dec 2006, 21:57

CODE
$command .= " " . $this->os_info['quote'] . "normal_return_url=" . tep_href_link_atos('atos_response.php', tep_session_name() . '=' . tep_session_id(), 'SSL', false) . $this->os_info['quote'];
      $command .= " " . $this->os_info['quote'] . "cancel_return_url=" . tep_href_link_atos('atos_response.php', tep_session_name() . '=' . tep_session_id(), 'SSL', false) . $this->os_info['quote'];


Bonsoir O'neil il est 21h52 et je n'ai toujours pas resolu mon pb ( panier qui ne se vide pas et pas d'enregistrement au niveau de l'admin)

j'ai modifié le fichier atos.php à la racine du site comme ci dessus mais j'ai toujours les pb.... please help me !!!

au fait quelque soit la commande et quelque l'acheteur j'ai au niveau du tableau visiteurs :
- l'ip du serveur d'atos 193.56.46.18
- /checkout_process.php?osC
sid=76e60c1c11c205aa8392e
1a9d23c92e7

je suis vraiment pommé et meme en faisant en forcant les cookies ca ne fonctionne pas !!!

cry.gif cry.gif cry.gif cry.gif cry.gif cry.gif

Écrit par : idachour 9 Dec 2006, 08:57



Bonjour a tous ,

je n'ai pas configuré dans mon fichier configure.php les acces en SSL or le fichier Atos.php fait appel à des sessions en SSL ex :

CODE
$command .= " " . $this->os_info['quote'] . "automatic_response_url=" . tep_href_link(FILENAME_CHECKOUT_PROCESS, tep_session_name() . '=' . tep_session_id(), 'SSL', false) . $this->os_info['quote'];

ça pourrait être le probleme !!!

je vais y reflechir dés ce matin dry.gif dry.gif

Écrit par : oneill 9 Dec 2006, 09:27

CODE
    $command .= " " . $this->os_info['quote'] . "automatic_response_url=" . tep_href_link_atos(FILENAME_CHECKOUT_PROCESS, tep_session_name() . '=' . tep_session_id(), 'NONSSL', false) . $this->os_info['quote'];

Essaie plutôt ca sans toucher à ton configure.php

Écrit par : idachour 9 Dec 2006, 14:18

J'ai fait la modif( et sur les autres fichiers et c parei ) je pense que c un pb de session ou de cookies car quand je clique sur un des articles du panier ( qui est plein car il ne se vide pas ) il me remet l'ancienne url comme suit : http://www.xxxxxx.fr/product_info.php?products_id=31{1}1{2}14

est ce que tu pe me donner un example de configure.php en sachant que mes fichiers sont directement à la racine du site, j'ai peut être mal renseigné les cookies voici mon fichier:

CODE
?php
/*
  osCommerce, Open Source E-Commerce Solutions
  [url=http://www.oscommerce.com]http://www.oscommerce.com[/url]

  Copyright © 2003 osCommerce

  Released under the GNU General Public License
*/

// Define the webserver and path parameters
// * DIR_FS_* = Filesystem directories (local/physical)
// * DIR_WS_* = Webserver directories (virtual/URL)
  define('HTTP_SERVER', 'http://www.xxxxxx.fr'); // eg, [url=http://localhost]http://localhost[/url] - should not be empty for productive servers
  define('HTTPS_SERVER', ''); // eg, [url=https://localhost]https://localhost[/url] - should not be empty for productive servers
  define('ENABLE_SSL', false); // secure webserver for checkout procedure?
  define('HTTP_COOKIE_DOMAIN', '.xxxxx.fr');
  define('HTTPS_COOKIE_DOMAIN', '');
  define('HTTP_COOKIE_PATH', '/');
  define('HTTPS_COOKIE_PATH', '');
  define('DIR_WS_HTTP_CATALOG', '/');
  define('DIR_WS_HTTPS_CATALOG', '');
  define('DIR_WS_IMAGES', 'images/');
  define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');
  define('DIR_WS_INCLUDES', 'includes/');
  define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');
  define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');
  define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');
  define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');
  define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');

//Added for BTS1.0
  define('DIR_WS_TEMPLATES', 'templates/');
  define('DIR_WS_CONTENT', DIR_WS_TEMPLATES . 'content/');
  define('DIR_WS_JAVASCRIPT', DIR_WS_INCLUDES . 'javascript/');
//End BTS1.0
  define('DIR_WS_DOWNLOAD_PUBLIC', 'pub/');
  define('DIR_FS_CATALOG', '/home/WwwBSD/xxxxxx.fr/');
  define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . '/download/');
  define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');

// define our database connection
  define('DB_SERVER', 'xxxxxxx'); // eg, localhost - should not be empty for productive servers
  define('DB_SERVER_USERNAME', 'xxxxx');
  define('DB_SERVER_PASSWORD', 'xxxxxxx');
  define('DB_DATABASE', 'xxxxxx');
  define('USE_PCONNECT', 'true'); // use persistent connections?
  define('STORE_SESSIONS', 'mysql'); // leave empty '' for default handler or set to 'mysql'

// DEBUT newdesk
  define('DIR_WS_RSS', DIR_WS_INCLUDES . 'modules/newsdesk/rss/'); //USAGE - call the url /rss.php?box=categories or /rss.php?box=whats_new or /rss.php?box=newsdesk_latest.php
// FIN newsdesk
?>


Écrit par : oneill 9 Dec 2006, 15:22

Je te conseil de mettre ca déjà sur false

CODE
define('USE_PCONNECT', 'true'); // use persistent connections?


Ma modif plus haut ne portait que sur cette ligne pas les autres. Tu dois avoir SSL dans les deux premières et NONSSL pour la réponse automatique

Écrit par : idachour 9 Dec 2006, 15:50

ca ne marche pas

essai d'aller sur mon site : h##p://www.nobex.fr

et effectue un paiement avec les info suivantes :
cb test : 4974934125497800
cryptogramme :655

c'est en demo

donc pas de pb ,

ca serait vraiement gentil

Écrit par : oneill 9 Dec 2006, 16:22

CITATION(idachour @ 9 Dec 2006, 15:50) [snapback]210341[/snapback]

c'est en demo

Alors c'est normal. Passe en prod.

Écrit par : idachour 9 Dec 2006, 16:35

je suis deja en prod..... je me suis mal exprimé....

je suis vraiment bloqué...

Tu remarqueras sur ma page le n° de session en bas à gauche.



Le n° session dont se sert le serveur d'atos pour appeler le checkout_process.php( voir visiteur) et celui qui est indiqué en bas de la page de mon site n'est pas le meme quand j'effectue mon achat...


Écrit par : oneill 9 Dec 2006, 18:49

Dans l'admin, à configuration/sessions, est-ce que tu as ca ?

CODE
Répertoire des sessions : cache/  
Utilisation de force des cookies : False  
Vérifiez l'identification de session SSL : False  
Vérifiez l'utilisateur : False  
Vérifiez l'addresse IP : False  
Empêcher les sessions d'araignée : True  
Recréez une session : False
Sinon fais comme ca

C'est surtout "Recréez une session" qui me soucis

Écrit par : idachour 9 Dec 2006, 20:51

j'ai fais les mofif et rien du tout

je commence a desesperé sad.gif sad.gif sad.gif sad.gif

je suis en mode production avec un certificat de test...
j'ai seo url avec un fichier .htaccess à la racine du site
je ne rewrite pas mes url de retour ( atos_response.php et checkout_process.php) avec ma fonction tep_href_link_atos dans mon fichier atos.php


mon panier ne se vide pas qd j'utile atos sinon pour les autres paiements ( cheque) ca marche super, pas de commande dans l'admin.
je crois que le pb et que j'ai des sessions differentes entre celle de l'utilisateur qui achete et celle qu'utilise le serveur atos( visible dans les visiteur ). le serveur atos utilise le meme oscid quelque soit l'achat!!!

Écrit par : EIVAD 20 Dec 2006, 19:45

Bonjour à tous,

J'ai le même problème que idachour : aucune de mes commandes réglées par CB (ATOS) ne sont validées et donc le panier n'est pas vidé.

Cela fait une quinzaine de jours que je galère pour trouver une solution dans le code du module ATOS et sur ce forum, sans succès:

- essais de diverses configurations des sessions
- essais avec API MERCANET P600 PLUGIN LINUX
- essais avec API MERCANET 500 PLUGIN LINUX

Je trouve bizarre l'URL de retour à la boutique en fin de transaction :

http://www.monsite.com/atos_response.php/?[osCsid]3000a3d54..... n'y aurait-il pas un slash (/) en trop après "atos_response.php"

Est-ce que quelqu'un saurait d'où cela peut venir?

idachour, as-tu trouvé la solution à ton problème?

Merci d'avance pour vos réponses

Écrit par : petitbiston 20 Dec 2006, 21:03

CODE
Ultimate SEO provoque ce genre de désagrément et pas que chez OVH.
Solution : éviter de rewriter les url de retour.


Je viens d'en faire les frais, aucun retour de commandes ce lundi ... sad.gif Faut que ca tombe la semaine avant Noêl ohmy.gif

@ Oneill : Si j'ai bien tout compris :

1 - On ré-insere le code initial mais rebaptisé tep_href_link_atos. =>question => on le place n'importe ou ce code ?

2 - On reprend le fichier atos_response.php et à chaque tep_href_link on remplace par le tep_href_link atos ?

J'ai bon ?

Écrit par : petitbiston 20 Dec 2006, 21:17

Oneill j'ai retrouvé ta réponse dans ce post où tu décris la procédure. Merci

>> http://www.oscommerce-fr.info/forum/index.php?showtopic=29107

Edit : j'ai suivi les instructions, je n'ai toujours pas de commandes dans Osc admin, et en plus j'ai de nouveau mon panier qui ne se vide plus...

Re Edit :

@ Idachour : J'ai le meme soucis que toi apparemment. Je suis hébergé chez Icodia, je viens d'installer SEO. Pas de traces de commandes CB. Par contre je viens de suivre les indications d'Oneill et rien n'y fait.

Écrit par : oneill 20 Dec 2006, 21:51

Donc le problème est autre. Mon truc ne règle les problèmes que sur certains serveurs mais il ne coute rien de le mettre. Au moins tu es sur que ce n'est pas le rewriting qui est en cause.

Écrit par : petitbiston 20 Dec 2006, 21:56

CITATION(oneill @ 20 Dec 2006, 15:51) [snapback]212287[/snapback]

Donc le problème est autre. Mon truc ne règle les problèmes que sur certains serveurs mais il ne coute rien de le mettre. Au moins tu es sur que ce n'est pas le rewriting qui est en cause.


Oui j'ai fait les rectifs wink.gif mais bon depuis que j'ai installé seo c'est apparu ... enfin j'crois. Quel peut etre les causes ? surtout que le cas n'est pas isolé à petitbiston smile.gif

Écrit par : petitbiston 20 Dec 2006, 22:07

On est tout les trois chez Icodia y aurait il pas un soucis avec Icodia ou /home/WwwBSD/modules/response.dat ??
cry.gif

Écrit par : EIVAD 20 Dec 2006, 23:00

Est-ce qu'il y a une personne sur ce forum, comme nous, hébergé chez ICODIA en mutualisé qui a son module de paiement ATOS qui fonctionne ?

petitbison, as-tu déja contacté ICODIA à ce sujet? Moi pas encore... mais là je sèche

Écrit par : xaglo 20 Dec 2006, 23:03

au moins celle trois message au-dessus de ta tête et quelques dizaines (centaines??) d'autres

biggrin.gif

Écrit par : petitbiston 20 Dec 2006, 23:09

@ Eivad : Ecoute tout fonctionnait bien. J'ai bien sur enregistré des commandes par CB !! J'ai quitter OVH pour Icodia.

Dans toutes mes modifs de contribs j'ai :

- récup ID transac => install ok, fonction ok
- "Update Stock rapide" => install ok, fonction ok
- Osc Affiliate => install réalisée mais ne fonctionne pas
- Ultimate SEO => install ok, fonction ok

Depuis Osc affiliate je rencontre des soucis, je ne sais pas si c'est lié. Est ce lié à ICODIA.

Écrit par : sigmud35 21 Dec 2006, 01:05

Un de plus wink.gif Plusieurs sites chez ICODIA, en mutualisé, avec solutions basées ATOS (Mercanet, Cyberplus)... Aucun souci de particulier...

Écrit par : oneill 21 Dec 2006, 09:22

Plusieurs aussi pour moi sans soucis


Et vos IP de retour ? Elles sont bonnes ?

Écrit par : petitbiston 21 Dec 2006, 10:48

Merci pour vos réponses, vous savez pas comment ca fait plaisir d'(avoir de l'aide et du soutien.

Nous aussi pas de problèmes avec Icodia depuis juin 2006 (avec le peu de transactions wink.gif)

@ Oneill : voici les IP dans mon menu Module Paiement : 193.56.46.96,193.56.46.97,193.56.46.18

Écrit par : oneill 21 Dec 2006, 19:42

Ne conserve que celui ci 193.56.46.18

Écrit par : petitbiston 22 Dec 2006, 01:42

Apres plus de 15 h de bataille a essayer de comprendre et de remettre en ordre mon site j'essayerai de faire un post dessus car je crois que ca vaut le coup surtout pour des "nobes" comme moi...

@ Oneill : peux tu me donner des précisions sur le pourquoi de privilégier cette adresse IP wink.gif

Écrit par : oneill 22 Dec 2006, 14:22

Je n'ai que celle ci et ca fonctionne smile.gif

Écrit par : infini 27 Dec 2006, 20:21

Bonjour oneill

Je rencontre le même problème depuis que j'ai installé SEO

J'ai suivi tes indications et j'ai placé ce code tout en bas du fichier html_output.php

CITATION
////
// The HTML href link wrapper function pour ATOS

function tep_href_link_atos($page = '', $parameters = '', $connection = 'NONSSL', $add_session_id = true, $search_engine_safe = true)
{
global $request_type, $session_started, $SID;

if (!tep_not_null($page))
{
die('</td></tr></table></td></tr></table><br><br><font color="#ff0000"><b>Error!</b></font><br><br><b>Unable to determine the page link!<br><br>');
}

if ($connection == 'NONSSL')
{
$link_atos = HTTP_SERVER . DIR_WS_HTTP_CATALOG;
}
elseif ($connection == 'SSL')
{
if (ENABLE_SSL == true)
{
$link_atos = HTTPS_SERVER . DIR_WS_HTTPS_CATALOG;
}
else
{
$link_atos = HTTP_SERVER . DIR_WS_HTTP_CATALOG;
}
}
else
{
die('</td></tr></table></td></tr></table><br><br><font color="#ff0000"><b>Error!</b></font><br><br><b>Unable to determine connection method on a link!<br><br>Known methods: NONSSL SSL</b><br><br>');
}

if (tep_not_null($parameters))
{
$link_atos .= $page . '?' . tep_output_string($parameters);
$separator = '&';
} else
{
$link_atos .= $page;
$separator = '?';
}

while ( (substr($link_atos, -1) == '&') || (substr($link_atos, -1) == '?') ) $link_atos = substr($link_atos, 0, -1);

// Add the session ID when moving from different HTTP and HTTPS servers, or when SID is defined pour ATOS
if ( ($add_session_id == true) && ($session_started == true) && (SESSION_FORCE_COOKIE_USE == 'False') ) {
if (tep_not_null($SID)) {
$_sid = $SID;
} elseif ( ( ($request_type == 'NONSSL') && ($connection == 'SSL') && (ENABLE_SSL == true) ) || ( ($request_type == 'SSL') && ($connection == 'NONSSL') ) ) {
if (HTTP_COOKIE_DOMAIN != HTTPS_COOKIE_DOMAIN) {
$_sid = tep_session_name() . '=' . tep_session_id();
}
}
}

if ( (SEARCH_ENGINE_FRIENDLY_URLS == 'true') && ($search_engine_safe == true) ) {
while (strstr($link_atos, '&&')) $link_atos = str_replace('&&', '&', $link_atos);

$link_atos = str_replace('?', '/', $link_atos);
$link_atos = str_replace('&', '/', $link_atos);
$link_atos = str_replace('=', '/', $link_atos);

$separator = '?';
}

if (isset($_sid)) {
$link_atos .= $separator . tep_output_string($_sid);
}

return $link_atos;
}


J'ai également modifié les fichiers atos_response.php (includes/functions) et atos.php (includes/modules/payment)

Est ce bien comme cela qu'il faut le modifier ? Tes indications signalent qu'il faut modifier le tep_href_link par tep_href_link_atos. Qu'en est il des $link ? Il faut les modifier par $link_atos ?

Merci pour ta réponse

Écrit par : jwindal 28 Dec 2006, 10:46

Bonjour,

J'ai une bonne piste de réflexion je pense pour ces problemes.
J'ai bcp pensé à des pbs de config ou d'hébergeur. Quand le site n'est plus disponible, j'ai tout de même une enregistrement de commandes à 0 (avec les frais de minimum de commande par ex). Mais cela c'est autre chose je pense. Une indisponibilité contre lequel on ne peut rien faire.


Par contre, j'ai eu le coup une jour avec un client. J'ai passé la commande pour lui au téléphone. Il a payé avec une carte American express. Sa carte n'est pas pareil en terme de nombre de chiffres et de date de validité. Et bien en faisant la commande sur mon poste (qui ne pose jamais de pb), la page de confirmation de commande s'affiche bien. le panier n'est pas vidé. La commande pas enregistrée.

Je suis sur que ça vient de là. J'ai environ 2 à 5% de commande comme cela et je demande le mode de paiement à chaque fois maintenant. C'est soit Amex soit e-carte bleue.

Je suis chez cybermut et je n'ai eu aucune réponse à ce propos.

Est ce que cela peut etre votre cas ?


Jerome

Écrit par : oneill 28 Dec 2006, 12:10

CITATION(infini @ 27 Dec 2006, 20:21) [snapback]213209[/snapback]

Est ce bien comme cela qu'il faut le modifier ? Tes indications signalent qu'il faut modifier le tep_href_link par tep_href_link_atos. Qu'en est il des $link ? Il faut les modifier par $link_atos ?


Rien de tout ca. Juste ce que j'indique

Écrit par : infini 28 Dec 2006, 22:44

OK merci pour ta réponse.

Après des heures de recherche et de test, je suis parvenu à identifier mon problème.

En fait, dans mon cas et après avoir désinstallé la contribution SEO, le problème persistait.

L'erreur provenait du fait que j'avais activé l'usage des cookies de force. Avec ce paramètre, plus aucune commande par CB ne s'enregistrait. Dès que je l'ai mis sur false tout a refonctionné parfaitement.

Je ne connais pas le lien avec les serveurs Atos mais quelque chose ne lui plaît pas. Je ne fait pas une généralité mais cela me pose problème dans mon cas.

Écrit par : oneill 28 Dec 2006, 23:13

Quand tu actives les cookies, le maintien de la session passe par le cookie. Lorsqu'ils sont désactivés, la session est alors maintenue par l'url. Dans le flux qui part vers la banque, il doit y avoir l'oscid de la session en cours pour qu'au retour le signal de la banque fait retrouver à l'utilisateur son panier qui se vide ou pas si le paiement est ou non validé et ainsi la commande est-elle validée ou non. Sans l'oscid dans l'url de retour, la session qui était en cours est perdue et aucune commande n'est validé puisqu'aucune ne peut être identifiée. L'activation des cookies fait disparaitre l'oscid des url.

Écrit par : xaglo 28 Dec 2006, 23:14

comme d'habitude, on ne le répètera jamais assez, la réponse était dans le tuto
http://www.oscommerce-fr.info/forum/index.php?s=&showtopic=6938&view=findpost&p=150089

CITATION
En cas de problème lors du retour au site (panier non validé)
Attention aux tests de session d'OsC: mettre la "vérification utilisateur" et "vérfication IP" sur FALSE dans l'admin->Configuration->Sessions
Garder les sessions en base de donnée: mettre 'mysql' dans le define SESSIONS du configure.php
Mettre sur FALSE l'utilisation de force des cookies
Laisser sur FALSE "Utiliser URL des moteurs de recherche"
Vérifier l'absence d'htaccess pouvant empêcher le serveur ATOS de se connecter au catalog (si vous avez mis un accès par mot de passe en phase de test)

Écrit par : infini 28 Dec 2006, 23:23

Bonsoir xaglo et oneill

J'ai bien évidemment lu ce tuto.

Si j'ai mis l'utilisation de force des cookies sur true, c'était pour supprimer le numéro de session dans l'url. Car en testant le site sur www.spider-simulator.com, la session apparaît toujours après l'installation de SEO urls.

J'ai un peu d'apréhension à remettre SEO urls et Sid Killer pour pallier à ce problème.

En attendant, je suis revenu rapidement à la solution préconisée dans la FAQ.

Merci pour vos messages qui confirment tout le bien que je pense de ce forum. De très bons conseils (qu'il faut suivre smile.gif ) et une disponibilité hors du commun.

Écrit par : xaglo 28 Dec 2006, 23:40

CITATION(infini @ 28 Dec 2006, 23:23) [snapback]213433[/snapback]
J'ai un peu d'apréhension à remettre SEO urls et Sid Killer pour pallier à ce problème.
Il ne faut pas avoir d'apréhension, d'autres y sont arrivés. juste prendre des précautions et valider ses modifications avant mise en service wink.gif

Écrit par : infini 28 Dec 2006, 23:44

Je sais bien mais le site est en ligne.

Les commandes tombent tous les jours donc le droit à l'erreur doit être le plus proche possible de 0.

J'ai installé WinMerge et je compare le fichier catégories.php pour être sur de ne pas oublier de modif. Je n'ai pas envie de basculer le nouveau fichier en l'état. Je préfère apporter les modifications nécessaires.

Je vais y aller en douceur.

Encore merci wink.gif

Écrit par : infini 29 Dec 2006, 00:36

oneill

CITATION
En fait tu récupères la fonction tep_href_link() d'origine (celle d'avant l'install de SEO) tu la remet en plus de la nouvelle en changeant son nom (tep_href_link_xxx() par exemple ) et il te suffit de l'appeler lorsque tu ne veux pas faire de rewriting comme pour les url de retour du serveur de banque.

Cette solution est valable pour le module Atos.

Je dois prochainement installer un module spplus. Le principe est-il le même ?

Écrit par : oneill 29 Dec 2006, 09:33

Ca, je ne sais pas.

Écrit par : sigmud35 30 Dec 2006, 12:50

Non Spplus, c'est propriétaire Caisse d'épargne je crois, pas d'ATOS...

Écrit par : infini 1 Jan 2007, 23:32

J'ai tout de même une question qui me travaille grandement.

Lorsque l'on n'utilise pas Ultimate SEO, le numéro de session apparaît dans l'URL comme ceci :

CITATION
osCsid=88d6b65c3caab5195fcd96bd4ba6bd4a


Visiblement Atos a besoin de ce numéro de session pour finaliser la commande.

Quand on installe Ultimate SEO, ce numéro de session disparaît il ?

Si c'est le cas, la solution de oneill consistant à ne pas rewriter les pages concernées par le module de paiement par CB permettra t'il d'afficher de nouveau le numéro de session au moment du paiement ?

Merci pour vos réponses.

Écrit par : oneill 2 Jan 2007, 14:37

Oui ca le permet

Écrit par : infini 2 Jan 2007, 14:40

De toute manière le numéro de session n'apparaît plus même après avoir enlevé SEO.

Et depuis les commandes par CB ne s'enregistrent plus.

Je ne sais pas si cela provient du fichier configure.php qui est mal renseigné ou quoi.

Je vois souvent dans les post ces paramètres laissés à vide

define('HTTP_COOKIE_DOMAIN', '');
define('HTTPS_COOKIE_DOMAIN', '');
define('HTTP_COOKIE_PATH', '');
define('HTTPS_COOKIE_PATH', '');

Pourtant j'ai l'impression qu'une fois l'installation terminée ces zones ne sont pas toutes vides

Si vous avez une idée, je suis preneur

Écrit par : jguerrea 9 Jan 2007, 09:00

nouveau au club wink.gif

un client me previent ce matin avoir passé commande non visible dans son historique

dans le mien non plus. Il est bien dans mercanet et a bien réglé.

Je n'aia pas SEO suis chez OVH en multi240

J'ai pris 300 paiements sur noel sans souci. Depuis ce matin dexu autres commandes sans souci ...

est-ce un souci unique ou ceux qui ont expérimenté ces soucis ont-ils trouvé la cas de figure qui génére celà ... c'est en effet pas génial de ne pas savoir qu'un client a commandé ;-(

si quelqu'un a une piste

merci

Jacques

Écrit par : thierry_montpellier 18 Jan 2007, 22:56

J'ai moi aussi ce problème de non enregistrement de commande et je cherche depuis ce matin comment le résoudre mais si j'ai une piste je viendrais ajouter ma pierre dans ce post

Thierry

Écrit par : oneill 19 Jan 2007, 08:59

CITATION(jguerrea @ 9 Jan 2007, 09:00) [snapback]215000[/snapback]
nouveau au club wink.gif

un client me previent ce matin avoir passé commande non visible dans son historique

dans le mien non plus. Il est bien dans mercanet et a bien réglé.

Trop de temps pour payer peut être. A voir avec son heure d'arrivée sur le serveur de la banque (n° de transaction) et l'heure de validation du paiement sur ton back office. Si plus d'une demi heure, ca fait cela.

Écrit par : qeb 26 Jan 2007, 12:13

Après plus de 3h de recherche sur le même problème que la plupart des personnes avec Atos je viens de trouver les lignes coupables dans checkout_process.php. Je ne sais plus où j'avais trouvé cette modification mais elle servait à obliger à accepter les conditions de vente même avec le javascript désactivé ...

CODE
// BEGIN OF MUST AGREE TO TERMS - JAVASCRIPT DISABLED FIX - By Phliplip
  if(empty($HTTP_POST_VARS['agree'])) {
    include(DIR_WS_LANGUAGES . $language . '/' . FILENAME_CHECKOUT_PROCESS);
    tep_redirect(tep_href_link(FILENAME_CHECKOUT_CONFIRMATION, 'terms_not_agreed='.urlencode(CONDITION_AGREEMENT_ERROR), 'SSL'));
  }
// END OF MUST AGREE TO TERMS - JAVASCRIPT DISABLED FIX - By Phliplip


C'est donc cette portion de code, mise au début du fichier checkout_process, qui redirigait directement le serveur atos vers checkout_confirmation au lieu de valider la commande et de vider le panier.

Voilà, j'espère avoir aider quelques personnes.

Qeb

Écrit par : oneill 26 Jan 2007, 12:27

Effectivement, déjà vu ici. Pas pensé sad.gif
http://www.oscommerce-fr.info/forum/index.php?s=&showtopic=27733&view=findpost&p=144208

Écrit par : jguerrea 26 Jan 2007, 20:37

Bonsoir

chez moi ce code est déjà commenté ...
donc il n'y a pas que celà

je n'ai plus eu le souci depuis la dernière fois ... me semble t-il ...

Écrit par : xavkick 6 Feb 2007, 18:13

Nous avons moins de soucis depuis que oneill( que je remercie au passage encore une fois ) nous à fait la modif sur le fichier.
Par contre (je suis chez ICODIA ---> 100% satisfait ) mais il semble que nous avons des soucis avec les utilisateurs de MOZILLA sur la version 2.001.
En effet sur cette version lorsque le client navigue sur le site, les pages passent de français à anglais de façon anarchique et je pense que cela peut provoquer cette perturbation.

xavier

Écrit par : oneill 6 Feb 2007, 19:27

@ xavkick -> Je me suis promené sur ta boutique avec un MOZILLA 2.0.0.1 sans aucun problème.

Écrit par : xavkick 7 Feb 2007, 12:54

CITATION(oneill @ 6 Feb 2007, 19:27) [snapback]219862[/snapback]

@ xavkick -> Je me suis promené sur ta boutique avec un MOZILLA 2.0.0.1 sans aucun problème.



Merci Oneill, j'ai modifié sur le fichier application top la sélection automatique des langues...


Sinon, concernant ATOS, cela peut venir aussi du client qui ferme sa fenêtre par une crois et non par le retour en boutique.

Je ne comprends pas que ATOS ne resolve pas ce soucis. ou alors je ne connait pas cette solution.

xav

PS: ONEIL ton site Everglo est tout simplement superbe.

Écrit par : oneill 7 Feb 2007, 21:56

blush.gif Mici

Si le client, après avoir effectué son paiement sur la page de la banque, coupe sa page directement, ce n'est pas grave. Le serveur de la banque envoie la réponse automatique à ta boutique qui doit, normalement se démer se débrouiller avec pour peu que cette réponse automatique soit correctement traitée.

Écrit par : lsolas 3 Apr 2007, 10:46

J'ai installé le module de paiement SIPS de chez Atos et je suis hébergé chez OVH.
J'ai le même soucis que dans ce topics, à savoir que lors de la mise en production, les commandes ne sont pas enregistrées dans la base et le panier n'est pas vidé.
Malgré la lecture de ce topics et la vérification de toutes les solutions proposées ici, le problème persiste. Quelqu'un peut-il m'aider ?

Cordialement

Laurent

Écrit par : web_addict 5 Apr 2007, 12:41

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+

Écrit par : webmasterdiet 28 Nov 2007, 20:46

j'ai aussi le même problème, je suis sur un 90plan ovh
d'après atos, c'est le fichier checkout_process.php qui est indisponible, d'où la réponse failed
hors mon fichier est dispo si je tape son adresse dans mon navigateur,
toute ma configuration de session est sur false
tout marchait normalement depuis 1 an, et là depuis 1 semaine plus une seule commande n'est enregistrée, aucun mail n'est envoyé aux clients, tout les paiements sont en état failed.

je désespère

Écrit par : maxime 29 Nov 2007, 07:56

As tu modifié un fichier quelconque depuis 1 semaine ? Si oui, vérifie cela. Si non, regarde si tu autorises les bonnes adresses ip dans la configuration du module atos (et éventuellement que ces ips ne sont pas bloqués à un niveau supérieur : htacess pare-feu).

Écrit par : webmasterdiet 29 Nov 2007, 10:35

Bien vu le problème d'htaccess, c'était à cause de ça, vraiment merci !!!!!!!!!!!!!!!!!!!!!!!!!!

Écrit par : Juliettta 13 Sep 2010, 07:14

Bonjour tout le monde,

En voyant le titre de ce message j'ai été faire une vérification sur mes paiements...Sait-on jamais..
Résultat pour ma part pas de souci.
Mais en même temps je n'ai PAS utilisé les responses et request du module atos, en effet je suis également sur Ovh et j'ai utilisé ceux fournis par OVH en direct
http://guides.ovh.com/MiseaJourKitAtos
A tester donc
Pour ma part ca fonctionne parfaitement.
Cela fait 1 mois maintenant que j'ai installé et pas de problème avec.
pas de session recréer pour ma config.
En espérant que cela aidera.
Bon codage

Écrit par : chrysalide 13 Sep 2010, 09:32

Salut Julietta,

les deux fichiers request et response du pack délivré par OVH ne corrige pas la problématique de non validation de commande après paiement.

Ils sont là pour mettre a jour la version installé compilés pour le noyau linux 2.4.x pour un noyau égale ou supérieur à 2.6.9.x.

D'ailleurs il sont livrés dans les pack des banques depuis déjà un bon moment en plus des 2.4

Normalement, ce problème de non validation ne doit pas arrivé trop souvent, personnellement je le rencontre que très rarement genre 1 commande tous les 2/3 mois malgré un volume conséquent de commande

Écrit par : miKL86 20 Oct 2010, 12:11

Bonjour,

Je rencontre le même pb que beaucoup : commandé payées mais non enregistrée.
- Par contre je n'utilise pas ATOS mais Cyberplus paiement.
- Je ne pas chez OVH mais chez online sur un dédié
- J'utilise aussi SEO URL
- Ce problème arrive de manière aléatoire
- Tous mes réglages sont sur FALSE dans sessions, sauf "empecher les sessions araigné"
- J'ai bien un Htaccess à la racine mais qui sert uniquement pour l'url rewriting

Sommes nous plusieurs dans ce cas là ? existe t'il des solutions ?
Merci d'avance à vous

Écrit par : djeek9006 11 Dec 2010, 18:49

Bonjour,
pour ma part la solution a été toute simple : malgré une version à jour d'oscommerce, le passage en PHP5.3 ne faisait plus fonctionner le retour d'atos (bien que le paiement soit validé).

Pourtantn, j'avais des fonctions type ereg, eregi et split, que j'avais bien passées en @ereg, @eregi, @split (pour ne plus avoir le message d'erreur deprecated)

Bref, il faut avoir une "vraie version" d'oscommerce, compatible avec PHP5.3 pour utiliser ATOS...

En espérant que ce post servent à d'autres ...

Oscommerce adapté PHP 5.3 : https://github.com/osCommerce/oscommerce2

Mais attention au fichier modules/payment/ATOS.php qui lui n'est pas encore adapté !


Écrit par : Natacha31 21 Dec 2010, 14:58

Problème identique
quelques soit les versions
il y a un bug quelque part

Bonnes fêtes à tous
Natacha

Écrit par : brouillard 30 Dec 2010, 15:07

Pour valider la commande manuellement : http://addons.oscommerce.com/info/7674

Écrit par : daveledave 10 Aug 2011, 15:06

Bonjour,

J'ai ce problème aussi. Est-ce que quelqu'un a finalement trouvé une solution ?
Je pense que c'est du a un timeout de la session entre le moment ou le client initie le paiement et le moment ou il est validé.

Les clients dont les commandes ne sont pas enregistrées sur mon site me disent qu'ils ont mis beaucoup de temps à effectuer le paiement (et le 3DSecure n'arrange rien).
J'ai appellé Atos et ils me disent qu'ils n'ont pas de timeout sur leur page de paiement... que le client peut payer 3 jours après être arrivé sur leur page.

Est-ce que quelqu'un a une solution ?
web_addict dit dans son précédent message qu'il a augmenté le temps de session mais que ca n'est pas suffisant. Je pense que ca doit déjà régler une partie du problème non ?

Merci

David smile.gif

Écrit par : Gnidhal 10 Aug 2011, 15:55

Augmenter la durée de session ça règle pas grand chose, ça pose plus de problèmes.
Si tu augmentes la durée de session (ordinairement 24minutes) :
tu prends le risque de saturer ta table session (j'en connais un qui a planté un dédié comme ça, avec plus de 2500 visiteurs/jour il est vrai)
tu laisses perdurer des sessions qui devraient être supprimées (risque de piratage de compte client dans un espace semi-public).
En 20 minutes, tout humain normalement constitué devrait réussir à conclure un paiement par CB.
Alors tu vas peut-être récupérer 1 paiement égaré sur 20 en allongeant de 20 minutes la session.
Quant au client qui passe commande le lundi et reste bloqué jusqu'au mercredi sur la page de la banque, c'est un fou ou un inconscient.

Mais tu as peut-être des erreurs de retour sur le atos_response.php qui met beaucoup de temps à répondre avec certains mutualisés (ça peut être le cas si le site est peu actif). Et dans ce cas, élargir la session ne servira à rien. Le serveur de la banque renvoie vers le site marchand qui met plusieurs minutes à lui retourner un 200. Sans réponse assez rapidement le serveur ferme la connexion, les données sont tronquées. Ta commande est perdue même si ta session fait 20 heures.

La contrib holding_orders permet de régler tous les cas de figure car les commandes sont pré-enregistrées avant paiement.
Elle est juste un peu délicate à installer.

Écrit par : oneill 10 Aug 2011, 16:49

Personnellemment, j'ai eu 3 timeout ces 12 derniers mois. Pas de quoi se mettre la rate au court bouillon, le phénomène est exceptionnel.

Écrit par : brouillard 10 Aug 2011, 17:43

C'est vrai qu'augmenter le temps de la session ne sert absolument à rien, et je me demande même à quoi sert la session dans les données de retour ATOS puisque le client est identifié par son customer_id qui est présent dans les données de retour ATOS.

J'ai changé le paramétrage de ATOS pour que le retour vers la boutique se fait automatiquement après le paiement, de cette manière la boutique récupère et enregistre directement la commande.

J'ai tendu une perche http://www.oscommerce-fr.info/forum/index.php?showtopic=68827

Mais j'ai la nette impression que cela n'intéresse personne.

Écrit par : Gnidhal 10 Aug 2011, 19:29

Pfff brouillard...
Sans numéro de session, il n'y a plus de panier puisqu'il est toujours dans les variables de session uniquement. Il ne sera transféré en bdd que par le checkout_process et ce dernier a besoin d'un id de session pour récupérer les données.

Quant à ta perche, elle n'est pas possible à mettre en oeuvre pour tous.

Écrit par : brouillard 2 Sep 2011, 11:36

Citation (Gnidhal @ 10 Aug 2011, 19:29) *
Pfff brouillard...
Sans numéro de session, il n'y a plus de panier puisqu'il est toujours dans les variables de session uniquement. Il ne sera transféré en bdd que par le checkout_process et ce dernier a besoin d'un id de session pour récupérer les données.
Quant à ta perche, elle n'est pas possible à mettre en oeuvre pour tous.


Bon, point par point :

1) Les variables de session (numéro de session) sont des cookies enregistrées dans l'ordi (voir navigateur) du client, donc si le client surf pendant 10 minutes sur un autre site et revient à la boutique son panier reste inchangé.

2) Quant le client est connecté je ne vois pas pourquoi l'id de la session sera transféré à la Bdd, c'est plutôt le customer_id (qui est enregistré avec les variables de session) qui sera transféré à la Bdd via le checkout_process.php.

3) Quant à la fameuse perche (Retour automatique à la boutique après paiement sur ATOS) c'est le même module de ATOS qui a subi quelques modifs. S'il fonctionne sans le retour automatique (AUTO_RESPONSE), il n'y a aucune raison qu'il ne fonctionnera pas avec, je l'ai testé sur plusieurs boutiques et ça marche nickel !

4) Quant au Pfff, j'en répondrais Pffff.

Écrit par : chrysalide 2 Sep 2011, 13:05

ton Id de session est effectivement stocké dans le cookie mais c'est juste un ticket pour rapprocher ton client, d'une session active (et ces infos) stockée en base (table session).

Ta session a une durée de vie définie sur 1440 secondes (par defaut) et passé ce délai tes informations de session ont juste été effacées de ta table session.

ton client part en balade plus de 24 minutes après être entré dans le tpev, qu'est ce qui ce passe ?

Alors +1 avec Gnidnal, Pfff Brouillard !

Écrit par : PMooNC 16 Sep 2011, 10:45

La solution c'est de prévenir le client (qui ne lit pas toujours smile.gif ) sur la dernière page avant le clic final qu'il a 20 minutes maximum pour valider son "ticket" au delà la boutique n'a pas le retour de la banque.

Ou bien forcer un retour vers la page précédente au bout de X minute d'inactivité sur cette page.

Pas chez OVH, mais même problème de temps en temps (c'est pénible).

Écrit par : brouillard 19 Sep 2011, 13:34

Citation (PMooNC @ 16 Sep 2011, 10:45) *
La solution c'est de prévenir le client (qui ne lit pas toujours smile.gif ) sur la dernière page avant le clic final qu'il a 20 minutes maximum pour valider son "ticket" au delà la boutique n'a pas le retour de la banque.

Ou bien forcer un retour vers la page précédente au bout de X minute d'inactivité sur cette page.

Pas chez OVH, mais même problème de temps en temps (c'est pénible).


C'est pénible et pas professionnelle du tout, la solution c'est le retour automatique après paiement

arrow.gif http://www.oscommerce-fr.info/forum/index.php?showtopic=68827

Écrit par : brouillard 25 Sep 2011, 10:52

Citation (chrysalide @ 2 Sep 2011, 13:05) *
ton Id de session est effectivement stocké dans le cookie mais c'est juste un ticket pour rapprocher ton client, d'une session active (et ces infos) stockée en base (table session).

Ta session a une durée de vie définie sur 1440 secondes (par defaut) et passé ce délai tes informations de session ont juste été effacées de ta table session.

ton client part en balade plus de 24 minutes après être entré dans le tpev, qu'est ce qui ce passe ?

Alors +1 avec Gnidnal, Pfff Brouillard !


Seul un débile mental passera plus de 20 minutes pour remplir 16 chiffres, une date (menu déroulant) et 3 chiffres pour le paiement sur le site de ATOS.

On n'a pas besoin de renvoyer la session_id (oscid) dans l'URL du moment que le client est connecté et identifié par le customer_id tant que la durée des cookies n'a pas expirée.

Dans le cas ou ce soit un débile mental (plus de 20 minutes), renvoyer la session_id (oscid) dans l'URL ne sert à rien, et n'identifie personne, et la commande ne peut s'enregistrer sans le customer_id (qui fut détruit avec les autres variables de session).

Écrit par : kenicki 22 Nov 2011, 10:04

Bonjour,

Je fais suite à tous les échanges que vous avez postés sur le problème de la validation du paiement CB mais le non enregistrement de la commande.
Dans mon cas tout fonctionnait bien jusqu'au jour où j'ai forcé l'utilisation des cookies pour ne pas plus avoir le oscid dans les URL et ainsi éviter le contenu dupliqué.
Après cette modification les commandes par CB n'étaient plus enregistrées.

Ma question : Existe-t-il une solution pour supprimer les numéros de sessions dans l'URL ET faire fonctionner le module de paiement (j'utilise ATOS de la BP) ?
je n'ai pas trouvé ma réponse dans les nombreux posts que j'ai pu lire...

Merci d'avance

Écrit par : Gnidhal 14 Feb 2012, 21:13

Après avoir rencontré le problème, je peux affirmer que Brouillard fait de l'embrouille derrière un écran de fumée!
La solution pour PHP 5.3 que j'ai expérimenté est là : http://www.oscommerce-fr.info/forum/index.php?s=&showtopic=69443&view=findpost&p=361176

ça devrait aussi résoudre ton problème kenicki

Écrit par : kenicki 17 Feb 2012, 14:24

Salut Gnidhal,

Quand j'ai vu ton post, je me suis dit génial je vais enfin pouvoir le débarrasser de ces "foutus" variables OsCid qui traine dans mon URL.
Et malheureusement après tests ça ne fonctionne pas.

Voila ce que j'ai fait :
- Forcer l'utilisation des cookies
- Effectuer la modification que tu as proposé dans "application_top.php"

Et les variables de sessions sont effectivement disparues dans les URL mais la commande n'est jamais enregistrée dans mon interface.

Pour info, je suis sur une V2.2 RC2

As-tu une idée ?
Merci

Écrit par : paddybl 21 Feb 2012, 11:21

salut désolé kenicki, mais gnidhal n'a jamais dit qu'il se débarrassait des osCId, au contraire...
il ne faut pas activer le forcage des cookies d'apres moi, ca c'est sur

l'osCid est obligatoire pour récupérer les infos de commande et valider.
Gnidhal pense que justement c'est cette osCid qui peut etre manquant et propose une solution pour etre sur qui soit bien récupéré dans tous les cas
qu'elle soit passé en post ou en get avec le data de ta banque

de mon coté j'ai 99% des commandes qui se valident correctement
j'ai programmé et je recois un mail de débuggage systèmatiquement en cas de problème avec les info du client, son nom et le montant et la cause de cette annulation ou erreur a chaque tentative infructueuse.
Et justement les rares fois ou je n'ai même pas se mail ou la commande validé, je retrouve le retour automatique en Failed sur le rapport de banque.

pas un problème d'osCid... soit disant que le serveur est injoignable...
d'autre que moi ont se problème de retour en FAILED?

la solution au problème de retour classique infructueux aurait pu etre le retour automatique sur la boutique, mais je confirme aussi les dire de Gnidhal sur la solution "ultime" de Brouillard... c'est de la fumée...
j'avais tenté quelques choses du genre nettement plus aboutit et celà ne résoud rien...

pour mémoire une vieille explication tres précise de ce type de tentative et du problème de retour en GET:

Citation
simtic
18 Jul 2009, 17:04
Bonjour,

J'ai travaillé ces derniers jours sur le site de Florian pour configurer le retour automatique.
Un petit mot ici pour faire un topo concernant cette intervention, qui s'est révélée assez, heu... riche en découvertes

Bon, le serveur de la banque communique ses infos à la boutique via une variable de nom DATA, qui contient les infos cryptées.
Cette variable est passée, selon les cas, en GET ou en POST, sur tel ou tel fichier php de la boutique.
le fichier qui reçoit la variable utilise le module d'Atos pour la décrypter et réagit ensuite en fonction des infos qu'il y trouve.
ça c'est l'idée.

ensuite,
plus concrétement:
Cette variable est passée une première fois au fichier checkout_process.php, en POST.
là, il s'agit d'une communication directe entre le serveur de la banque et celui de la boutique (ici, le navigateur de l'internaute n'intervient pas).

Puis lorsque l'internaute revient sur la boutique, il arrive sur le fichier atos_response.php.
Et là encore, on trouve le paramètre DATA.
Sauf que
- lorsque le retour automatique n'est pas activé, ce paramètre est transmis en POST (et là tout va bien)
- lorsque le retour automatique est activé (avec DATA!NO_RESPONSE_PAGE!), le paramètre DATA est transmis en GET (allez savoir pourquoi).

Et là, y'a deux problèmes :

1) le paramètre DATA, passé en GET, est mal introduit dans l'url de retour. Cette dernière contient déjà un paramètre GET (osCsid) pour l'identifiant de session, et le paramètre DATA devrait donc être séparé du paramètre osCsid par un &. Sauf qu'il est introduit par un point d'interrogation, comme s'il s'agissait de l'unique paramètre GET. on se retrouve donc avec une url de retour de la forme:
atos_response.php?osCsid=<id_de_session>?DATA=<valeur_du_parametre_DATA>
au lieu de:
atos_response.php?osCsid=<id_de_session>&DATA=<valeur_du_parametre_DATA>

ce qui fait que du point de vue de php, il n'y qu'un seul paramètre osCsid, et qui vaut:
<id_de_session>?DATA=<valeur_du_parametre_DATA>

donc un paramètre de session erroné, d'où la redirection en page d'accueil.

On peut régler ce problème en concaténant un & à la fin des urls de retour normal_return_url et cancel_return_url (dans atos.php).
Si ces urls se terminent par un &, le paramètre DATA n'est plus introduit par un ? et se retrouve bien séparé du paramètre osCsid.
et la session n'est donc plus perdue.

2) Mais j'ai ensuite rencontré un autre problème: une erreur au moment du décryptage du paramètre DATA. L'erreur indiquait que le paramètre DATA n'était pas de la bonne taille. là, je suis pas sûr (d'ailleurs si quelqu'un a une idée...), mais je me suis dit que ça pouvait venir du fait que ce paramètre étant d'une taille assez conséquente, il se pouvait qu'il se soit retrouvé tronqué dans l'url. Il me semble en effet que certains serveurs limitent la taille maximum des urls... enfin à vérifier.

Quoi qu'il en soit, en partant de cette idée, nous avons décidé de nous basé sur le paramètre DATA au moment où il est transmis au fichier checkout_process.php, puisqu'à ce moment-là, retour automatique ou pas, il est passé en POST. C'est à dire que nous avons mis en place un système de sauvegarde de ce paramètre, pour qu'il puisse être ensuite réutilisé au moment de l'appel à atos_response.php. Pour prendre en compte le fait que plusieurs commandes pouvaient être passées en même temps, nous avons d'abord pensé à créer une table en base, avec un champ customer_id et un champ DATA. Puis nous avons finalement opté pour une sauvegarde dans un dossier. Chaque paramètre DATA y étant enregistré dans un fichier dont le nom est formé avec l'identifiant du client. Lorsque le fichier atos_response.php est appelé, c'est donc à partir de cette sauvegarde que le paramètre DATA est récupéré, et non plus à partir du paramètre GET. Et voilà .

Écrit par : Loocktet 3 Mar 2012, 01:13

Bonjour à tous,
Depuis plusieurs jours, le retour automatique ne fonctionnait plus (avec bien sur, les conséquences de commandes encaissées et non enregistrées).
Pas de trace dans le log Apache (ou plutôt plus de trace de checkout_process), pas de mail d'erreur Atos, rien... sad.gif

Après quelques tests et recherches, j'ai pu constater qu'Atos ne supportait plus la réponse automatique sur une page en SSL (oui, je sais, c'est spécifié dans la doc mais ça marchait depuis plusieurs années).
J'ai modifié l'adresse de retour dans atos.php en remplaçant le $request_type par 'NONSSL' et là, miracle, cela fonctionne à nouveau.

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'];


Pour info, j'avais appliqué la modif de application_top.php postée par Gnidhal (merci!) dans ce topic afin de conserver la session en cas de retour sur une page non SSL.

Voilà, si ça peut aider ceux qui avait positionné leur page de réponse automatique en SSL...

Écrit par : tofquer 4 Mar 2012, 17:03

Bonjour,

Depuis quelques temps, je rencontre aussi ce problème de commande bien payée mais dont la commande n'apparaît pas dans l'administration. A chaque fois, le problème vient quand il y a un doublon sur l'ID de commande des clients.
Encore aujourd'hui, deux clients ont le même numéro d'ID commande, l'un en paiement paypal et l'autre en paiement cyberplus, sauf que celui qui a payé par cyberplus, ba je n'ai pas sa commande ?
Les autres fois, la même chose sauf que les deux clients avaient payés avec cyberplus paiement.

Je viens d'installer la modif indiquée par Gnidhal, je verrai si ça change.

Propulsé par Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)