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

Je n'ai que celle ci et ca fonctionne

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



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

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

Rien de tout ca. Juste ce que j'indique

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.

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.

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....st&p=150089

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 ) et une disponibilité hors du commun.

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

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

oneill


Cette solution est valable pour le module Atos.

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

Ca, je ne sais pas.

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

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 :



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.

Oui ca le permet

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

nouveau au club

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

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

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.

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é ...



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

Effectivement, déjà vu ici. Pas pensé
http://www.oscommerce-fr.info/forum/index....st&p=144208

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

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

@ 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.

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.

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

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



- J'ai vérifier l'histoire des cgv qu'il faut valider mais c'est commenté chez moi dans checkout_process (


- J'ai augmenter le temps de session dans le fichier funtions/sessions.php
Chercher :

rempalcer par :


- 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 :

Par :


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 :


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.


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".


Ce code vérifie si le moyen de paiement est bien enregistré dans les infos de sessions sinon erreur



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+

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

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).

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

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

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

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

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é !

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

Bonnes fêtes à tous
Natacha

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

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

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.

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.

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....showtopic=68827

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

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.

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 !

La solution c'est de prévenir le client (qui ne lit pas toujours ) 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

http://www.oscommerce-fr.info/forum/index....showtopic=68827

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).

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

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....st&p=361176

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