Bonjour à tous,
La première version bêta de la version 2.0 est prête, j’attends vos retour pour savoir si cette version peut être considérée comme une release stable. Une désinstallation de la version 1.x est nécessaire avant d’installer celle-ci car il y a eu trop de modifications pour mettre simplement à jour en remplaçant les fichiers.
Changelog:
- BO: refonte du back office
- BO: possibilité de définir le protocole à utiliser systématiquement lors des retours de banque.
- BO: possibilité de définir le domaine vers lequel se font les retours de banque.
- BO/SECURITY/COMPAT: possibilité de définir un domaine et un protocole de retour spécifique aux réponses automatiques
- BO: possibilité de définir une langue unique.
- INTERNAL/FS: Modification de la hiérarchie des fichiers pour faciliter la déportation des templates dans le dossier de thème.
- BO/LINUX: (Linux uniquement) Automatisation de l'export des tpl, images et fichier de langue vers le dossier de theme. Réécriture des fichiers de langue à la volée. Nécessite un droit d'écriture et d'exécution sur le contenu du dossier de templates.
- ALL: Support du paiement en 2/3 fois
- DEFAULT-CONFIG: Par défaut, les logos de cartes sont maintenant affichés dans le bloc 3 plutôt que 1 pour ne pas avoir de texte généré par ATOS.
- INTERNAL/COMPAT: Abandon des fonctions CORE PHP escapeshellcmd et escapeshellarg qui posaient problème sur des hébergements à bas coût
- INTERNAL/COMPAT: Utilisation de la variable d'environnement HTTP_HOST plutôt que SERVER_NAME (posait problème sur les serveurs 1&1)
- INTERNAL/COMPAT/WINDOWS: Les chemins dont la valeur passe par Tools::getValue ont leurs backslashs remplacés par des slashs
- INTERNAL/COMPAT/WINDOWS: Les arguments sont entourés de guillemets doubles plutot que simples
Télécharger :
Module ATOS/SIPS version 2.0 BETA 1 RC 1
Pour soutenir le module et aider à son évolution :
Bonjour Damien,
Superbe ta version 2 !!! je suis en train de tester sur mon serveur local en mode test. sous Windows aussi. Donc version OK sous Windows en mode test pour le moment !!! J’ai juste du cliquer sur le bouton « Charger la configuration par défaut » après l’installation car à la fin des path de répertoires par défaut j’avais des / au lieu de \ et tout rentre dans l’ordre. J’ai « stressé » un peu le module. Le seul PB que j’ai eu, c’est si après « VALIDATION » sur la plateforme de la banque je ne clique pas sur retour boutique, elle n’est pas prise en compte dans le BO de ma boutique. As tu des problèmes de ce côté ? Est-ce propre au mode test ou en mode production tu penses que ca roule ?
Salutations
Ta boutique est-elle en maintenance ?
Ton serveur est-il local ou en ligne ? Consultes tu le site depuis une adresse qui n’existe que sur ton réseau local ?
Ma boutique n’est pas en maintenance, mais je vais faire des tests demain sur ma boutique en ligne je te tiens au courant.
Sur une boutique sur réseau local il est normal de ne pas recevoir la validation automatique de la banque : l’adresse du serveur n’étant résolvable que depuis le réseau local, les serveurs de banque ne peuvent pas le contacter.
Le même problème se pose avec la maintenance si l’on oublie d’insérer les IPs des serveurs bancaires dans les IPs de maintenance Prestashop.
Bonjour,
Je ne comprend pas pour les droits en écriture. Pouvez-vous les expliquer avec des chiffres (ex : 755, 700…).
A quoi correspond :
– lecture et exécution pour les serveurs HTTP/PHP
– lecture et exécution pour tous
– lecture et exécution par tous
– tous les droits pour les serveurs HTTP/PHP
– doit avoir des droits suffisants pour être exécuté via la fonction exec() en PHP
– lecture par tous
Merci beaucoup.
Bonjour,
non, ce n’est tout simplement pas possible car cela dépend la configuration du serveur, par exemple : A quel utilisateur:groupe appartiennent les fichiers, sous quels utilisateurs:groupes tournent les serveurs (ou deamons, services)…
Une même valeur numérique de CHMOD fonctionnera à la perfection sur certains serveurs, sera trop faible sur d’autres serveurs, et, bien pire, sera une faille importante de sécurité sur d’autres car trop élevée !
En réalité, la plupart des (vrais) webmasters consciencieux ne jetterons qu’un coup d’oeil rapide à cette section car la seule chose qui les intéressera sera de connaitre les fichier nécessitant un droit d’écriture par le serveur PHP, les autres droits sont aisément retrouvable en fonction du type de fichier et de son contenu (par exemple un fichier PHP de classe devra être lisible par le serveur mais ne devrait pas être consultable depuis un navigateur, un fichier PHP contrôleur sur l’architecture Prestashop nécessite lui par contre d’être consultable via un navigateur, etc…).
Comme stipulé dans la documentation, de sérieuses compétences technique en administration/sécurité d’hébergement sont nécessaires à l’installation de ce module. Si tu n’as pas ces compétences, demande simplement à ton hébergeur ou à la personne assurant l’info-gestion de ton site de l’installer pour toi.
Vous pouvez penser que je suis élitiste mais il s’agit d’une véritable question de sécurité, un module de paiement mal installé peu conduire à un détournement des paiements ou à un vol des identités bancaires de tes clients. Les personnes ayant déjà eu affaire à un e-Commerçant peu scrupuleux comprendrons. Un petit exemple pour illustrer mes propos ? Ayant voulu essayer les services du site metaboli.fr je me suis créé un compte et ai payé par paypal, j’ai très rapidement fermé ce compte à cause des méthodes de vente malhonnêtes de ce commerçant mais c’est une autre histoire… Hors, 3 mois après cloture du compte, d’un seul coup, metaboli.fr se met à effectuer plusieurs retraits sur mon compte, à intervalles aléatoires, à cause d’un « problème technique ». Il est évident que personne n’a envie de se retrouver à ma place dans cette histoire, mais en cas d’installation d’un module de paiement par un débutant, vous risquez surtout de vous retrouver dans la position de metaboli.fr, hors juridiquement vous risquez gros, très gros dans ce cas (sans parler de votre image de marque qui partira en lambeaux).
De plus, une fois encore comme indiqué dans la documentation, je rappelle que les droits (donc valeurs CHMOD) que j’utilise sur mon propre serveur de développement sont conservées dans l’archive (tarball) du module. Ces droits ne doivent cependant pas être considérés comme une parole d’évangile, il sont simplement fournis à titre d’illustration.
Bon tant pis. Du coup, j’ai remis les même droits d’écriture que mon ancien module atos. Pour info tout à marché en tant que production. Merci pour ton module Tgg_Atos.
Bonjour djneo,
Concernant les droits sous unix, un peu de lecture ici, http://fr.wikipedia.org/wiki/Permissions_Unix/, il n’y en pas pour longtemps à lire.
Je ferai la même remarque que Damien sur d’autres messages et sujets similaires. Il faut à minima maîtriser les droits sous unix pour mettre en place ce module l’idée étant de comprendre ce que vous faîtes quand vous modifiez les droits sur vos fichiers, car cela touche directement à la sécurité de votre site.
Salutations
Ah merci, un peu de soutien, j’en avais marre de passer pour le grand-méchant-loup-moralisateur-qui-veut-pas-que-j’installe-son-module-pourri 😉 (Bon, dans les mails d’insultes que je reçois c’est un peu plus virulent que ça, mais je ne préfère pas recopier, on ne sait jamais, des fois qu’un enfant passe ici ^^)
Pareil pour moi 😉
Pas de validation si on ne clique pas sur « Retour Boutique »
Je vais essayer 2 trois trucs et je reviens…
Sinon bravo pour le BO !
et on ne le revis jamais…
Bonjour,
Je vais peu-etre poser une question à côté de la plaque mais le CMB avec Citelis n’utilise t-il pas du SIPS/ATOS, et dans ce cas pourquoi le CMB n’est-il pas présent sur le module (qui m’a l’air bien sympa) ?
Merci et bonne continuation pour ce projet !
Bonjour,
Les banques préconfigurées sur le module le sont en tant qu’exemple et pour pouvoir tester rapidement en mode démonstration le module pour voir s’il répond à vos besoins.
Si tu as pris le temps de lire la documentation, au moins le sommaire, ce qui est un impératif avant une demande de support, tu as probablement remarqué la présence d’une section « Ajout d’une nouvelle banque au module ».
N’étant en aucune façon rémunéré sur ce module, tu comprendras que je ne peux pas passer mon temps à surveiller quelles sont les banques qui exploitent la solution de paiement ATOS. Rien qu’essayer de dénombrer de manière honnête le temps que j’ai passé en développement pour la version 1.0 et la 2.beta actuelle me prendrait déjà une bonne soirée ;-).
Comme expliqué précédemment, ce module n’a pas été créé pour une banque en particulier, il a été créé pour respecter les spécifications ATOS 600, toute banque respectant ces spécifications est compatible si elle ne nécessite pas de spécifications supplémentaires qui lui serait propre.
Merci beaucoup pour l’info !
Développant aussi quelques solutions libres, je connais bien le soucis, mais si ce module me convient je n’oublierai pas de faire un petit don, en espérant que les autres feront de même !
Bonne continuation !
Bsr Damien,
Bravo encore pour ton boulot, j’essaye de tester la version2 (pour ma part la version 1 fonctionnait niquel aucun soucis d’instal et de réglages) pour ce qui concerne la version2, lorsque je clique sur « payer par carte » je retourne sur la page d’accueil de mon site,j’ai bien mis tous les chmod, je ne vois pas ou est le pb .
je fais mes essais sur un site de test qui est un sous domaine de mon site,je ne pense pas que le pb vienne de là mais peut être as tu une idée.
Bonne soirée
D’après ce que tu me décris, il s’agit des templates qui ne sont pas à jour (l’url de la page de redirection vers la banque a changé entre les deux versions pour séparer les trois fichiers contrôleurs dans leur propre dossier pour faciliter la mise en place de stratégies de sécurité renforcée).
Trois cas me viennent à l’esprit :
– les templates n’ont pas été remplacés lors de la mise à jour du module => réécraser les fichiers templates avec ceux de l’archive du module 2.0.b1 RC1
– la version compilée des anciens templates est toujours présente => supprimer tout fichier comportant « tgg_atos » dans le nom à l’intérieur du dossier /prestashop/tools/smarty/compile/ (ou supprimer tous les fichiers de ce dossier à l’exception de index.php si tu as la flemme de trier, ils seront automatiquement recréés dès qu’ils seront nécessaires)
– les templates de la version 1.0 sont présents dans ton dossier de thème (les templates du dossier de thème sont prioritaires sur ceux embarqués) => supprimer le dossier /prestashop/themes/votre_theme/modules/tgg_atos/ ou le mettre à jour en exportant les fichiers de thème, langue et image selon la procédure décrite dans le manuel ou en utilisant la fonction d’export scripté du B-O si ton système est Linux et que les droits sont suffisants pour que ce script fonctionne.
Je te remercie vraiement pour ton aide à une heure si tardive, c’était bien un pb de template ,j’ai tout viré et je n’ai plus le blocage; je continu les tests et j’affine les chmod ,et je pense que cela ça va rouler.
Encore merci
Bonne soirée
Bonjour,
Tout d’abord très bonne initiative.
Etant novice dans ce domaine, j’ai réussi à l’installer et à priori à le re-paramétrer en mode production, seulement sur le front office après avoir choisi paiement par carte bancaire, le message suivant apparaît :
« Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient. »
Je n’ai rien trouvé dans la doc à ce sujet…
Est-ce normal ? J’ai merdé quelque part ?
Merci d’avance !
Bonjour,
merci de lire la documentation avant toute demande de support : les informations sur les erreurs rencontrées sur le front office sont envoyées par mail à l’administrateur de la boutique.
Pour plus d’informations sur les erreurs, un mode de débuggage est disponible dans le back office (onglet avancé).
Cordialement, Damien.
Bonjour Damien,
Je viens d’installer le module sur ma boutique Prestashop effectué les pré-réglages et uploadé le certif de prod.
J’ai ce message d’erreur, sur la page ATOS, lorsque je choisi de payer par CB (juste après le clic sur le mode de paiement) :
Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient.
Une idée ?
Merci !
re-Bonjour,
Il s’agit juste d’un prob. d’accès aux fichiers, dixit, console de debug.
Problème apparemment résolu.
Vous pouvez supprimer mes deux messages.
Merci pour ce module, bonne soirée,
Tout d’abord félicitation pour ton module !!!
Je suis sur le point d’installer un module de paiement compatible mercanet mais j’hésite entre prendre ta version 1.0 et attendre la 2.0 stable.
Peux tu me conseiller?
Peut-être as-tu une date prévisionnelle pour la 2.0 ?
Cordialement
Bonjour,
aucun bug n’ayant été relevé depuis la sortie de la 2.0.b1-RC1, elle est maintenant considérée comme 2.0 stable release (RC dans 2.0.b1-RC1 signifie qu’elle est une release candidate, autrement dit que le développeur la considère lui-même comme stable mais la soumet à une phase de beta testing pour plus de sécurité).
Je n’ai pas le temps en ce moment, mais cela fera l’objet d’un ticket plus officiel.
Concernant la 1.0, elle est stable si vous n’avez pas besoin d’utiliser les thèmes exportés. Comme cette branche (1.x) n’est plus soutenue, et si personne ne souhaite en reprendre le développement (je ne vois franchement pas l’intérêt, je ne lui trouve aucun avantage par rapport à la 2.0 et elle comporte plusieurs défauts (cf CHANGELOG de la 2.0), les thèmes exportés ne sont pas nécessaires puisque leur intérêt réside dans la possibilité de mise à jour du module tout en conservant vos thèmes personnalisés.
Je mettrais probablement fin au support gratuit de la 1.0 lors de l’officialisation de la 2.0, ce qui signifie que vous pourrez toujours l’utiliser sans problèmes, même continuer à la télécharger gratuitement sur le blog (ce module n’a pas vocation à devenir payant puisque je considère qu’il fait partie des modules « essentiels » qui doivent rester gratuit), mais que je ne donnerai plus de mon temps gratuitement à répondre aux demandes d’aide.
Donc en résumé, je conseille fortement la dernière version 2.0.
Merci je vais donc installer le 2.0.
En tout cas félicitation pour votre travail formidable et pour votre réponse rapide malgré le fait que vous n’avez pas de temps libre en ce moment.
Bonne continuation.
Bjr,
Bravo encore pour ton boulot, le module fonctionne tres bien.
Dernière petite question, est il compatible avec un hébergement type Infomaniak?
Bonne soirée
A priori chez Infomaniak la fonction exec() est désactivée, donc ce n’est pas compatible avec ce module.
Il faut vous tourner vers un module ATOS PERL.
Cordialement
J’ai une question à propos de l’ID de transaction.
Que se passe-t-il quand cet ID atteint la valeur maximale au niveau de la table SQL (à savoir 999 999) ?
Reviens-t-il à la valeur minium définit dans la configuration du module ?
Cordialement
Par ailleurs, dans la documentation il est indiqué que la taille maximale de transaction_ID est de 6 chiffres alors pourquoi est-il défini en mediumint(9) dans la base de données ?
C’est encore moi, désolé de polluer ce post…
J’avais une mauvaise compréhension du fonctionnement de MySQL.
En effet, l’auto-increment du transaction_id repart à 0 si la date change.
Donc il n’y a pas de problème.
Je viens d’installer le module, ça marche très bien visiblement ! Un GRAND merci a toi 😉
Si ça peut aider, j’ai bien galéré a l’installer a cause des fichier bin que je transferais par filezilla en mode « automatique ». Il faut bien faire le transfert en mode « binaire » sinon cela ne fonctionne pas.
Félicitation !
très très beau travail.
Je ne comprend pas que tu reçoive des mails injurieux !! mais bon, même quand c’est gratuit les gens sont mécontents
En tout cas merci pour ce module qui m’évite de débourser 200€. Sachant qu’un module de paiement sur un e-commerce, on peut pas faire sans.
Encore merci
Bonjour Damien.
Bravo pour ton module qui fonctionne parfaitement pour un de mes clients.
Par contre pour un autre, je butte sur le message « Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient. »
Note : il manque un formulaire de contact sur ton blog !
Bonjour Damien,
Tout d’abord merci pour ce module.
J’ai un problème avec le paiement :
Au moment de la validation du paiement par CB, il m’indique que
« Sorry, no more CB payments can be processed today, bank server should be available again at midnight. »
Et me retourne une erreur 139.
Avez-vous déjà rencontré cette erreur ?
Merci
J’ai bien avancé et trouvé l’origine de l’erreur.
Le serveur qui posait problème était un serveur Mailclub en safe_mode.
J’ai du commenter la ligne 868 de tgg_atos.php
//$cmd .= ‘ 2>&1’;
C’est elle qui bloquait l’appel.
De ce que j’ai compris en cherchant sur Google, cette commande permet à priori d’envoyer les sorties standard et d’erreur du serveur au même endroit. Je pense que c’est le safe_mode qui gène cette commande.
Désolé, il s’agit de la même erreur que Guillaume pour le module version 1 (cf son post du 7 décembre 2010).
Filezilla envoi par défaut les fichiers en mode ASCII.
Il faut les envoyer obligatoirement en mode binaire (menu Transfert -> Mode de transfert -> Binaire)
En espérant que ça puisse en aider d’autre…
bonsoir, après être tombé sur le meme messsage d’erreur que julien (ci dessus) j’ai reprocédé à une installation en mode binaire.
je tombe maintenant sur l’erreur suivante
You don’t have permission to access /modules/tgg_atos/front-ctrl/payment-redirect.php on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Je ne comprend pas, j’ai schmodé ce fichier en 755 et cela devrait fonctionner ainsi. Quelqu’un aurait il eu un problème similaire?
merci d’avance
oups désolé pour mon message precedent qui provenait….d’une erreur de schmodage évidemment.
Désormais je bute sur le fameux « « Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient. »…
Bonjour,
Le message « Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient. » est affiché dans deux cas :
Si ta boutique ne peut envoyer de mails et que tu es dans le deuxième cas, tu peux aussi passer la boutique en maintenance (après avoir inséré ton IP et celui du ou des serveurs bancaires dans les IP de maintenance pour que le retour automatique/silencieux fonctionne) et activer le mode débug du module pour que des informations sur l’erreur rencontrée apparaissent en haut de page (attention aux thèmes dont les CSS peuvent masquer les informations de débug).
Bonjour, ton module sera-t-il compatible avec la version 1.4 de Prestashop ?
Aucune idée, à vous de vérifier, je n’ai pas trop le temps de m’amuser à suivre les évolutions des bêta-versions de Prestashop en ce moment.
Passez tous un bon réveillon de nouvel an !
Je commence à tester la version 1.4 RC2 de Prestashop, je viens de terminer l’install avec tgg_atos.
Au point où j’en suis, j’ai pu faire un paiement test avec retour boutique qui s’est bien passé (paiement accepté).
Pour ça, j’ai dû changer l’onglet de tgg_atos en $this->tab = ‘payments_gateways’; ce qui m’a permis d’activer le module pour les pays,
et activer smarty v2 au lieu de v3.
Par contre la dernière manip’ m’a fait planter d’autres trucs dans la boutique (visiblement le module panier n’est plus compatible smarty v2, une bête histoire de test à = au lieu d’==). L’idéal serait donc d’avoir les templates tgg_atos en v3. Je ne connais pas smarty, je ne me rends pas compte de la charge que ça représente, en plus de la rétro-compatibilité…
En tout cas, merci Damien pour ton super travail! C’est propre et facile à utiliser (modulo les droits mais en bon tux-addict, ça ne me fait pas peur 🙂 )
Je continuerai à donner l’avancement de mes tests, si ça vous intéresse.
Bonjour Fred, merci beaucoup pour ces infos, j’utilise smarty depuis bien avant que ce moteur tpl soit populaire donc ca ne devrait pas poser de problemes 😉
J’attendais que l’architecture de la branche 4.x de Prestashop se stabilise avant de passer du temps a fournir une version officiellement compatible 4.x, là j’ai quelques galeres de logement (apres 4h de trajet aller-retour pour le travail, peu de motivation a travailler le soir ou le week end), mais j’emmenage courant fevrier donc je devrais redevenir productif en mars 🙂
Je viens de découvrir un bug, si le montant total est inférieur a 1€ (dans mon cas 0.4€) l’apelle au formulaire ( getPaymentForm() ) retourne une erreur.
Si ça peut t’interesser… 😉
Juste pour info c’est visiblement Atos qui bloque les transaction inférieur a 1€, mais ca serait peut-etre bien d’avoir une gestion au niveau du module.
Oui je sais, c’est planifié depuis la V1, mais le manque de temps et d’argent (plus de 700 telechargements a ce jour, une bonne centaine d’heures de developpement, des dizaines d’heures de support et un seul don, cherchez l’erreur…)
Ma priorité va pour l’instant a la creation d’un site dédié au module favorisant l’entraide (un forum pro et un forum « bac a sable », une FAQ, une documentation wiki…).
Cela dit rien ne t’empeche d’ajouter une simple condition pour afficher ou non le module lors du choix de paiement en editant le hookPaiement du module. Cela peut meme etre fait en modifiant simplement les templates. Pour ma part j’attends d’avoir le temps d’ajouter les options :
– restreindre l’utilisation du module a des panier d’au moins x€
– idem pour chaque paiement en plusieurs fois sans frais
Salut, vraiment très bon module, et très facile a paramétré
si on lis bien la doc 😉 J’ai cependant une petite question Il
semblerai que le module ne gère pas les code retour 05 ? (payement
refusé) Dans la gestion de mes commande je ne vois pas : Payement
refusé ou payement en attente ? (je sais pas si c’est normal car
avec mon autre solution de payement j’avais un petit message
m’indiquant que la personne était allez sur la page de payement
mais n’avais pas payé) Super taff sinon, respect
Oui en effet, j’ai choisi de différer quelque peu des solutions ATOS habituelles : lorsque l’utilisateurs revient avec une annulation ou un paiement refusé plutot que de convertir son panier en commande annulée j’ai pris le parti de laisser l’utilisateur conserver son panier et de le rediriger vers le choix des modules de paiement, vous avez ainsi plus de chance qu’il finalise tout de même son achat via un autre mode de paiement.
Ces codes (05,06,75…) peuvent etre retrouvés dans les logs si vous desirez vous en servir a des fins statistiques, s’il vous faut en plus le contenu du panier, le module propose des hooks auxquels des modules annexes peuvent se greffer pour alimenter une BdD avec les donnes des rerour de banque. (Ce systeme d’extension vous permet d’ajouter vos propres fonctionnalités tout en continuant a mettre a jour le module en lui-meme)
Bonjour, Super module, merci! Je l’ai installé en demo en y
ajoutant Citelis. En fait je transfere le paiement CB d’une
boutique encore en cours OSCommerce vers une nouvelle avec
Prestashop. En reprenant les fichiers parcom (demo et prod), je me
demande ce que je dois faire des champs AUTO_REPSONSE_URL et
RETURN_URL qui sont parametrés sur les parcom oscommerce (vers
call_response.php et call_autoresponse.php) ? Merci pour votre
aide! Stephane
Salut,
C’est le module qui gère le fichier parmcom contenant l’ID marchand dans le nom de fichier, il est ecrit a chaque validation de la page de configuration du module. Quand a ces deux clés de configuration pour les adresses de retour elles sont générées a la volée et transmises en parametre lors de l’appel à l’executable, leur valeur depends de la configuration du domaine de retour et du protocole de retour sur la page de configuration.
En un mot : tu te compliques la vie 😉
Merci Damien, j’aurais du me douter en voyant la saisie du fichier logo dans le config du module….
Décidément une bonne surprise ce module.
Merci 🙂
C’est dans cette intention qu’il a été créé : proposer un module simple d’utilisation et d’installation ne necessitant pas de connaissance particulière concernant ATOS, ne nécessitant que des connaissances web/hébergement standards.
Pour finir d’etre lourd, je viens de passer en prod et je veux finaliser la question des droits fichiers et repertoires.
Je suis peut-etre miro mais j’ai pas trouvé :
« La tarball contient les droits utilisés lors du développement sur une offre mutualisée pro OVH, si vous souhaitez les conserver extrayez directement son contenu sur le serveur (tar -xzf
nomdufichier.tar.gz). »
Comme je suis hébergé par ovh…et que je ne suis pas le pro des droits ‘relatifs’, j’avoue que j’aurais bien profité de traduction en chmod…
Merci encore.
Salut Damien Ca marche au poil en prod ! En 2 coups de
cuiller. Reste juste cette histoire de droits au sujet desquels je
suis sensible et j’aimerai vraiment gérer ca comme il faut. Un post
a toi au dessus m’a rendu un peu parano…Dommage d’utiliser un
module comme ca pour laisser une porte ouverte… Si tu tombes sur
ton fichier de droits ovh et que tu veux bien donner encore quelque
minutes de ton temps, je veux bien…
Merci a toi.
Comme indiqué a de multiples reprises, les droits que
j’utilise sur l’hebergement OVH sont dans la tarball. L’utilisation d’une tarball fait partie des competances LAMP de base et est hors sujet ici.
Des centaines (et je suis en dessous de la réalité) de pages traitent de ce sujet sur le net, google est votre ami.
S’il n’est pas interdit d’etre débutant, un minimum d’implication personnelle est tout de même requise.
Hmmm..l’animal est irascible…;-)
J’etais persuadé à la lecture de ta phrase que ces droits étaient contenu dans un fichier detenu par toi et oublié dans le pack:
« La tarball contient les droits utilisés lors du développement sur une offre mutualisée pro OVH, si vous souhaitez les conserver extrayez directement son contenu sur le serveur (tar -xzf nomdufichier.tar.gz) ».
Je sais ce qu’est une tarball et je cherchais dans ton archive un fichier contenant la description des droits!
Erreur!! En relisant plusieurs fois, j’ai enfin compris: c’est en décompressant directement l’archive du module a son emplacement sur le serveur ovh qu’on profite automatiquement des droits portés par les fichiers dans l’archive!!!
Mauvaise compréhension donc due je dirais pas a un manque d’implication mais le manque d’habitude de gymnastiques issues du monde unix…
En tout cas je m’y colle de ce pas!
merci.
Oui, il faut vraiment s’y mettre car s’en passer c’est perdre beaucoup de temps, cela fait partie de pré-requis pour tout webmaster ou developpeur en environnement LAMP, impossible d’atteindre une productivité professionnelle sans ces outils.
Salut, Probléme en FO : Le paiement par carte est
indisponible jusqu’à demain, nous vous prions d’accepter nos
excuses pour cet inconvénient. Debug : array ‘cmd’ => string
‘C:/Documents and
Settings/mcaux/Bureau/Prestashop/prestashop_local/modules/tgg_atos/bin/request
« amount=19742 »
« automatic_response_url=http://127.0.0.1:8888/Prestashop_local/modules/tgg_atos/front-ctrl/payment-autoresponse.php »
« cancel_return_url=http://127.0.0.1:8888/Prestashop_local/modules/tgg_atos/front-ctrl/payment-return.php »
« currency_code=978 » « customer_id=2 »
« customer_email=mcaux@axecibles.com »
« customer_ip_address=127.0.0.1 » « language=fr »
« merchant_id=038862749811111 » « normal_return_url=http://127’…
(length=685) ‘status’ => int 1 Je suis en local, la méme
erreur sur serveur distant. Pourquoi ? Merci d’avance !
Problème résolu : Le chemin d’accès au fichier du module
est trop long….
Et la presence d’un espace dans le chemin ne devait pas aider non plus, c’est a eviter absolument pour fuir les ennuis. Surtout maintenant que windows gère les liens symboliques on peut facilement éviter ce cas de figure (cf commande shell windows MKLINK, diponible depuis Vista)
Bjr,
Le module fonctionne parfaitement chez moi depuis un mois.
Depuis la mise à jour en 1.3.6 le descriptif du moyen de paiement dans le front office est en anglais, je n’avais jamais eu ce soucis lors des mises en places précédentes,ayant remis les mêmes permissions et fait plusieur sinstall_désinstall le pb persiste.Sur un forum le pb a été soulevé (pb de fichier fr.php) je ne vois rien sur le mien!!Je viens donc ici chercher un début de piste de recherche.
Merci par avance!
Je me repond à moi même!
Il faut faire attention de bien effectuer les modifications dans le fichier fr.php se trouvant dans le dossier « mon thème ».
Suivre les instructions dans le tuto!
Testé, et ça marche parfaitement d’après les premiers tests, merci ! Et surtout bravo pour ce travail de qualité, bien pensé (je n’ai pas testé le paiement en plusieurs fois, mais cette fonctionnalité donne envie !).
Je viens de faire un petit don, et j’en referai un autre si il répond à toutes mes attentes en fonctionnement normal (en gros si il n’y a pas de perte de commandes suite bugs).
3ème mail que je reçois avec « Error in call parameters structure (invalid amount length (0)) « …
Une idée ?
Oui, il s’agit des commandes a moins d’un euro qui ne sont pas gerees par Atos. Si votre boutique est concernee par ce cas specifique il faut filtrer ces commandes depuis le hookPayment, etant donné le nombre de boutiques concernees cela cera integré nativement dans la release stable 2 a venir.
Merci pour la réponse. Mais passer une commande à moins de 1€ est impossible sur mon site le plus petit produit fait 2€, et il y a les frais de port en sus… Je vais faire plus de tests on verra 🙂
Bonjour,
Je sais pas si votre problème est réglé
J’ai le même souci. Je crois qu’il y a un souci quand le client fait un aller-retour sur la page précédente; Ca retourne une valeur ‘0’ et donc cette erreur. Mais la transaction se déroule normalement malgré tout…
Si vous avez une idée? Merci pour tout et ton super module.
Bonjour,
Je ne saisis pas bien votre problème, il me faudrait un peu plus d’explications.
De plus, la version 2 RC1 est obsolete, la version actuelle est la RC3 et une preview de la RC4 (elle integre le patch 1&1) est disponible depuis les commentaires de la RC3.
Pour ce qui est du bug sur les montants trop faibles, il est corrigé depuis la RC3 (cf changelog)
Bonjour,
Je voulais tester ton module avec une version 1.4.0.10 de Prestashop.
Mais avant même de faire quoi que ce soit j’ai l’erreur suivante dans la partie administration des modules :
Erreur(s) de parsing dans le(s) module(s)Aurais tu une solution pour palier à ce problème ?
Merci d’avance
J’avais pas vu que j’avais remis le « display_errors » à « off ». Du coup j’ai une erreur un peu plus parlante :
Warning: file_get_contents(/****/public-html/***/modules//tgg_atos/tgg_atos.php) [function.file-get-contents]: failed to open stream: Permission denied in /****/public-html/***/classes/Module.php on line 372C’est bon j’ai trouvé. Certains fichiers du module n’avaient pas les bons droits d’accès (surement perdu à la copie des fichiers). Il fallait mettre les droits en lectures sur les fichiers php pour que prestashop puisse les utiliser.
Je me suis permis de répondre moi même à mes questions sur ton blog pour que Google référence la solution.
Allez je vais faire joujou avec ton module. 😉
Merci
Bonjour, tout d’abord chapeau Damien ! Pour le travail d’intégration, le tps passé au bénéfice des autres. En ce qui me concerne des choses fonctionnent, d’autres non.
Précisions : hébergement OVH en mutualisé, serveur PHP en safe_mode = OFF et solution de paiement E-transactions du C.A.
J’ai besoin de tes lumières, si tu le veux bien : je me suis cassé les dents toute la journée mais là je bloque. J’ai compris le cheminement des données, donc l’intérêt de l’appel du fichier « payment-autoresponse.php ». Je fais vite car mes yeux sont en train de me quitter devant l’écran ..!..
Il y a 2 choses : est-ce normal d’avoir un caddie vide ? >> caddie(0) cf mode Debug… bon à la limite c’est pas le plus urgent, ou alors j’ai loupé un épisode…
Surtout : les emails de confirmation (client + admin) ne sont envoyés que si le client clique sur RETOUR BOUTIQUE. Pareil pour la gestion de stock, je crois : c’est cavalier non ? Si le client ferme l’onglet ou le navigateur ? Comment intégrer tout ça dès la validation de la commande par la banque, donc en AUTORESPONSE ??? Je sais qu’il s’agit d’un dialogue serveur/serveur mais comment récupérer ce paquet de variables ($_POST[DATA] ???) De plus il y a la piste de ton « Hook tggAtosOrderConfirm » mais j’avoue ne pas tout capter.
Gros merci à toi ou aux autres qui pourront peut-être m’aider, en plus je pense que ce n’est pas si compliqué que cela !!
Good Night Gentlemen
Bonjour,
Pour le caddie c’est normal : les informations du panier ne sont pas envoyés a atos. Idealement ils devraient l’etre pour avoir plus d’informations dans les logs en cas de soucis, mais serialiser un panier n’est pas si simple, il faut prendre en compte les declinaisons et personnalisations de produit.
Concernant le non envoie de mail sans retour client depuis le site de banque c’est effectivement cavalier, mais cela n’est pas du au module, tu dois avoir un probleme d’installation, ou alors tu es en maintenance et tu as oublier d’ajouter l’ip de la banque aux IP de maintenance prestashop, car le module gere tres bien tout cela.
Très bon dev en tout cas je souhaité te féliciter 😉
Par conte j’avais quelque question.
Savoir s’il était possible lorsque quelqu’un va sur la page de payement afficher dans l admin (onglet commande) quelques chose genre : en attente de payement. et si le payement a bien été effectué changer l’état par : Paiement accepté. comme ca cela permet de savoir qui est allez jusqu’à l’étape de payement et a pas réussi pour une raison X ou Y et pouvoir le relancer par la suite ?
Je serai bien sure prêt a faire une donation si cela était possible
cordialement
Bonjour Tatouine,
Cela est en effet possible. J’ai choisi de ne pas creer de commande en erreur lors d’un refus de banque pour que le client ne perde pas son panier et puisse repartir rapidement en paiement via un autre mode de paiement si disponible sur votre boutique, ceci afin d’ameliorer le taux de conversion.
Pour obtenir un rapport sur les retours refuses, deux moyens :
1- les logs
2- la creation d’un module se greffant sur le hook de reponse de la banque que met mon module a disposition des autres. J’ai mis en place ce systeme de hook pour eviter que chacun modifie le module selon ses besoins, j’espere ainsi que petit a petit de plus en plus de modules gratuits viennent completer le mien pour combler les manques, car chaque boutique est differente et a ses propres besoins.
Merci bien pour la reponse mais je pensais plus un truc du genre
Quand on envoie quelqu’un sur la page de payement sa met le en : en attente de payement
Mais s’il annule ou mauvais payement ça laisse sur : en attente de payement mais si ça réussi alors changement de statut : Paiement accepté.
bonjour
je teste ton module sur la version 1.4 RC4 de ps sur windows et xampp 1.7.4 cela ne fonctionne pas , pas d’affichage en mode teste., en mode debug l’affichage est audessu du site . et la cela fonctionne si on click sur les icones.
merci pour ton module.
Bravo pour ce super module.
J’ai rencontré 2 problèmes, dont le premier solutionné :
1. Résolu : si utilisation du même contrat de vente a distance, un doublon dans le transaction id donne une erreur (page jaune d’erreur atos). j’ai donc modifié l’increment dans la base de données pour le faire demarrer à 100000 pour le premier site, 200000 pour le second… (sans voir qu’on pouvait faire cela par le back office, la honte 😉 )
2. Comment configurer le capture day pour un paiement en une fois ? Cela permet d’envoyer la transaction en banque plus tard (jusqu’à 7 jours sans perte de garantie 3D secure, jusqu’à 90 jours si pas de 3D secure installé ou avec perte de la garantie). On ne débite ainsi pas la carte tout de suite et on gagne en frais en cas d’annulation, ou on débite le client à l’expédition seulement.
Autre question : J’ai retiré la clé primaire dans la base pour la date, qui ne me paraît pas utile. Je me trompe ?
Encore merci et bravo pour ce module très bien fait !
La clé sur les deux champs est necessaire car c’est elle qui fait en sorte que l’id de transaction retourne a sa valeur de depart chaque jour. Sans elle, le module tombera en panne apres 999998-(id de depart) affichages du formulaire.
Bon, cela laisse tout de meme de la marge 😉
oui ça laisse de la marge 😉 mais bon je vais re modifier ça.
en ce qui concerne le capture day, est-il possible le paramétrer ? si oui, peux-tu m’indiquer où le faire ?
encore merci !
Bonjour,
J’ai installé votre module sur ma boutique et j’ai le message suivant :
Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient.
Je pense que cela doit venir des droits sur les fichiers mais j’ai également un serveur mutualisé chez OVH. Donc logiquement il ne devrait pas y avoir de soucis à ce niveau non ?
Merci.
Désolé pour le dérangement.
Solution trouvée : grâce au mode Debug. C’était les permissions du dossier bin.
Super module.
Bonjour à toutes et tous,
Encore une fois merci pour ce module.
EDcod disait un peu au dessus qu’il avait réussi à résoudre un problème de page jaune lié à l’utilisation d’un même certif. sur deux sites, et ce, en démarrant les transaction_id à 100 000 sur le premier site et à 200 000 sur le second…
De mon côté, je n’y arrive pas ! J’ai bien renseigné les transaction id mais j’ai toujours une page jaune sur le deuxième site. Le premier site fonctionne quant à lui très bien.
Je n’ai pas d’erreur en mode debug par contre je lis avec étonnement : transaction_id=0 ca ne devrait pas être à 200 000 ? Si oui comment corriger ? une idée ?
Un grand merci d’avance !!
Problème résolu : la table ps_tgg_atos_transactions_today n’était pas présente en base de données … ! la première commande ayant retourné une erreur sur un id de transaction commun la table n’a jamais du être crée.
Bonjour,
La non creation de la base est en effet un probleme majeur. Je suis interessé par toute information a propos de la configuration du serveur pour pouvoir determiner la cause de non fontionnement et corriger le module.
Il faudrait tenter une desinstallation reinstallation et voir si la table a bien ete cree et consulter les logs sql sinon.
Si la procedure d’installation est incapable de creer la table, vous pouvez la creer manuellement. Je vous proposerai bien mon aide mais j’attends toujours que France Telecom daigne effectuer le cablage de mon nouvel appartement vers Free…
bonjour
j’ai trouve ton interface super mais sur la derniere version 1.4 les icon des carte ne s’affiche pas dans la fenetre prestashop ,elle s’affiche qu’n mode debug et fonction.
cordialement stephane
continue c’est super.
yo!
Merci Damien pour ton script, ça sent le gros travail.
Je dois avoir fait un truc « Mal », pasque j’ai une « sale » erreur 🙂
Fatal error: Uncaught exception ‘SmartyCompilerException’ with message ‘Syntax Error in template « /home/chroot/pshopUser/_my_site_name/prestashop/themes/prestashop_alt/modules/tgg_atos/tpl/tgg_atos-front-payment-redirect.tpl » on line 2 « {include file=$tpl_dir./breadcrumb.tpl} » – Unexpected « / », expected one of: « { » , « $ » , « identifier » , INTEGER’ in /home/chroot/pshopUser/_my_site_name/prestashop/tools/smarty/sysplugins/smarty_internal_templatecompilerbase.php:431 Stack trace: #0 /home/chroot/pshopUser/_my_site_name/prestashop/tools/smarty/sysplugins/smarty_internal_templateparser.php(2855): Smarty_Internal_TemplateCompilerBase->trigger_template_error() #1 /home/chroot/pshopUser/_my_site_name/prestashop/tools/smarty/sysplugins/smarty_internal_templateparser.php(2920): Smarty_Internal_Templateparser->yy_syntax_error(37, ‘/’) #2 /home/chroot/pshopUser/_my_site_name/prestashop/tools/smarty/sysplugins/smarty_internal_smartytemplatecompiler.php(51): Smarty_Internal_Templateparser->doParse(37, ‘/’) #3 /hom in /home/chroot/pshopUser/_my_site_name/prestashop/tools/smarty/sysplugins/smarty_internal_templatecompilerbase.php on line 431
Quelqun a déjà vu ça ?
Je fais mes tests sur une 1.4 trunk.
J’ai désactivé la compilation forcée et le cache smarty, toute la partie CCC est en fonctionnement par défaut, et pas de cache global.
Je ne reçois pas de mail pour cette erreur.
Le theme prestashop_alt est le nouveau thème gratuit proposé sur le prestastore (2 colonnes).
La page qui donne cette erreur est celle juste après le choix du type de paiement (qui me montre bien le paiement normal/2x/3x) :
modules/tgg_atos/front-ctrl/payment-redirect.php
(au passage elle n’appelle pas le footer du theme on dirait).
Que dire de plus ?
Ah oui, j’ai lu sur le forum que ça n e fonctionnait pas avec smarty 3… page blanche.
Pas cherché mongtemps, mais pas trouvé où chager la version utilisée. Dans config/smarty.config.inc.php, ça a l’air d’être le 2 par défaut.
Merci !
La version actuelle n’est pas compatible 1.4 semble-t-il, je corrigerai cela dès que possible, malheureusement France Telecom fait comme toujours chier son monde quand il s’agit de cabler une ligne adsl chez leurs concurrents et je poireaute depuis un mois dans mon nouveau logement sans Internet…
Si vous voulez que je reprenne plus rapidement le travail sur ce module, jetez des oeufs pourris sur les boutiques Orange 😉 (ca ne changera rien mais ca défoule !!).
Gracias Damien.
« Patience et longueur de temps font plus que force ni que rage » – Jean de la Fontaine
Courage pour cette bien connue partie de ping-pong ! 🙂
Chez nous, les nains, ont dit « Patience et longueur de pioche font plus que les haches » – Naheulbeuk, Pen of Chaos.
Bon, après presque une heure accroupie avec une lampe torche dans la bouche, un tournevis dans la main droite et mon multimètre dans la gauche, la jolie petite FreeBox Révolution affiche enfin l’heure (tout ça pour juste savoir l’heure me direz vous ?).
Un peu de détente ce soir, ensuite je reprends le développement, promis 😉
Bonjour,
J’ai installé le module sur ma nouvelle boutique, tout marche, je rentre mon numero de carte bancaire (en mode test) et j’ai un message me disant :
« Votre paiement n’est pas accepté par votre établissement financier.
Nous regrettons de ne pas pouvoir donner une suite favorable à votre demande. »
Est-ce normal parce que je suis en mode de TEST ?
Sinon d’où viendrait le problème ?
Merci
Bonjour,
Merci de lire la documentation ATOS concernant le mode démonstration, car je n’ai pas l’autorisation de diffuser celle-ci (ni le temps de m’amuser à répondre aux personnes qui ne prennent pas le temps de lire les documentations fournies avant de demander de l’aide, pour cela il existe un site dédié : commentcamarche.net, le paradis des boulets du net).
Bof… la parenthèse ne me semble vraiment pas nécessaire…
Tu devrais être de bonne humeur, pourtant ! 😉
Si, nécessaire dans le sens où il faut malheureusement très régulièrement rappeler aux utilisateurs d’une solution open-source gratuite que lire la documentation AVANT de faire une demande de support n’est pas facultatif.
Ainsi que de vérifier, dans la mesure du possible, si la même question n’a pas déjà trouvé une réponse auparavant…
Je ne sais pas si tu imagines le nombre de message que je dois modérer qui n’ont aucun rapport avec le sujet…
Suis-je censé, un exemple parmi tant d’autres, apprendre à tous les débutants (dont, je remarque, une forte majorité se considère comme professionnels ^^) comment utiliser un logiciel FTP juste parce que j’ai décider d’essayer de combler un manque dans les modules « de base » Prestashop ?
Personnellement j’ai une réponse toute trouvée et la réponse est non. Pour rappel, ce module est destiné à des personnes ayant des aptitudes dans la configuration de l’OS ciblé, la mise en oeuvre et la maintenance de solutions d’hébergement web, la gestion SGBD, et surtout une extrême conscience des problèmes de sécurité que pose l’exploitation d’un site internet, un technicien web qualifié donc. S’agissant d’une solution de paiement, est-ce trop demandé ? Cela ne t’inquiète pas toi, de savoir que la prochaine fois que tu vas entrer tes références bancaires sur un site internet, ce sera peut-être un non initié qui aura mis en place la solution de paiement ?
Seulement voila, un grand nombre de personnes décidant de démarrer une activité commerciale en ligne sont persuadés que cela n’importe pas, et quand il y a un problème, c’est contre les personnes qui leur ont fourni des composants gratuits qu’ils se retournent (étrangement jamais contre leur banque, à qui ils ont payés la solution, qui pourtant leur propose probablement la pire solution de paiement que j’aie vu à ce jour : Atos ^^).
Je suis d’accord avec toi, cependant à leur décharge, trouver une réponse dans un commentaire d’article, ce n’est pas chose aisée.
Pourquoi ne pas faire une page FAQ ?
Tu pourrais la mettre à jour régulièrement en fonction des questions posées et renvoyer les internautes vers elle (concernant les questions propre à ton module, car si ça s’éloigne trop, genre : comment uploader un fichier sur mon serveur, ben là oui, je crois que y’a rien d’autre à faire que de ne pas répondre)
En effet, par contre étant donné que ce point est traité dans la documentation fournie avec le module, chapitre installation, cela reste amplement un abus de requête de support.
J’ai effectivement commencé à travailler sur un site dédié au module, plus adapté que ce wordpress (qui a l’origine devait me servir plutôt à publier des astuces, mais j’avoue le temps me manque…), mais vient alors le dilemme : chaque heure passée sur le site c’est une heure de moins pour ce module et pour les autres que j’ai commencés. De plus ce que je paye en hébergement, c’est ça en moins à la fin du mois… Et puis il y a le manque de temps, mon travail m’en prends beaucoup en ce moment (il faut bien que je mange 😉 je ne suis pas rémunéré sur ce module, si je compare les dons et le temps passé sur le module, j’obtiens une rémunération brute de moins de vingt centimes par heure ^^, si je compte l’hébergement je suis carrément en négatif), les deux déménagement successifs en 3 mois… D’ailleurs pour en revenir aux dons, je commence à avoir du mal à caser tous mes outils de devs sur mon disque dur, donc si une âme charitable a trop d’argent, elle peut m’offrir un nouveau disque dur 😛
Pour ce qui est de la page FAQ, si tu consultes la doc de la dernière version, tu verras l’apparition d’une section FAQ, avec seulement 3 points pour le moment, les 3 points les plus récurrents, mais cela devrait s’étoffer avec le temps.
Flemmard je suis, un peu,
Mais flemmard reconnaissant.
http://www.prestashop.com/forums/viewreply/402202/
Merci Damien ! :}
Oui j’ai vu tisc0, je te remercie 🙂
Dis-bien à ton patron combien de temps de dev est nécessaire pour créer un module en interne à votre entreprise et il verra qu’un don est loin d’être déraisonnable aux vues des économies réalisées 😉
Est-ce moi ou mes messages sont supprimés ?
Il ne s’agit pas de suppression des messages mais de mise en attente pour modération pour éviter que ce blog ne ressemble rapidement aux forums de Comment Ça Marche… 😉
Salut Damien,
J’ai installé avec succès ta solution (v2 b1 rc1) et en suis plus que satisfait. D’ailleurs une rétribution va suivre le mois prochain (de ma poche, j’en parle même pas au patron…) car je sais reconnaitre le travail, la compétence et surtout le partage.
J’utilise PS 1.3.5, tout d’abord ai-je intérêt à faire évoluer le module ou l’as tu juste adapté à PS 1.4 ?
Pour les transactions, je souhaite passer en mode de capture « VALIDATION » et non « ANNULATION » qui est par défaut. Cela me permet de proposer le débit à l’expédition et surtout de gérer les erreurs de stock. J’ai ajouté ces lignes au fichier parmcom.e-transactions :
# Mode de capture (validation auto ou manuelle)
CAPTURE_MODE!VALIDATION!
# Nombre de jours pour valider une transaction
CAPTURE_DAY!6!
Cela fonctionne au niveau bancaire et j’ai effectivement 6 jours pour valider une commande dans le back-office de ma banque. Seul problème, ton module ne semble pas être adapté à ce mode de validation et, alors que la transaction s’est bien faite, je reçois un email « erreur de paiement » en tant qu’admin, et le client lui, ne reçois pas sa confirmation de commande. Je vais aller voir dans « tgg_atos.php ».
Merci de ton aide, à bientôt
Guillaume
Bonjour,
J’ai installé avec succès ta solution (v2 b1 rc1) et en suis plus que satisfait. D’ailleurs une rétribution va suivre le mois prochain (de ma poche, j’en parle même pas au patron…) car je sais reconnaitre le travail, la compétence et surtout le partage.
J’utilise PS 1.3.5, tout d’abord ai-je intérêt à faire évoluer le module ou l’as tu juste adapté à PS 1.4 ?
[…]
Cela fonctionne au niveau bancaire et j’ai effectivement 6 jours pour valider une commande dans le back-office de ma banque. Seul problème, ton module ne semble pas être adapté à ce mode de validation et, alors que la transaction s’est bien faite, je reçois un email « erreur de paiement » en tant qu’admin, et le client lui, ne reçois pas sa confirmation de commande. Je vais aller voir dans « tgg_atos.php ».
Le support de ces fonctions a été ajouté dans la version 2 b3 rc3.
De plus cette version corrige le bug lors de panier au montant trop faible (par exemple moins d’un euro ou de cent yens). Pour le règlement du mode de capture, tu n’auras avec cette version pas besoin de modifier un fichier de paramètre, les variables CAPTURE_MODE et CAPTURE_DAY sont directement configurables sur la page de configuration sous les noms Mode de capture et Délai de capture pour la version française.
J’en attendais pas moins de ta part : super ! Rdv semaine prochaine pour honorer ma promesse 😉
» es variables CAPTURE_MODE et CAPTURE_DAY sont directement configurables sur la page de configuration sous les noms Mode de capture et Délai de capture pour la version française. »
Là je fais face à un mystère car ces paramètres sont inexistants dans mon back-office… quel onglet est sensé être concerné ? J’ai pourtant correctement désinstallé et supprimé la « v2 b1 rc1 ». Je vais creuser car dans le fichier de traduction française il y a bien mention de ces variables…
As-tu bien vidé les caches de Smarty apres avoir mis a jour le module ? (c’est a faire pour chaque mise a jour de module utilisant des templates sous Prestashop)
Oh punaise le newbie… comme quoi on en apprend tous les jours ! Donc c’est nickel ça fonctionne ! J’avais déjà entendu parler de ça mais n’avais jamais vidé le cache Smarty en question.
Sinon je viens de te faire un don de 20 € – c’est pas grand chose mais j’invite les utilisateurs de ton module à le faire car tu fais du bon boulot.
Le BO fonctionne mais j’ai malheureusement toujours ce problème gênant de mauvaise notification par email :
Admin (moi) > « Une erreur est survenue lors du paiement de votre commande. »
Client (moi pour les tests) > rien
Pourtant la transaction est effective puisqu’elle apparait dans le BO de ma banque (gestion des encaissements) D’ailleurs j’ai voulu faire d’une pierre 2 coups et tester le paiement en 2 fois : cette fonction est-elle opérationnelle ? (côté bancaire il y a bien le dispatch des échéances) Par contre j’ai l’impression que le mode de capture que j’ai passé à « VALIDATION » n’a pas été pris en compte car l’état de la commande est « envoyée en banque » et non « à valider (sans autorisation) »
Arf… on va y arriver !
Le paiement en 2 fois sans frais est tout à fait opérationnel pour autant que je sache, par contre il est absolument incompatible avec le mode VALIDATION, car si tu lis bien leur documentation, le mode paiement en plusieurs fois utilise la variables capture_mode est alors définie à PAYMENT_N, cette même variable qui doit être définie à VALIDATION pour utiliser le mode éponyme.
Pour ce qui est de l’erreur de paiement dont tu parles, sans plus d’informations je ne peux pas grand chose pour t’aider, tu peux toujours m’envoyer en message privé sur le forum Prestashop les identifiants de ta boutique et un accès hébergement (ftp, mysql, et si possible ssh) si tu veux que j’aille jeter un rapide coup d’oeil.