Bonjour à tous, j’ai pris ma journée pour faire les dernières vérifications avant d’empaqueter la release candidate 4.
Pas de nouveautés depuis la dernière Preview RC4 à part la correction d’un message qui n’était pas traduit.
Allez, pour fêter cette release dont la sortie a été trop souvent reculée, on se fait un petit récapitulatif en images ?
Le choix de la méthode de paiement a été entièrement réécrit depuis la RC3 pour une approche plus professionnelle envers le client.
L'interface d'administration elle-même a pas mal bougé depuis la version 1.0 avec la possibilité de configurer un montant minimum de paiement et le paiement différé.
Bon ok, pas grand chose de nouveau ici...
La configurabilité des domaines de retour permet de mettre en place des politiques de sécurité avancées.
Et bien-sûr, le paiement en plusieurs fois, avec possibilité de ne l'autoriser qu'à partir d'un certain montant de panier.
Le Changelog de la RC 4 :
– DEBUG: Génération de logs lors de l’installation.
– BUG/COMPAT: Nettoyage d’une occurence d’utilisation de SERVER_NAME qui a été oubliée lors de la modification de compatibilité version 2.0 BETA 1 RC 1.
– ALL: Ajout de la possibilité de restreindre l’accès aux méthodes de paiement en 1, 2 ou 3 fois à un montant de panier minimum.
– FRONT: Le module prévient maintenant l’utilisateur lorsqu’un changement de devise doit intervenir pour utiliser cette passerelle de paiement.
– BUG/COMPAT: Compatibilité avec le mode Guest checkout de Prestashop 1.4.
– BUG/COMPAT: Correction de l’option permettant l’utilisation des binaires ATOS par défaut du serveur.
– BO: mise en mémoire de l’onglet de configuration actif dans le back-office du module lors de la soumission du formulaire.
– COMPAT: utilisation d’un wrapper de compatibilité pour la création de dossier de thème pour la réécriture des fichiers de traduction.
– BO: Ajout de liens vers le blog et la documentation incluse.
Pour un module qui ne devait à l’origine n’être qu’un « minimal requis fiable » pour pouvoir exploiter gratuitement une passerelle Atos/SIPS et ainsi débuter une activité de vente électronique en limitant les frais nécessaires, devant simplement remplacer les modules gratuits truffés de bugs et failles qui existaient, je pense qu’il est actuellement le module Atos/SIPS pour Prestashop le plus complet, même parmi les modules payants que je connais.
Le module supporte toujours officiellement les version 1.2.5 et supérieures de Prestashop, mais je n’effectue plus de recette sur ces versions par manque de temps, ainsi il se peut que vous rencontriez des problèmes avec les versions de Prestashop antérieures à la 1.4, auquel cas laissez-moi un message avec une description sérieuse du bug rencontré, les versions en cause (Prestashop, PHP, Apache et MySQL), le système d’exploitation utilisé et je ferais de mon mieux pour vérifier cela rapidement et corriger si nécessaire (et si possible).
Cette nouvelle version m’a coûté pas mal de temps, alors si vous appréciez le travail, un petit don ne sera pas de refus :-).
Module ATOS/SIPS version 2.0 BETA 4 RC 4
– votre TrogloGeek adoré 😉
PS: Je recherche toujours une bonne âme pour améliorer la documentation.
Salut,
J’ai légèrement testé cette version sous Prestashop 1.3.1. Coté fichier de lang fr.php il faut mettre un P au lieu d’un p pour avoir la traduction.
$_MODULE[‘tgg_atos-front-hookPayment_16365edc296ea13ed82126fdcc57d5b8’] = ‘Payer par carte’;
$_MODULE[‘tgg_atos-front-hookPayment_5f93e9e400ef8e1fbf16a0b3f7c19aa5’] = ‘Payer par carte en 2 fois sans frais’;
$_MODULE[‘tgg_atos-front-hookPayment_3bcd0d346c89de1382913c21eca96eb0’] = ‘Payer par carte en 3 fois sans frais’;
En tout cas Merci pour ce module !!
Ok merci, les fichiers de langue ont changé de systeme de prise en compte de la casse depuis la version 4, je dupliquerai les entrées avec et sans casse pour que le fichier de langue de la stable release prenne bien en compte les deux cas.
Bonjour,
Quelle est la différence entre votre module, et celui-ci : http://sourceforge.net/projects/modatospresta/ ?
Merci d’avance.
Bonsoir,
Pour vous répondre, un peu de chronologie :
Ce projet dont vous parlez est une première tentative de portage des scripts d’exemple ATOS en un module Prestashop par meandmypresta. Le projet a été arrêté en 2008 à la version 1.3, non fonctionnelle puisque le retour automatique de la banque ne se faisait pas correctement car l’auteur s’appuyait sur la session du visiteur, inexistante dans ce cas de figure. Même erreur que la contribution ATOS pour osCommerce, l’un et l’autre projets ne sont fonctionnels qu’à condition de mettre sérieusement les mains dans le code et d’en remanier une bonne partie après avoir lu et compris la documentation ATOS concernant le développement d’une passerelle. De plus ce projet souffre d’autres défauts de conception:
non prise en compte de la langue (français uniquement)
non prise en compte de la devise (euros uniquement)
consommation inutile de n° de transaction ATOS
obsolescence programmée: nécessite un nettoyage régulier du fichier de n° de transaction pour que le module ne bloque pas le serveur dans une boucle récursive lorsque tous les numéros sont consommés
peu configurable
lacunes de sécurité
Pourtant dans ce projet, au crédit de meandmypresta, il y avait une idée fort intéressante : embarquer les kits de démonstration de toutes les banques compatibles ATOS 600 pour permettre de tester très facilement le module, pour peu que l’hébergement soit compatible avec les binaires fournis, sinon il suffit d’aller les chercher sur le site de la banque, et on est en démonstration très rapidement. Ainsi, même s’il n’a jamais été finalisé, ce module posait un concept très intéressant.
En 2010, il fut repris par neonec qui sortit une nouvelle version 1.3.5 sur le forum Prestashop, corrigeant certains défaut, mais sans pour autant finaliser le module en une version stable et pleinement fonctionnelle. Il fit un peu de support quelques temps mais ne sortit jamais aucune nouvelle version pour corriger les problèmes. Donc ici aussi de l’huile de coude est nécessaire.
Mon module est une décision de repartir à zéro avec des méthodes programmatiques plus modernes et un plus haut niveau d’intégration Prestashop, mais sans abandonner cette superbe idée de meandmypresta de faciliter l’essais en mode démonstration, permettant ainsi plus facilement de se décider ou sur la signature ou non du contrat VAD Atos avec sa banque.
N’étant pas moi même commerçant mais un pur développeur de métier, j’ai décidé d’interagir avec la communauté pour permettre aux commerçants de détailler leurs besoins et de participer à la spécification du module.
S’en est suivi un an de versionning depuis les premières bêta, puis la 1.0 et les bêta pré-2.0 auxquelles nous sommes actuellement.
La version actuelle n’est pas encore parfaite, par exemple certaines lignes du fichier de traductions françaises ne sont pas prises en compte par les versions de Prestashop antérieures à la 1.4 comme l’indique ci-dessus yoyo, et plus de retours utilisateurs seront nécessaires pour vérifier qu’il n’y a aucun autre vice caché.
Par contre je prends toujours en compte les bugs que l’on me rapporte et m’efforce de les corriger le plus rapidement possible.
Un bon nombre de prise en compte de fonctionnalités ATOS ont été ajoutées aux fils des versions, des éléments de compatibilité pour prendre en compte plus de plate-formes d’hébergements et de versions Prestashop.
Ensuite, forcément je serais tenté de vous orienter plutôt sur ma solution mais je ne suis pas vraiment impartial sur cette question je crois ;-)…
Les deux solutions sont gratuites et inter-compatibles, alors testez les deux et faites vous votre propre opinion.
Désolé, je me doute que vous auriez probablement préféré une réponse pré-machée, mais c’est le problème avec les développeurs libres : ils ne sont pas payés pour venter les mérites de leurs produits :-P.
Vous répondez parfaitement à ma question et je vous en remercie 🙂
Je vais dans un premier temps m’orienter vers votre solution.
Salut chef !
Une recherche sous Gooooogleu m’a fait tomber par hasard sur cette RC 4. Ravi de voir que le projet avance 😉
Par contre, le loooooong monologue que tu viens de faire, il faut, AMHA, que tu le mettes dans ta doc ! ca t’éviteras de te recoltiner ce bla bla à chaque fois ! ^l^
Pour la doc, si elle est dispo dans le téléchargement, je vais y jeter un oeil (sans garanti, hein 🙂 )
Savez-vous s’il est possible de ne pas autoriser l’accès au paiement aux cartes bancaires et IP africaines ?
Faut-il configurer le module, ou le paramétrer du côté de SIPS ?
Merci d’avance.
Ça, seule votre banque peut vous répondre. Par contre, si la banque vous fournit des paramètres à inclure à l’appel de l’exécutable request, là je pourrai vous indiquer la marche à suivre.
Bonjour Damien,
Merci beaucoup pour ce travail que vous fournissez bénévolement! J’admire votre générosité et cette webhumanité qui émane de vous!
Pourriez-vous me dire où puis-je trouver un tutoriel pour installer cette dernière version ? Dans le *.tar.gz ? J’avoue ne pas l’avoir encore téléchargé…
Cordialement,
Luc
Bonsoir,
Il n’existe pas (encore) de tuto, par contre les infos sur les permissions à appliquer aux fichiers sont dans la doc qui est dans la tarball.
—– à effectuer par un technicien qualifié —–
1. Extraire la tarball dans le dossier des modules Prestashop.
2. Obtenir de votre banque les exécutables binaires compatibles avec votre hébergement, remplacer ceux présents dans le dossier /bin/ du module.
3. Appliquer les permissions adéquates sur les fichiers du module.
—– à effectuer par un administrateur boutique —–
4. Installer le module sous Prestashop.
5. Configurer la banque à utiliser dans le module.
6. Effectuer une recette en mode démonstration en suivant la documentation ATOS. Bien vérifier que la commande est prise en compte dans le back-office même si l’utilisateur ne clique pas sur le retour boutique après obtention de la page de confirmation de transaction ATOS.
7. Effectuer les réglages voulus dans la page de configuration du module puis vérifier à nouveau le bon fonctionnement.
8. Basculer en mode Pré-production.
9. Effectuer la même recette qu’en mode démonstration mais cette fois-ci en utilisant une véritable carte (suivre une fois encore les indications de la documentation ATOS), même vérification.
10. Remplir le PV de recette ATOS conformément aux indications fournies par votre banque.
Cdlmt, TgG.
Merci pour ce super module!!
Je suis nouveau sous prestashop et apprend peu à peu les étapes pour rendre ma boutique fonctionnelle, seulement je me demandais si l’auto-réponse était activée d’emblée, si non que faut-il faire? J’ai un contrat avec ma banque, je fais les phases de test, mais je n’ai ni reçu le récap de ma commande ni l’annonce qu’une commande a été faite sur mon site, alors que presta et la banque se comporte comme si une commande avait belle et bien été passée.
J’ai résolu de nombreux petits pb grâce à vos posts, mais là j’avoue que je bloque un peu.
Qu’en pensez-vous? Merci d’avance
Bonjour,
l’auto-réponse est bien évidemment activée d’office, car la non prise en compte de celle-ci oblige à se synchroniser sur les journaux ATOS (ce que certains seront au final forcés à faire étant donné que l’auto-réponse d’ATOS n’est pas toujours super fiable, bien sûr eux vous répondront que le problème vient de votre serveur, mais ce n’est pas toujours de bonne foi !).
Pour ce qui est de vous répondre, encore faudrait-il apporter un minimum de soin et de sérieux à la description de votre problème : phrases construites et sans ambiguïté, énonciation des environnements et versions logicielles en cause…
Tout ce que je comprends de votre problème est que :
– la commande n’est pas prise en compte par Prestashop
– pourtant la commande est bien prise en compte par Prestashop
……….. ?!! What the frak ?
N’oubliez-pas que tout ce qui tourne autour de ce module, incluant les réponses à vos questions (en passe de devenir la consommation de temps #1 de ce projet), je le fais sur mon (maigre) temps libre et au détriment d’autres projets personnels, alors si vous réclamez de l’aide, mettez-y un peu de sérieux…
Test sous Prestashop 1.3.1 en mode pré-production sans souci.
Un fan de BattleStar Galactica.. +1
Merci pour le retour, j’en manque étrangement malgrès plus de 60 téléchargement de cette dernière version en dix jours… ?! Mais je pense que la grande majorité des utilisateurs ne font malheureusement de retour que s’ils ont un problème…
In cylons we trust… je pense qu’avec eux une bêta-test doit être plus simple 😉
Bonjour Damien
tout d’abord, je rejoins le commentaire de Luc : bravo pour votre générosité.
J’ai installé sans difficulté particulière votre module mais à l’usage, je rencontre la difficulté mentionnée dans la documentation : le chemin est trop long.
Et c’est là que je ne comprends pas ce qui se passe :
1) j’ai désinstallé le module grâce au lien idoine
2) j’ai supprimé le module
3) j’ai uploadé de nouveau le module et j’ai renommé le dossier : de tgg_atos, il est devenu tgg
==> et là, mystère le module n’apparaît pas dans la liste des modules dans ma partie privée. Si je renomme le dossier en tgg_atos, il réapparaît immédiatement.
Pouvez-vous me dire quelle erreur je commets qui empêche de renommer le dossier ? Je précise que j’ai recherché dans tous les fichiers du module et, sauf erreur de ma part, je n’ai pas trouvé de référence au nom du dossier.
Merci par avance
Bonjour,
Les modules Prestashop necessitent que leur fichier de classe principal porte le meme nom que le dossier du module.
Pour résoudre le chemin trop long, installez le module, déplacez son sous dossier « param » vers le haut de l’arbo du systeme de fichiers puis mettez le chemin a jour dans l’onglet de configuration avancée, ce sera beaucoup plus simple 😉
Bonjour,
Tout d’abord bravo pour ce module !
J’ai une petite question, je souhaite déclencher un script lorsqu’une commande est validé. A quel endroit me conseillez vous d’insérer le script ?
Bonjour,
nul besoin d’insérer quoi que ce soit dans le module, créer un nouveau module et utilisez le hook approprié, ainsi vous pourrez mettre à jour le module sans perdre vos actions supplémentaires.
Reportez-vous à la dernière section de la documentation fournie avec le module.
Je rencontre un bug… la commande ne se valide pas correctement malgré la validation du paiement. j’essaie de voir si cela vient du module de paiement ou du coeur de prestashop.
peux tu m’expliquer la ligne 557… je ne comprends pas pourquoi tu fais appel à la fonction ValidateOrder uniquement si le panier n’existe pas (if !cart->orderExists)?
Est ce que la fonction Order est censé valider la commande juste avec le numéro de order_id?
de mon côté, je valide mes commandes et pourtant, elles sont bien enregistrées mais pas validées.
merci de tes éclaircissements.
Bonjour,
Au contraire, la validation ne se fait que lorsque le panier existe, c’est la commande qui ne doit pas exister pour cela.
Tu te méprends probablement sur la fonction PaymentModule->validateOrder de Prestashop, celle-ci sert à convertir un panier en commande et non pas à passer la commande dans un statut validé. C’est le second paramètre de cette fonction qui définit dans quel état la commande est initialement créée.
Je ne vois pas de quelle fonction Order tu parles ? Le constructeur de classe ?
Je te déconseille fortement de mettre les mains dans le cambouis d’un module de paiement si tu ne connais pas correctement PHP 5 ou Prestashop, car tu vas au devant de sérieux ennuis juridiques si tu mets en danger la confidentialité des informations bancaires de tes clients. (ou d’ennuis financiers si tu te fais détourner tes paiements… mais ça c’est une autre histoire.)
Qu’appelles-tu « ne pas se valider correctement » ? Quelle version de Prestashop utilises-tu ?
Bonjour Damien,
Je tiens à te remercier pour le job fournit dans le dev de ce module.
Cependant j’ai encore besoin d’un coup de main, lorsque j’ai un paiement via ton module de paiement cb , le statut de ma commande est annulé alors que dans log j’ai
bank_response_code: 00 et dans ma remise de banque mon paiement est bien présent, dans la conf du module j’ai « Etat de la commande lors d’un paiement validé :
paiement accepté ».
As-tu une idée d’où pourrait venir le problème ?
Par avance merci
Nicolas
Bonjour Nicolas,
Désolé de vous avoir laissé sans nouvelles aussi longtemps, je n’ai pas eu beaucoups de temps libre ces deux dernieres semaines.
Non, je n’ai jamais constaté ce bug. Quelle version de Prestashop utilisez-vous ?
Je vous ai envoyé un mail pour vous transmettre mon adresse, si vous le souhaitez je peux aller faire une session de debuggage sur votre serveur, auquel cas envoyez moi les acces (ftp, back office et si possible ssh) de l’hebergement.
Bonjour,
j’essaye actuellement d’installer le module ATOS Version 2.0 BETA 4 RC4 sur mon site prestashop qui est actuellement en version 1.4.3. Je tiens à préciser au cas où que je travaille en LOCAL. J’ai pas encore mon server OVH.
Tout semble être bien paramétré mais lorsque j’arrive sur ma page de payement j’ai la phrase “Le paiement par carte est indisponible jusqu‘à demain, nous vous prions d’accepter nos excuses pour cet inconvénient.”
De plus j’ai un message d’erreur dans mon header “Strict Standards: Declaration of tgg_atos::validateOrder() should be compatible with that of PaymentModuleCore::validateOrder() in C:\EasyPHP-5.3.6.0\www\monsite.com\modules\tgg_atos\tgg_atos.php on line 11” des fois la ligne signalée peut être la “1041”.
j’ai bien suivie les paramètres d’installation de sogenactif mais rien y fait… Shame on me.
Quelqu’un aurait une petite idée sur mon problème? Est ce parce que je travaille en Local ? a moins que j’ai fait une erreur ailleurs. J’avoue être un peu perdue.
Merci pour votre aide.
Bonjour, le module fonctionne très bien en local (je le développe sur une machine virtuelle linux hébergée sur ma station de travail), à part la réponse silencieuse du serveur bancaire évidemment puisqu’elle nécessite un hébergement visible depuis Internet.
Configurez correctement les paramètres d’envoi de mail de votre easyPHP car le module masque les réels messages d’erreurs aux visiteurs et les envoie par mail au propriétaire de la boutique (merci de lire la doc…).
Pour l’erreur « Strict Standards: Declaration of tgg_atos::validateOrder() should be compatible with that of PaymentModuleCore::validateOrder() in C:\EasyPHP-5.3.6.0\www\monsite.com\modules\tgg_atos\tgg_atos.php on line 11 » il s’agit du wrapper de compatibilité pour les version avant et après 1.4 de Prestashop, rien de préoccupant, je le réécrirai à l’avenir pour éviter de déclencher ces avertissements.
La ligne 1041, si vous y jettez un coup d’oeil, correspond à l’envoi de l’erreur par mail à l’administrateur.
Bonjour,
mon client a fait l’acquisition d’un module Atos Sips Prestashop qui après maintes installations et configurations ne fonctionne pas. L’équipe prestashop nous répond que nous devons payer l’installation. D’habitude, on achète un module, on l’installe et ça marche, là ça ne marche pas et il faut donc payer plus…
Et bien je vais tester votre module et s’il fonctionne, je préfère vous faire un don que de payer pour de la vente forcée d’une équipe loin d’être open source finalement ! Y’a des limites je trouve, il faut un minimum de maintenance lorsque l’on vend un module.
Je vous tiens au courant
Cordialement
Bonjour, j’espère que mon module vous conviendra, de toutes façons le module officiel de Prestashop est un brique très peu configurable…
Par contre il est normal qu’un module Atos soit plus complexe à installer que les autres modules Prestashop et cela l’équipe Prestashop n’y est pour rien : Atos est un système obsolète, non open source, qui nécessite d’exécuter un fichier binaire (disons un .exe pour faciliter la compréhension des purs windowsiens), et se pose alors la difficulté de la compatibilité système entre votre hébergement et l’exécutable (quelle version du noyau ? 32 ou 64 bits ?), des autorisations à appliquer sur ces exécutables pour qu’ils puissent être lancé par un script PHP, de la configuration de l’hébergement pour que PHP soit autorisé à exécuter des commandes shell…
S’il faut s’en prendre à quelqu’un, c’est à :
– Atos/SIPS, qui après avoir plus que largement rentabilisé leur système qui n’est pas tout jeune n’a pas jugé bon de faire évoluer leur système archaïque
– Votre banque de se fier à Atos/SIPS, le seul système de paiement où les bugs pourraient presque être garantis dans la prestation.
– Votre banque qui n’a pas jugé bon d’investir quelques malheureux kopecks dans la création d’un module pour Prestashop qui est pourtant le logiciel e-Commerce standard des personnes souhaitant mettre en place une boutique en ligne sans connaissances… Plutôt que de payer une fois pour tout le monde ils jugent visiblement préférable que chaque commerçant ait à payer de son côté pour ce module, de sources pas toujours très fiables.
Mais ne mélangez pas tout, l’équipe Prestashop malgré ses défauts (qui tendent à s’améliorer je trouve) est bien une équipe open-source, la solution Prestashop étant qui plus est libre. Ne leur crachez pas dessus, car ils vous offrent une bonne alternative à osCommerce ou Virtuemart qui sont deux parpaings obsolètes au possible et bien moins facilement modifiables que Prestashop. Pour ma part je préfère de loin Magento pour sa puissance et sa flexibilité pour peu que l’on ait le niveau en PHP et que l’on se casse un peu le crâne au début sur son système de configuration modulaire par XML, on peut ensuite développer des extensions à un rythme très soutenu. Par contre pour qui n’a que de faibles connaissances en Web et hébergements PHP et pas de budget pour qu’un prestataire modifie la boutique à son goût, je recommande de loin Prestashop !
Bonjour,
je vous remercie pour votre réponse très intéressante.
Je préfère être clair, je ne souhaite aucunement cracher sur l’équipe Prestashop mais bien sur le module Atos payant qui n’est accompagné d’aucune autre maintenance que « Payez l’installation par notre équipe » même si je sais que c’est plus compliqué. Or au final, si une boutique n’a pas de moyen de paiement bancaire qui fonctionne (hors paypal), elle perd beaucoup de son intérêt et donc la solution open source que j’apprécie énormément outre perd aussi de son caractère Open source pour obliger le quidam à débourser. C’est tout ce que je veux dire et je ne remets nullement en question les temps de développement et la qualité apportés à cette plate-forme.
Votre solution marche au final beaucoup mieux que la solution payante puisque des commandes sont bien validées en production. Mais je n’avais pas remarqué que les commandes restent en mode Attente si la personne ferme la fenêtre de paiement. Est ce normal ?
Et encore merci de l’apport que vous faîtes au monde Open Source.
Par ailleurs, j’ai vu que vous aviez besoin de testeurs, si je peux vous être utile dans la mesure du possible, indiquez moi la marche à suivre.
Bien cordialement
Bonjour, j’ai bien installé votre module cependant il subsiste une erreur très étrange :
dans le BO, le chemin vers le dossier param est trop grand, j’ai donc décidé de le déplacer dans une autre dossier.
Donc je modifie /var/www/mon-site-avec-un-nom-trop-grand/modules/tgg_atos/param et je met /var/www/c-mieux/param après avoir ftp-copié-collé le dossier bien sur (et même modifié le pathfile). Lorsque je valide, le BO me dit :
-> Impossible d’écrire le fichier de configuration, vérifiez les permissions sur le dossier de configuration
-> Le chemin vers les fichiers paramètres n’existe pas ou les droits sur les fichiers le rendent invisible.
PS: le dossier param et tout son contenu sont bien à 777 …
J’aurais vraiment besoin d’aide svp.
Merci d’avance !
Bonjour,
cela ressemble fort à un problème d’open basedir sur un serveur d’hébergement mutualisé.
Avez-vous vérifié vos logs PHP ?
Un grand merci pour ce module extrêmement efficace.
Bon, et bien en fin de compte il semblerait que je soit une fois de plus incapable de m’arrêter : une bêta RC5 est en préparation avec quelques améliorations :
– Possibilité de déclarer dans un XML des variables supplémentaires à ajouter à l’appel de l’executable request (permet par exemple de configurer les templates côté serveur, écraser une variable générée par le module, ou d’ajouter des variables que vous demanderaient d’ajouter les techniciens ATOS de votre banque pour activer des fonctionnalités non-couvertes par le back-office du module).
– Possibilité d’afficher les erreurs du front-office pour des IP spécifiques. Le mode Débug d’ATOS est maintenant restreint à ces IP.
– Possibilité de configurer les adresses devant recevoir les emails de rapport d’erreur front-office.
Avec ces deux dernières fonctionnalités je vais probablement enfin recevoir un peu moins de message contenant simplement « Aaaaaaaaaaahhhh, j’ai pas lu la doc et j’ai un message : Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient. Koikispasse ???!!!!!??? » Parce que de tels messages sont vraiment déprimants et partent 9 fois sur 10 directement à la corbeille…
J’envisage de plus d’ajouter un appel de contrôle à l’exécutable request depuis la page de configuration pour aider à la détection de problèmes de configuration.
Affaire à suivre, cordialement votre TgG 😉
PS: je cherche toujours des testeurs pour m’aider à vérifier les versions avant publication, ce qui accélèrerait considérablement le rythme de publication des versions, aucune réponse pour le moment.
De plus toutes les personnes ayant proposé de participer à la documentation se sont défilées lorsque je leur ai répondu… Étrange étrange venant de personnes faisant généralement cette proposition à la fin d’un long mail de critique sur la documentation actuelle, n’est-il pas ? 😉
Au passage: pour infirmation la release RC4 actuelle a maintenant largement dépassé la centaine de téléchargements, le seul retour négatif intéressant étant celui de yoyo, la RC4 sera donc officiellement labellisée 2.0 stable (après avoir éliminé toute majuscule des noms de fichiers de template pour définitivement résoudre la compatibilité des fichiers de traduction pré et post 1.4).
Il n’y aura donc en fait pas de 2.0 RC5 mais plutôt une 2.1 RC1 🙂
Bonjour,
Merci encore pour ce module !
Bravo pour les évolutions !
Je t’ai fait un don qui me semble normal pour un développement comme ça !
Un détail : avec l’ancienne version je l’avais déjà fait mais je ne te l’avais pas dit, j’ai ajouté le support de « citelis » au module … à vrai dire comme c’est la même API, je n’ai eu qu’à ajouter « citelis » dans la liste des moyens de paiement avec le code de dev spécifique… Et a priori ça fonctionne en prod nickel !
Je pense que c’est pas super propre ce que j’ai fait, mais bon …
Merci pour le retour et le don, j’essayerai de penser a ajouter Citelis dans la conf par defaut.
Bonjour,
J’ai testé le module et il fonctionne très bien. Mais j’aurais besoin d’intégrer urgemment la banque citelis dans le module. Pouvez-vous m’indiquer la marche à suivre?
Merci d’avance
Bonjour,
Merci pour ce module.
Je viens de le tester en local sur presta 1.4.3 tout marche nickel. J’avais eu l’erreur de « paiement …demain » j’ai juste utilisé la commande tar directement(tar ..atos.zip -C …/prestashop/modules) au lieu de faire du copier coller dans le répertoire modules de prestashop.
Bravo et bonne continuation.
Je vous remercie pour ce module !
Cordialement,
Mathieu
Bonjour,
merci beaucoup pour le module.
Je me demandais pourquoi ne pas créé un dépôt public sur github, cela serait plus facile pour avoir la dernière version et peut être pour te filer un coup de main ? ^^
J’avais initié le projet sur google code, mais ayant eu des problemes de synchro avec le svn le projet n’est pas synchro (je suis neofite en serveur de controle de version, on ne peut pas tout connaitre a 25 ans 😉 ), mais je compte m’y remettre quand j’aurai du temps a consacrer, pour l’instant la priorité etait de fournir une 2.0 stable qui convienne a la plupart des utilisations possibles de la passerelle, et comme, vous vous en doutez, le projet est loin d’etre rentable niveau dons, je ne peux pas y passer tout mon temps libre…
Bonjour, tous d’abord félicitation pour ce module vraiment pratique et je ne manquerais pas d’y participer un peu petit peu.
Je rencontre un souci lors du paramétrage du module
Je pense avoir configuré tous les droits le block de paiement avec le choix du paiement par carte apparait bien dans ma boutique mais lorsque je clic dessus je recoit un message d’erreur dans ma boite email
L’exécutable request a retourné une erreur.
(127):
mais pas de message d’erreur apres le (127) ????
je suis prestashop 1.3.1.1 hébergement spécialisé (c’est peu être la que ça peche, je reprend un developpement d’une boutique abandonné par un autre dev)
merci d’avance pour ton aide
Le code d’erreur shell (127) peut t’aider a trouver l’origine du probleme, je pencherais pour l’un des cas suivants :
– binaire incompatible (version de noyau ou incompatibilité 32 ou 64 bits)
– binaire absent a cette adresse
– absence de droits de lecture/execution pour cet utilisateur.
Lance le fichier manuellement en sh ou bash pour en avoir le coeur net.
Re après une longue pause, je reprend la où je mettais arrêter précedemment, c’est à dire l’erreur 127, mon serveur est en 64 bits, y’a t’il quelque chose a modifier au niveau de ton module ?
Merci d’avance pour ta réponse
Bonjour Damien,
Bravo pour ton travail.
Je voulais te faire une vrai proposition de collaboration pour ton module.
Tu pourrais le tester sur notre site en production, on te laisserai les accès adéquate.
Bien à toi 😉
Bonjour,
Tout d’abord je tiens a vous félicité pour la qualité de votre module, au regard de sa gratuité.Heureusement qu’il y a encore des personnes comme vous qui propose de partager leur travail.
Je viens d’installer votre module et il fonctionne parfaitement, cependant pour l’adapter parfaitement a mes besoins j’aurai besoin de quelque renseignement.
Je voudrais lors d’un paiement en deux fois sans frais, pouvoir choisir le montant des transactions.Par exemple pour une commande de 100 euros au lieu d’avoir un deux fois avec deux transaction de 50 euro, je voudrai pouvoir choisir le montant de chaque transaction.
Cordialement
marc desaulty
Bonjour,
Si vous compulsez un peu la doc ATOS à propos de la configuration du paiement en N fois vous verrez que cela n’est pas possible. Le seul paramétrage possible de ce côté est la possibilité de définir le montant de la première transaction uniquement (ce qui dans votre cas, paiement en deux fois, devrait convenir), et ce montant doit être calculé AVANT d’envoyer l’utilisateur vers la banque (vous ne pourrez donc pas manuellement répartir le montant total entre les deux transactions après génération de la commande).
Si vous souhaitez modifier le calcul de répartition, éditez la fonction getPaymentForm() de tgg_atos/tggatos.php, trouvez la ligne :
'INITIAL_AMOUNT='.round($atos_amount/$splitted)(vers la fin de la fonction)
Cette ligne est responsable du paramétrage de la première transaction, vous pouvez intervenir ici pour modifier la répartition de manière automatique.
Cordialement, TgG.
Salut grand chef !
Je viens de passer 3 (ou 4 ?) heures sur ta documentation, pour (humblement essayer de) l’améliorer, et ainsi, te permettre de répondre ! » RTFM » !
…j’ai compilé mes questions, tes réponses, et les posts de mes petits camarades.
Par contre, il me faut une adresse mail pour te renvoyer tout ça !
Bon, je file, il y a Madame qui râle que je suis encoooore sur mon PC à cette heure !
Arrgggghhhhhhhhhh !!
Je viens de subir l’infamie suprême !
Étant en mode dégradé (mon DD de sauvegarde m’ayant lâché), je priais ^pour que tout aille bien… Et mon DD principal m’a lâché aussi.
J’ai donc perdu tout mon travail, et accessoirement la révision de ta doc.
Je suis ravi, comme tu l’imagines. La suite au prochaine épisode. Dans quelques temps à mon avis.
Pauvre de toi ! J’ai connu cela a l’epoque des disques durs 10Go en perdant presque un an et demi de travail (sans compter les photographies de vacances…), c’est pour cela que je veille etroitement sur la santé de ma grappe 0+1 et que j’ai tendance a synchroniser regulierement les workspaces entre la becane fixe (protegee en 0+1 pour la partie données), le portable et le serveur d’hebergement. Sinon il est aussi conseillé de mixer deux disques de modeles differents pour proteger ta grappe en R0, R1 ou R5 car deux disques d’un meme modele ont tendance a lacher a intervalle très raproché, perdant l’interet du systeme de redondance.
Bonsoir,
Je suis en train de tester le module, et je rencontre une erreur bizarre:
(255): !-1!Error parameter (customer_ip_address=monIPv6vachementlongue) too long!!
Le module ne gère pas les IPv6?
Comme sur ce coup la ni google ni le forum Prestashop ne sont mes amis je viens à la source. Une idée Damien?
Bonjour, merci pour le retour,
en fait ATOS n’accepte que 19 caractères max dans le champs customer_ip_address. Pour résoudre le problème, vous pouvez éditer la fonction getPaymentForm() de tgg_atos/tgg_atos.php et remplacer :
'customer_ip_address' => $_SERVER['REMOTE_ADDR'],par
'customer_ip_address' => substr(0, 19, $_SERVER['REMOTE_ADDR']),Pour ne conserver que les 19 premiers caractères pour les IP trop longues.
N’hésitez pas à envoyer vos commentaires à votre banque car aucune ne semble se rendre compte qu’ATOS est une solution largement obsolète.
La modification sera apportée à la 2.0 stable.
Cordialement, TgG.
Salut Damien,
Tout d’abord, je tiens à te remercier pour ce module, il est juste super !
Même si tu trouves mon message « déprimant », je t’en conjure, ne l’envois pas direct à la corbeille… 🙂
J’ai bien entendu lu plusieurs fois depuis ce matin la doc et je n’arrive pas à résoudre ce problème.
J’ai malheureusement, le fameux et célèbre : LE PAIEMENT PAR CARTE EST INDISPONIBLE REVIENS DEMAIN, UN PEU PLUS INSTRUI SINON ATTENTION »
J’ai un hébergement OVH perso mutualisé avec ce message :
array(2) {
[« cmd »]=>
string(681) « /homez.429/lacamerac/www/modules/tgg_atos/bin/request « amount=29199″ »
automatic_response_url=http://www.lacameraembarquee.fr/modules/tgg_atos/front-ctrl/payment-autoresponse.php » « cancel_return_url=http://www.lacameraembarquee.fr/modules/tgg_atos/front-ctrl/payment-return.php » « capture_day=0 » « capture_mode=AUTHOR_CAPTURE » « currency_code=978 » « customer_id=7 » « customer_email=dsaSgndg@hotmail.fr » « customer_ip_address=89.224.107.94 » « language=fr » « merchant_id=053196640600013 » « normal_return_url=http://www.lacameraembarquee.fr/modules/tgg_atos/front-ctrl/payment-return.php » « order_id=46 » « transaction_id=4 » « pathfile=/homez.429/lacamerac/www/modules/tgg_atos/param/pathfile » 2>&1″
[« status »]=>
int(126)
}
Ton aide serait précieuse et très appréciée!
Merci.
Nico
j’ai oublié cette erreur en mail :
(126): sh: /homez.429/lacamerac/www/modules/tgg_atos/bin/request: Permission denied
Voyez avec votre administrateur systeme, vous outrepassez probablement une politique de sécurité de votre hébergement.
La solution fonctionne parfaitement, merci Damien et ravi que ça puisse aider au développement du module!
Salut Damien, merci pour ton module, j’essaye désespérément de l’installer sur un prestashop 1.4.3 (j’ai pris la rc4)
mais impossible d’arrivé a mes fins :
——————————————————————————–
-PREMIER CAS : si je coche : « Mon serveur détient les binaires ATOS dans ses dossiers d’inclusion : »
j’ai ce message d’erreur : « Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient »
avec cette erreur :
array(2) {
[« cmd »]=>
string(608) « request « amount=6000 » « automatic_response_url=http://www.kalihair.fr/modules/tgg_atos/front-ctrl/payment-autoresponse.php » « cancel_return_url=http://www.kalihair.fr/modules/tgg_atos/front-ctrl/payment-return.php » « capture_day=0 » « capture_mode=AUTHOR_CAPTURE » « currency_code=978 » « customer_id=2 » « customer_email=contact@graphee.com » « customer_ip_address=88.165.175.184 » « language=fr » « merchant_id=082584341411111 » « normal_return_url=http://www.kalihair.fr/modules/tgg_atos/front-ctrl/payment-return.php » « order_id=16 » « transaction_id=42 » « pathfile=/homez.373/kalihair/www/modules/tgg_atos/param/pathfile » 2>&1″
[« status »]=>
int(127)
}
sh: request: command not found
———————————————————————
Si je ne coche PAS cette case, j’arrive a simuler mon paiement avec la carte de test (mercanet) mais quand je clic sur retour boutique j’ai cette erreur :
!082584341411111!fr!6000!47!CB!20110801093053!113120!20110801!00!1312191080!191080!978!4974.00!1!4D!00!!!!!!fr!fr!2!16!contact@graphee.com!88.165.175.184!0!AUTHOR_CAPTURE!!02!SSL!!201204!!!!!!!9!0Fatal error
avec page blanche…..
bref je sais plus quoi faire 🙁
pour info, j’ai bien récupéré le dossier MERCANET pour linux 32 bits (j’ai un hebergement ovh pro), j’ai bien remplacé les fichier dans bin par ceux de mercanet, idem pou 4 fichiers de param.
merci pour ton aide!
Alors après moulte test, mon dernier souci est bien lors du clic sur « retour a la boutique »
– La commande n’est validée QUE lorsque l’on clique sur « retour a la boutique » après le paiement (et non avant, donc quid des clients qui ne clic pas deçu pour finaliser l achat?)
– J’ai une grosse page d’erreur lorsque je clic sur ce bouton
– Pas de commande en backoffice, panier non vidé…
bref je sais absolument pas quoi faire 🙁
Bonjour,
Je suis navré mais sans connaitre les erreurs complètes je ne peux pas vous aider.
alors pour l’erreur en mode debug j’ai ceci :
array(2) {
[« cmd »]=>
string(1250) « /homez.373/kalihair/www/modules/tgg_atos/bin/response « message=2020333939603028502c2360532e3344532d2360522e3360502c4360502c3334502e2328552e2330532d2324542c3324512c33242a2c2360532c2360502d2338502c23602a2c2360552c2360502c4338555c224324502d3360502c232923304048502c2338502c2324542c4360512c3360582c2324512c332c522c33602a2c3360532c2360502d4324532c5328522d5048512c2330502c2360582c4360512c3360582c23242a2c3360512c2360502c4360505c224324502c4360502c3360512c5324522c3344582c5330575c224324502c2360502c2338512e3340532d233c2a2c2328582c2360502c4639525c224360522e3360502c2329463c4048502c2340502c2360532e333c585c224324502d4360502c233c542e333c542b4360505c224324512d2360502c2338522c2324522c23302a2c2360592c2360502c4639525c224360532c2360502c3345433b56595438362d5430263d52383721483936344e38565d4d5c224360512d4360502c232d333454502a2c2360572c2360502c4360525c224360532d5360502c3330582e5c2258512d43344e2c333c552b4324582d6048502c5340502c2360522c33382a2c2330502c2360512d2425353524412f34455d2330352134353529255c224360532e3360502c2324505c224324502e3360502c232854316048512c3360502c2360512c3048512c3324502c2360522c23602a2c3328522c2360502c33442a2c3328532c2360502c33602a2c2328562c2360502c33282ad1c0f7605017983f » « pathfile=/homez.373/kalihair/www/modules/tgg_atos/param/pathfile » 2>&1″
[« status »]=>
int(0)
}
et en dessous du cadre rouge ceci :
!0!!082584341411111!fr!6000!65!CB!20110801113210!133227!20110801!00!1312198347!198347!978!4974.00!1!4D!00!!!!!!fr!fr!2!16!contact@graphee.com!88.165.175.184!0!AUTHOR_CAPTURE!!02!SSL!!201204!!!!!!!9!0Fatal error
Sinon, est t’il possible de vous missionner contre rémunération pour résoudre le problème? ainsi vous auriez accés aux fichiers, ftp , admin…. ?
merci pour votre aide.
(afficher la source pour voir la totalité de la chaine lol, elle sort du cadre d’affichage)
Effectivement, il semble y avoir un soucis entre les binaires atos et l’environnement d’exploitation ou entre le serveur PHP et les binaires, une séance de débuggage sur le serveur semble s’imposer.
Je propose effectivement un forfait installation/débuggage, je vous contacte par mail pour plus de détails.
Bonsoir,
je voudrais savoir comment sont gérés les statuts des commandes lorsque les utilisateurs quittent la page de paiement de la banque avant de valider ? Dans mon cas, avec la PS 1.4.3 et la dernière version tgg_atos beta 4 RC4, les commandes ont un statut « En attente » et non « Annulé ».
Merci de votre aide !
Cordialement,
Renan COLLIN
tiens, voila qui me dit que y a un serieux souci sur ma boutique, moi quand les clients quitte la page de la banque y a rien dans les commandes 🙁
Ne sont convertis en commande que les paniers pour lesquels le paiement a été validé, cela pour éviter que vos clients perdent leur panier en cas de refus bancaire ou de retour via le bouton d’annulation, ce qui leur permet de repartir immédiatement en paiement avec une autre carte ou via un autre module de paiement que vous proposeriez. Cela permet (théoriquement) d’améliorer le taux de conversion.
Bonsoir,
je comprends tout à fait vos arguments.
Serait-il imaginable qu’une version future permette de garder les paniers même en cas d’annulation de paiement avec un statut « paiement annulé » puis la passer en « Validée » en mode normal dès validation d’un nouveau paiement ?
Bien cordialement
C’est tout à fait faisable en modifiant le module, mais n’est pas prévu dans les améliorations gratuite étant donné qu’elle n’est en rien nécessaire. Si besoin cela peut être envisagé sans problème en tant que prestation payante.
Bonsoir,
merci pour votre réponse.
Je vous ai fait un petit don (car petit projet) mais je ne manquerai de réutiliser votre solution ou de faire appel à vos services si besoin.
Cordialement,
Renan COLLIN
Bonjour,
comme déjà indiqué, je suis aussi bloqué avec le message
Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient
J’aimerais bien proposer ton module en remplacement de celui de sourceforge, mais je n’arrive pas à le faire fonctionner.
As-tu résolu le problème ?
Bonjour, comme déjà indiqué aussi, ce message est le message d’erreur « grand publique », le vrai est reçu par mail… Lire la doc ?
Bonjour Damien,
Je rencontre un souci avec ton module de paiement SIPS/ATOS v1.0.
Quand je clique sur le logo de la société générale, j’ai ce texte qui apparaît :
http://www.sextoystv.fr/modules/tgg_atos/tgg_atos-payment-redirect.php
Je sais que la v2 est sortie… Mais serait-il possible d’avoir ton aide pour régler ce problème stp ? Car la je suis carrément largué…
J’espère avoir une réponse rapide de ta part
Bonne journée
Cordialement
Christian
Arf le texte qui apparaît est le suivant :
Le paiement par carte est indisponible jusqu’à demain, nous vous présentons nos excuses pour la gêne occasionnée
Désolé
Salut Troglo,
Je souhaitais savoir si il faut modifier les chemins comme indiquer dans le guide d’installation API ou tout est programmé automatiquement ?
Merci
Idéalement il faut déployer le fichier parmcom contenant les paramètres par défaut du service avec les certificats et les exécutables fournis par la banque comme décrit dans la doc API (à ceci près que vous devrez forcément avoir un dossier pour les fichiers paramètres (parmcom, certificats) et un dossier pour les binaires, éventuellement le même dossier pour les deux mais à éviter), ensuite vous indiquez la position du dossier contenant le parmcom en tant que chemin vers les fichiers de paramètres, le module y créera le pathfile et le parmcom de votre certificat, et vous paramétrez le chemin vers les exécutables/binaires.
Idéalement (toujours), prévoir un dossier de stockage des logs (toujours utile un jour ou l’autre).
Bonjour,
Ton module est super, je les installé anciennement sur un autre site ou je n’ai eu aucun problème.
En ce moment je l’installe sur un autre site (serveur Linux 32) et lorsque je clique sur Payer par cb, j’ai un mail m’indiquant :
(127): sh: request: command not found
J’ai bien les bon fichiers compatible linux 32 et j’ai mis tous mes droits en 755 en pensant que cela pouvais venir de la. J’ai envoyé le fichier request et response en binaire.
Je crois avoir tout bien fait, or cette erreur persiste. As tu une idée de l’origine de cette erreur ?
Merci d’avance.
Bonjour,
Vous avez probablement coché la case « Mon serveur détient les binaires ATOS dans ses dossiers d’inclusion » alors que ce n’est pas le cas. Vérifiez que cette case n’est pas cochée, décochez-là le cas échéant.
Merci, le problème venait effectivement de la.
Bonsoir,
Je viens de lire tous les commentaires et toute la doc… Pour commencer, merci pour ce module, il est super! Je l’ai installé pour ma soeur qui est sous etransaction (du CA) et il fonctionne hyper bien.
Par contre pour moi, c’est plus compliqué, je dois passer par Citélis. J’ai essayé de faire comme indiqué dans la doc, mais pour l’instant çà buggue. A suivre donc!!!
Juste pour dire qu’une version avec Citélis serait vraiment appréciée!!! 😉
Sinon, merci pour tout!!!
L’integration Citelis est en cours, la banque a accepté d’être integrée d’office dans le module mais est longue a m’envoyer le kit. Si vous m’envoyez votre kit Citelis cela ira plus vite 😉
Bonjour,
Je peux vous envoyer cela à quelle adresse? J’ai accès au kit d’installation, çà y a pas de soucis, je peux donc vous envoyer les fichiers…
P.S: Il va de soi que je ferai un virement Paypal, parce que çà fait un sacré moment que je tourne en rond… Donc au risque de me répéter: MERCI!!!
Bonjour,
En transférant ma boutique d’un mutualisé sur un VPS, j’obtiens maintenant cette erreur quand je veux effectuer un paiement en ligne. (le nom de domaine est le même)
—-
Erreur de sécurité
Nous regrettons de ne pouvoir donner suite à votre demande, merci de prendre contact directement avec le commercant en indiquant votre problème
—–
ce message vient du serveur de la banque en ssl
paiement.e-transactions.credit-agricole.fr/cgis-payment-etransactions/prod/callpayment
Alors que si je passe en mode test, tout fonctionne comme il faut ?
Dans la configuration du module, aucune erreur de relevé
Si quelqu’un à une idée ?
Merci.
Je me réponds à moi même.
C’est la table qui n’a pas été créé à l’installation.
Donc désinstallation du module (attention les certificats sont effacés)
Installation
configuration
et tout est ok
Bonjour,
suite à une restauration et une migration de notre site, nous rencontrons le problème suivant :
Paiement par carte
Paiement par carteVous avez choisi de payer par carte.
Vous allez être redirigé vers un serveur bancaire sécurisé où les informations nécessaires au paiement vous seront demandées.
Total de votre commande : 30,00 €
Le paiement par carte est indisponible jusqu’à demain, nous vous présentons nos excuses pour la gêne occasionnée.
De plus nous recevons par mail le message
L’exécutable request a retourné une erreur.
(126): sh: /home/www/haxessoriz/www/modules/tgg_atos/bin/request: Permission non accordée
J’ai vu sur un poste ici plus haut qu’il s’agit probablement d’un problème de sécurité chez l’hébergeur. Mais quel est le problème exactement, si il est connu? Car chez notre hébergeur, ça fait 5 jours qu’ils « cherchent » mais ne trouvent rien.
Merci de votre aide
Bonjour,
Le message d’erreur reçu par mail devrait amplement suffir a votre hébergeur pour trouver le problème, mais si ce sont des bras cassés vous pouvez leur suggérer de commencer par vérifier la compatibilité des executables avec la version du noyau linux ;-).
Apparemment ils nous ont migrer vers du 64bits sans nous prévenir. La banque nous a renvoyer des exécutables, mais celà ne fonctionne toujours pas… 🙁
Pour info, c’est chez Celeonet…
D’après l’hébergeur, les exécutables fonctionnent sur leur infrastructres après les avoir testé. Une idée d’où peut venir le problème? sachant qu’on a toujours l’erreur 126 comme indiqué ci-dessus.
Merci,
Si les exécutables sont bien compatibles (le meilleurs moyen de vérifier est de lancer manuellement request, si vous obtenez un message d’erreur ATOS (!-1!</TBODY></TABLE><BR><DIV ALIGN=CENTER>…) c’est que tout va bien), il s’agit probablement d’un problème de droit, de propriétaire ou de politique de sécurité LAP trop restrictive ou non respectée.
Avez-vous un accès SSH sur votre espace d’hébergement ?
Bonjour,
j’utilise le module avec prestashop 1.4.3 dans une machine 64bits. J’ai une fois eu l’erreur (126): sh: …/prestashop/modules/tgg_atos/bin/request: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory je l’ai résolu en installant le paquet redhat-lsb.i686.
Merci pour le module.
Bonjour,
merci pour ce module qui fonctionne presque parfaitement. J’ai toutefois le petit souci indiqué plus haut « Strict Standards: Declaration of tgg_atos::validateOrder() should be compatible with that of PaymentModuleCore::validateOrder() in C:\xxxxxx\www\monsite.com\modules\tgg_atos\tgg_atos.php on line 11 »
et en page commande:
Strict Standards: Declaration of tgg_atos::validateOrder() should be compatible with that of PaymentModuleCore::validateOrder() in /www/modules/tgg_atos/tgg_atos.php on line 1165
J’ai essayé de voir comment masquer le message qui, comme dit plus haut, n’empêche pas le bon déroulement du programme, mais ne trouve rien. Avez-vous une piste pour le masquer.
Merci d’avance
Bonjour,
Il suffit d’utiliser un reglage d’error reporting adapté au contexte de production, cf doc Apache + PHP.
De toutes facons cet avertissement n’aparaitra plus avec la prochaine version (2.0)
Bonjour,
Je suis actuellement à la recherche d’un module permettant, une fois la commande passée, de ne verser qu’un acompte par CB, le reste étant payé lors du retrait de la marchandise. L’acompte sur le site ne servant qu’à éviter les commandes fantaisistes. Toutefois la commande doit afficher le prix complet, seul le paiement est partiel, d’un montant fixe au delà d’un seuil de commande défini.
Je n’ai rien trouvé qui fasse cela, aussi avant de me le coder à la mimine, je souhaiterais vous proposer, soit d’établir un devis pour ajouter vous-même cette fonction (si vous la trouvez utile) à votre module ou bien, si l’envie ou le temps vous manque, de m’autoriser à partir de votre code pour l’adapter à mon besoin. Bien entendu, je fournirai dans ce cas un diff dont vous pourrez faire l’usage que bon vous semblera 🙂
Merci de me contacter par mail si ma demande vous semble pertinente.
Cordialement,
p@T
Salut,
ce n’est pas extrêmement compliqué ; il faut modifier le calcul du montant au début de tgg_atos::getPaymentForm() puis (optionnel) modifier l’appel à PaymentModule::validateOrder() dans tgg_atos::processResponse() en utilisant non pas le montant retourné par ATOS mais Cart::getOrderTotal(). Le reste est du pure templating/wording et de la configuration du workflow de validation de commande. Mais c’est une utilisation assez marginale, mon module est déjà trop compliqué au gout de certains ;-).
Pour ce qui est de mon autorisation de modifier et éventuellement diffuser la version alternative créée, pas de soucis, tu n’as d’ailleurs pas besoin de mon autorisation pour cela puisque je publie ce module sous GPL v3, tant que tu publies sur une licence compatible GPL v3. Je t’autorise à utiliser une LGPL, normalement incompatible, que je n’utilise pas personnellement pour ne pas encourager le détournement à des fins propriétaire de mon code. Mais je te remercie tout de même d’avoir l’honnêteté de penser à me contacter.
La modification est plutôt simple si tu sais vraiment ce que tu veux faire mais je te contacte par mail au cas où tu préférerais me faire bosser dessus (ce qui en cette période d’impôts m’arrangerait bien ;-)).
très beau travail, juste une question :
– pour la banque postale le parcom a changé de nom, exit parcom.scelliusnet transformé en parcom.scellius, j’ai modifié le pathfile en conséquence.
Est ce la seule modif à effectuer ?
cordialement
Bonjour,
Il faut soit renommer le nouveau parmcom avec le nom que porte l’ancien, soit mettre a jour le tableau statique de configuration contenant les suffixes de parmcom par banque au debut de la classe tgg_atos, mais n’editez pas le pathfile puisqu’il est automatiquement généré lorsque vous valider la configuration du module.
Un très grand merci pour ton temps et ta disponibilité.
Je vais installer ce module sur ma config et bien évidement faire un DON.
Je suis intiment convaincu qu’il faut encourager ta démarche qui est véritablement tournée vers l’autre.
C’est beau…
Gabriel.
Bonjour,
Je viens de télécharger votre module.
Un grand merci à vous.
Je compte l’installer ce week-end et si tout fonctionne je ferai un don conséquent dès la mise en production.
Si, si, j’en prends l’engagement !
Cordialement,
Gil
Bonjour Damien,
je viens de souscrire à un contrat avec le crédit Agricole (kit e-transaction fourni et identifiants.)
Pourrais tu rentrer en contact avec moi stp ?
J’aurais besoin d’une petite aide (rémunérée bien sûr) pour configurer ce module sur mes 2 boutiques.
D’avance merci !
Ben.
Bonjour,
Un grand merci pour ce module qui fonctionnait jusqu’à ce que mon client me demande une mise à jour de son logo (onglet graphique).
Vous allez vous dire ‘encore un’, mais j’ai la fameuse erreur ‘paiement par carte indisponible jusqu’à demain…’.
J’ai bien vérifié les droits sur les répertoires, les transactions s’enregistrent dans la table tgg_atos_transaction_today.
L’hébergement est sur ovh et l’erreur en mode debug (on ne reçoit pas de mails) :
array(2) {
[« cmd »]=>
string(687) « path/vente/modules/tgg_atos/bin/request « amount=154140 » « automatic_response_url=http://www.domain.com/vente/modules/tgg_atos/front-ctrl/payment-autoresponse.php » « cancel_return_url=http://www.domain.com/vente/modules/tgg_atos/front-ctrl/payment-return.php » « capture_day=0 » « capture_mode=AUTHOR_CAPTURE » « currency_code=978 » « customer_id=55 » « customer_email=nom@hotmail.com » « customer_ip_address=xxx.xxx.xxx.xxx » « language=fr » « merchant_id=xxxxxxxxxxxxxxxxx » « normal_return_url=http://www.domain.com/vente/modules/tgg_atos/front-ctrl/payment-return.php » « order_id=623 » « transaction_id=8 » « pathfile=/path/vente/modules/tgg_atos/param/pathfile » 2>&1″
[« status »]=>
int(126)
}
Vous avez une idée ?
Merci.
(Modération: édité pour masquer l’IP et l’ID marchand)
Bonjour,
Je ne comprends pas plus que vous comment la soumission de l’onglet graphisme a pu provoquer cela car les seules chosent qui pourraient provoquer une telle erreur (càd un non lancement du request, tout statut différent de 0) à priori sont un mauvais réglage du path des binaires, un mauvais réglage de droit ou d’utilisateur/groupe sur le dossier et son contenu ou une incompatibilité entre le binaire et le noyau. De plus, sans avoir le mail d’erreur…
Avez-vous tenté de vous connecter en SSH sous l’user de votre site pour tenter de lancer manuellement la commande obtenue via le débug ? Vous obtiendrez ainsi l’erreur complète.
Bonjour,
J’ai l’erreur : (127): sh: request: command not found
J’ai lu dans les commentaires qu’il faut décocher la case « Mon serveur détient les binaires ATOS dans ses dossiers d’inclusion » ce que j’ai fait.
Si je sors du paramétrage du module et que je reviens dessus, la case est de nouveau cochée.
Y’a t’il un paramétrage particulier à faire pour que la case reste décochée ?
Merci
Bonjour,
En effet cette case est prévue pour des cas bien specifiques, c’est a dire lorsque l’on peut appeler le binaire sans preciser son emplacement.
Pour ce qui est de la case qui reste cochée je n’ai jamais rencontré ce problème spécifique, par contre j’ai déjà vu des cas similaires d’options de configuration de Prestashop qui ne sont pas prises correctement en compte en utilisant le système de cache Prestashop (Admin >> Preferences >> Performances >> Cache >> Utiliser le cache), surtout avc memcached.
Utilisez vous cette option ?
Bonjour,
Pour la case à cocher, en effet c’était un problème de cache.
Merci
Bonjour Damien,
J’utilise actuellement le module en version 1.x, ce soir l’upgrade de la boutique en PS 1.4 sera en prod, donc passage de ton module en version 2.x
Juste une petite question, plus par prévention qu’autre chose.
Si je regarde le parcom précédemment généré par le module, sont définis les AUTO_RESPONSE_URL et CANCEL_URL, ce qui n’est plus le cas avec le parcom généré par le module en 2.0
Si j’ai suivi ton code, à présent c’est passé en variables dans la requête de transaction vers le serveur atos de la banque. C’est bien celà ? Je n’ai pas à me soucier de la disparition des définitions dans le fichier parcom ?
A ce soir pour un retour détaillé.
En effet, entre temps le module a évolué pour être capable d’adapter ces variables au domaine réellement visité par le client (lorsque les réglages de domaine sont à AUTO, la valeur par défaut). La raison de ce changement :
– Permettre l’utilisation de ce module sur une boutique multi-domaine (en trichant un peu, voir beaucoup, avec Prestashop il est possible de créer plusieurs boutiques avec une seule administration et de présenter des catalogues différents selon ces domaines ; auquel cas vous n’auriez pas envie que le retour de banque se fasse sur le mauvais domaine n’est-ce pas ?)
– Permettre de sécuriser votre boutique en utilisant des (sous-)domaines différents pour le front et l’admin, sans cette modification le domaine d’administration serait alors utilisé pour les URLs de retour, un résultat plutôt catastrophique.
– Permettre de restreindre la réponse automatique à un (sous-)domaine dédié, une sécurité de plus. (par contre cette modification seule n’aurait pas nécessité le retrait des URL pré-générées dans le parmcom.
– Beaucoup de personnes perdaient les données de retour de banque à cause d’une redirection de (sous-)domaine dans le .htaccess du frontal (typiquement domaine.tld -> http://www.domaine.tld) qui n’avait pas été copiée dans l’admin, créant une dissociation avec les URLs générées par le back-office du module.
Content de voir que vous surveillez toujours de près mon code, n’hésitez pas à me reporter tout ce qui vous semblerait étrange, mal formé ou nécessitant des commentaires.
Bonjour,
En PS1.4.4.1, une fois sur la page de sélection de cartes (modules/tgg_atos/front-ctrl/payment-redirect.php), PS n’arrive pas à me déterminer le page_name, le body de cette page n’est donc pas personnalisée
Je ne sais pas si c’est lié, sur un autre site en tgg beta3, j’ai bien :
Une piste ?
Bonne continuation
P.
il faut lire :
Je ne sais pas si c’est lié, sur un autre site en tgg beta3, j’ai bien :
body id= »payment-redirect »
Bonsoir,
cela est dû à la compatibilité du module avec les version 1.3.x de Prestashop me poussant à ne pas implémenter le modèle de FrontController des versions 1.4.
Pour combler ce manque en attendant que je corrige cela de mon côté, vous pouvez ajouter la ligne
$smarty->assign('page_name', 'tgg_atos-'.basename(__FILE__, '.php'));
avant l’appel à
$smarty->display(...à la fin du fichier tgg_atos/front-ctrl/payment-redirect.php
Bonjour,
Le module a été installé après une mise à jour 1.2.5 vers 1.4.4.1.
Tout fonctionne parfaitement bien, mise à part l’ ID de transaction qui revient au numéro initialement paramétré tous les 24 heures, est ce normal?
En tout cas Merci pour le travail.
Y a t il moyen de faire un petit don autre que paypal?
Oui, ATOS spécifie l’unicité des IDs de transaction sur la journée uniquement, les IDs consommés sont donc libérés dès que possible par le module pour permettre aux boutiques à forte affluence d’afficher jusqu’à 999 999 fois le formulaire de paiement.
Je vous envoie un RIB par email si vous souhaitez effectuer une donation par virement.
Merci pour votre travail…je teste courant septembre et je fais immédiatement un don.
C’est la moindre des choses vu le prix qui est demandé ailleurs pour ce genre de module.
Merci encore…
Bonjour,
merci pour ces paroles des plus agréables, cela dit sachez qu’il est normal que les autres modules soient plus cher, en effet dans un logiciel ce qui coûte le plus cher ce sont les bugs. N’ayant pas eu trop le temps d’en ajouter dans le mien, et ayant même l’effronterie de retirer ceux que l’on me rapporte, il est donc normal que celui-ci soit gratuit ;-).
Bonjour!
Comme beaucoup, me voilà stoppé net dans mon élan par « Le paiement par carte est indisponible jusqu’à demain,… ». Cela fait quelques heures que je parcours les différents posts relatifs à cette erreur, et après avoir appliqué les différents correctifs proposés, rien y fait, l’erreur persiste…
Le chemin spécifié des deux fichiers binaires REQUEST et RESPONSE est le bon, les droits alloués aux différents répertoires sont les mêmes que dans votre doc (même en 777 ça ne marche pas…),la compatibilité a été vérifiée…
De plus, mise à part l’erreur status 127, je ne reçois pas de mail avec l’adresse renseignée en back-office , pourtant j’utilise la même adresse aussi bien comme webmaster que service client, et les mails clients me parviennent bien.
J’ai également la case « Mon serveur détient les binaires ATOS,… » de coché. Je vous avouerais que je n’ai d’ailleurs pas vraiment compris le rôle de cette checkbox. Serais-je passé à coté de quelque chose d’évident?
Je souhaite également vous remercier pour le formidable travail de debuggage que vous faites, peu se sont autant investi dans le recettage que vous…
Bonjour, la case « Mon serveur détient les binaires ATOS,… » est réservée pour le cas spécifique où les binaires doivent être appelés sans préciser le chemin comme c’est le cas sur certains hébergement mutualisé où les binaires ont été installés pour être utilisé par tout le monde (dans /usr/bin par exemple). La cocher dans tout autre cas provoquera une erreur.
En règle général, il vaut mieux éviter de toucher à l’onglet « Avancé » lorsque que l’on ne sait pas trop à quoi correspondent ces options ;-).
Le fait que vous ne receviez pas les mails, ce que m’avait déjà rapporté une autre personne avant vous, m’inquiète fortement car c’est un élément que je juge indispensable à un débogage efficace. M’autoriseriez-vous à accéder à votre hébergement pour essayer de trouver la cause de non réception des mails ? J’en profiterai bien-sur en échange pour déterminer la cause du problème principale…
Je vous envoie un mail pour que vous puissiez me répondre en toute confidentialité.
Bonjour,
Même problême ….j’avais testé pendant quleques heures et lut les différents posts, puis mis de coté . Je me remet dessus en me disans avec le break je vasi trouver …pareil.
J’ai mis les droits, installé le module (en n’ayant aucun message d erreur relatif au droits , a l absence des bin ou aux chemins trop longs).
J’active le debug et j’ai :
[« status »]=> int(127)
en haut de page et recoit par mail :
L’exécutable request a retourné une erreur.
(127):
J’utilise mercanet.
Merci pour tous ce boulot et cette dispo !!!
hummmm, dsoél de cette pollution , je me demande si il y a pas une histoire de bin x86 sur du 64 ….
bonjour,
Je recoit erreur 127 sans aucune autre explication.
J’ai vérifié les binaires, les chemins les droits je ne comprends pas . Pourquoi n’ai je pas le detail de l’erreur ?
Merci de votre aide.
Bonjour,
Le detail de l’erreur est fourni, si vous n’avez rien d’autre c’est que votre système d’exploitation n’a pas renvoyé de message d’erreur. Cela vient généralement de binaires incomptibles ou transférés par erreur en mode ASCII par FTP, donc corrompus.
merci.
Des que résolut je vous copierais la cause :p
problême résolut, évident mais bon ….
Safe_mode on …..
corrigé avec passafe safe_mod a off, peut aussi se corrigé en placant les bin dans le repertoire safe_mod_exec_dir suivant la sécurité voulue.
Par contre en retour de paiement, je retombe toujours sur modules/tgg_atos/front-ctrl/payment-return.php au lieu du site, peut etre parceque je suis en debug ?
Merci pour le boulot, un gain de temps precieux, et à la maniére des stars cachant leur Bonne actions, je ne préciserais pas que j’ai fait un don :p
Bonjour,
J’utilise avec succès votre module et vous remercie pour votre travail.
J’aurais besoin d’une fonctionnalité supplémentaire, qui a priori n’est pas supportée actuellement.
Il s’agit du retour automatique vers la boutique :
Le client clique sur le logo de sa carte bancaire > il arrive sur le site d’atos, entre son numéro de carte bancaire et clique sur valider > il est automatiquement redirigé vers le site marchand en cas de succès de paiement.
Cela permettrait de placer le tag de conversion (en l’occurence Lengow) une fois la commande passée, pour calculer de manière 100% fiable le ROI. Cela fiabiliserait aussi d’ailleurs le suivi des conversions Analytics ou autres.
Car actuellement, une fois le paiement accepté, le client doit cliquer sur « retour à la boutique », et uniquement dans le cas où il clique sur ce bouton, la conversion est enregistrée.
Je précise qu’a priori, on ne peut pas placer le tag sur l’url silencieuse car le tag ne fonctionne pas, cette page n’étant pas visitée par le client mais par le serveur de paiement.
Cette fonctionnalité existe sur la version payante développée par Prestashop.
Atos supporte cette fonctionnalité car Mercanet me précise « Cette procédure de redirection automatique vers votre site après paiement est possible en paramétrant le champs DATA de votre call request. »
Je suis évidemment prêt à financer cette fonctionnalité dont j’ai un besoin urgent !!
Merci d’avance,
Bonsoir,
oui je connais bien cette problématique et cette modification est en stack-list pour la milestone 2.2. Cette modification nécessite que je fasse quelques menus arrangements car les données transmises dans ce mode sont moins complètes que dans le mode standard, aussi il va falloir modifier un peu le process de traitement de la réponse bancaire utilisateur sans altérer le traitement de la réponse silencieuse.
Je vous contacte par mail pour que nous puissions en discuter.
Bonjour Damien,
Pourrais tu me contacter par email pour la meme problématique. Je test actuellement ton module mais j’ai besoin de tracker mes commandes avec un tag de conversion.
Merci
Bonjour Damien,
Comment allez-vous ?
Je suis également dans ce cas précis (besoin de redirection automatique apres paiement CB).
Je souhaiterais pouvoir suivre les conversions et ainsi qualifier l’analyse du ROI.
Pourriez-vous me contacter à ce sujet ?
Merci,
cf version 2.1 RC 6
En ce qui concerne la redirection automatique vers le site marchand sans attendre que le client veuille bien cliquer sur « Retour vers la boutique », voici une solution que j’ai dû mettre en place pour pouvoir récupérer systématiquement les données à destination de Google Analytics :
– Dans le parmcom, rajouter l’instruction :
DATA!NO_RESPONSE_PAGE!
Ceci renverra directement sur la page payment-return.php. Toutefois, il faut faire une petite modification car dans ce cas de figure les données sont renvoyées par méthode _GET. J’ai juste modifié la ligne :
$response = $_POST[‘DATA’];
par
if(isset($_POST[‘DATA’]))
$response = $_POST[‘DATA’];
if(isset($_GET[‘DATA’]))
$response = $_GET[‘DATA’];
(Attention, pour info, j’ai commenté le contrôle sur _POST[‘DATA’] qui est fait juste avant dans le code).
Si ça peut contribuer à l’amélioration du module, très utile je dois dire au passage. Merci !
Bonjour,
merci beaucoup pour votre retour, par contre ces modifications sont incomplètes et provoqueront des erreurs lors de la validation de la commande à cause de l’absence de certaines données de retour.
J’ai de mon côté fait ma propre implémentation de cette fonctionnalité, cf version 2.1 RC 6.
Bonjour,
Merci beaucoup pour votre module, je suis en train de le tester.
Pouvez-vous m’indiquer ou se trouve la variable templatefile dans vos fichiers pour que je puisse ajouter mon template.
Merci d’avance.
Bonjour,
actuellement rien n’est prévu pour la gestion des templates, les variables doivent soit être écrites dans le parcom du service (celui de votre ID marchand est réécrit à chaque soumission d’un onglet de configuration dans le back-office module), soit dans le tableaux des paramètres envoyés à l’exécutable (en fin de fonction tgg_atos::getPaymentForm()). Je vous envoie par mail une RC de la 2.1 qui attend que j’ai du temps pour finaliser la 2.0 stable et la publier avant de commencer les stages RC de la 2.1. L’un des intérêts de cette 2.1 est la présence d’un XML pour déclarer des variables supplémentaires à inclure à l’appel des exécutables, ce XML est justement prévu entre autres pour permettre de personnaliser les pages bancaires via l’API ATOS.
Bonjour,
Tout d’abord, merci pour cette contribution.
J’utilise votre module sur ma boutique, cependant, lors que j’arrive sur la page payment_redirect… j’ai un gros Internal Server Error.
Auriez vous une idée de l’origine de ce problème? il ne me semble pas l’avoir eu en mode test.
Merci de votre aide.
je m’auto répond… OVH n’aime pas les droits 777 =)
Bonjour Damien,
Tout d’abord bravo et merci pour ce module qui m’a fait gagner pas mal de temps dans la mise en place du paiement en ligne pour plusieurs boutiques.
Je viens ici faire un petit retour sur un souci que j’ai rencontré et que d’autre pourrait rencontré à leur tour. Aillant mis 1h pour un problème tout bête je me suis dit que ça pourrait aider 🙂
Avec le système de paiement du Crédit Agricole e-transactions, le fichier param.etransactions a changé de nom ! Pour devenir param.e-transactions.
Le message que je rencontrais :
L'exécutable request a retourné une erreur.Error reading default parameters definition (/home/MY_PATH/atos/param/parmcom.etransactions)
J’ai donc renommé le fichier param.e-transactions fourni par la banque en param.etransactions et ça marche !
J’espère que ça peut aider !
Bonjour,
Est-ce que votre module marche pour la banque caisse d’épargne (SP PLUS)? Si oui quelle configuration faut faire?
Merci
Bonjour Damien,
Un grand merci pour ton module pour lequel je vais faire rapidement un don !
Installation ok. Pour l’instant tout va bien. La suite des tests quand j’aurai le retour de la banque avec le kit Mercanet et les infos complémentaires (id, certificat, etc..).
La doc est claire et je viens de lire tous les posts ci-dessus (qui apporte souvent le petit plus)… Mal aux yeux donc !
Je reviens vers toi à la mise en pré-prod pour te remercier une nouvelle fois ! 😉
Jérôme
Bonjour,
je vien d’installer ce module (super boulot d’ailleur) avec toutes les modifs préconisé dans le tuto et j’ai une erreur de certificat : « API ERROR : Error reading certificate data at line »
Une idée ?
Merci.
Sans le message d’erreur complet il est difficile de répondre précisément mais le problème le plus courant est le problème de longueur du chemin vers les fichiers de parametres. Avez vous une erreur lorsque vous etes sur la page de configuration du module ?
Bonjour,
Même si cela fait plus d’un mois, je me permet d’apporter ma petite pierre à l’édifice, qui pourra surement aider certaines personne s’étant retrouvé avec cette erreur (qui n’est pas du tout lié au module ceci-dit 😉 ).
Cette erreur provient du certificat téléchargé. En effet, lors de la récupération du certificat chez la banque partenaire (Sogenactif d’après ce que je vois), il ne faut pas commettre l’erreur de récupérer le certificat au format PHP. En effet, le certificat qui est attendu ici est celui intitulé « Classique », soit, un certificat tout ce qu’il y a de plus normal.
En espérant que cela en aidera d’autres qui auront eu cette erreur.
Merci beaucoup Damien en tout cas pour la réalisation de ce module qui fonctionne à merveille.
Bonjour Damien, je viens t’offrir mon soutien par un second don et t’ai à ce titre envoyé un email. Si tu peux le consulter, je t’en remercie (à ce propos ton adresse email de réponse automatique n’est plus valide puisqu’il m’est revenu direct)
Cordialement !
Bonjour,
Merci Damien pour ce module bien conçu et facile d’accès. Et merci surtout de le rendre disponible gratuitement à la communauté.
Nous sommes actuellement en phase de pré-production sur le serveur bancaire et tout fonctionne correctement. Seul hic avec le module (comme mentionné plus haut) la possibilité d’avoir un retour automatique vers la boutique si la transaction a abouti car si le client ne clique pas sur le lien de retour vers celle-ci la commande n’est pas prise en compte dans l’interface de gestion.
Avez-vous des pistes à me suggérer qui me permettent de modifier les sources du module afin d’activer cette possibilité de réponse automatique, ou peut-être les récents développements du module intègrent-ils déjà cette fonctionnalité ?
Cordialement.
Bonjour Damien,
Suite à la mise en place de ta version 2.0 rc4 sur ma nouvelle boutique prestashop 1.4.4
j’ ai un message d’ erreur après que le paiement ai été accepté.
Ce message apparait quand on fait un retour à la boutique:
« La création de la commande a échoué »
La commande ne s’ inscrit pas dans le back office.
je sais que cette question à peut être été traité plusieurs fois mais je ne sais pas comment la rectifié.
( peut être faut ‘ il modifié quelque chose dans le fichier « payment-return.php »)
je suis vraiment novice.
Merci par avance pour ta réponse.
Bonsoir,
ce cas ne me dit rien, il est possible qu’il m’ait déjà été soumis mais je n’en ai pas souvenir.
Je vous envoie un mail pour que vous puissiez m’envoyer en réponse un accès au serveur que je puisse examiner le problème.
Bonjour,
Je me permets de poster ici car à la lecture de tous les commentaires je me pose des questions.
Je vais mettre en place un système de paiement BNP Paris Mercanet
Donc apparement Atos,
– Je suis sur un hébergement mutualisé OVH
– D’après la doc je vais avoir un certificat et ils proposent des API à télécharger.
(Je n’ai pas encore reçu le mdp par courrier mais je m’intéresse aux modules à l’avance)
Penser vous que ce module fonctionne dans ce cas la ?
Bonjour,
Pas de problème, c’est toujours comme ça.
Récupérez votre certificat de production et insérez-le dans le module lorsque vous serez satisfait de votre configuration en mode demo.
Bonjour et MERCI pour ce module indispensable pour nos boutiques!
Est il possible de configurer un compte 3D secure?
Actuellement en pré-prod, chez LCL (sherlocks) je n’ai aucune erreur avec le debug mode activé mais je me retrouve avec une page jaune avec pour seule info « Transaction invalide » à cette adresse : https://sherlocks.creditlyonnais.fr/cgis-payment-sherlocks/demo/callpayment
Que fais-je de mal?
Merci pour tout
Bonjour,
L’URL que vous m’indiquez est une URL de demonstration et non de (pre-)prod si je ne m’abuse.
Tout le monde se partage le meme compte en mode demo (le compte demo, il y en a un par banque), ainsi il suffit que les IDs de transactions que generent le module aient deja ete utilisés aujourd’hui par une autre personne pour obtenir ce resultat.
Fixez un ID mini de transaction plus haut et réessayez.
Bonjour,
Trés bon boulot, une jolie piece de code.
Je viens d’installer la rc4 sur un presta1.4.4.1 en locale sur un serveur
virtuel sous wamp.
Pas de soucis particulier pour sa config, chemin des binaires etc etc.
Je passe sans probleme sur le serveur de test d’etransactions.
J’utilise les codes de cartes pour ok et annulé, le serveur repond correctement aux
deux requetes.
Cependant, je suis obligé de valider le retour boutique pour que
l’integration de la commande sois bien prise en compte dans la boutique (suite
au retour sur cette derniere ).
Je presume que ce soucis vient soit des ip serveur non acceptées( pourtant la boutique est hors maintenance) ou je pencherais plutot pour un parametrage du fichier parcom avec les references url de retour que je ne connais pas?
A premiere vue la reponse automatique (silencieuse) ne passe pas.
Le virtual host que j’utilise en local est celui d’un site en prod sur la toile car
je dois bientot le passer d’osc vers presta, ce qui me laisse a penser que
mon url de reponse va atterrir et se perdre sur le site de prod et non le local.
Je viens de verifier les url de retour via le debug du module et effectivement
elles sont bien renseignées, donc la requete d’autoreponse est bien executé mais se
conclu sur une 404 sur le site osc en prod, logique…
Ma question est donc la suivante: Comment pourrais tester l’autoreponse etc sur un vhost en mode test great codemaster ?
Best regards,
Sam
Le problème est que pour le retour silencieux votre boutique doit etre accessible via une adresse routable depuis la toile car c’est le serveur de banque qui emet cette requete. Les adresses de loopback (localhost, 127.0.0.1) sont par definition non routables depuis une autre machine, ou plutot routables mais pas vers votre boutique.
Si votre boutique locale est routable via une DNS ou une IP internet, saisissez-la en tant que domaine de retour auto/silencieux dans la config module et… Shazaaaam !
Sinon vous faudra attendre l’hebergement definitif pour que le retour auto fonctionne, n’oubliez cependant pas de le tester a ce moment.
Merci pour ces precisions techniques Damien.
Je vais bientot entamer la migration sur le site en prod, je testerais donc ceci en live.
Best regards,
Sam
Bonjour à tous.
Je cherche à télécharger le module atos/sips. Je trouve pas le lien pour le télécharger.
Un grand merci à Damien pour le module.
Un petit effort, il est en bas de l’article…
Bonjour Damien,
D’abord bravo pour ce boulot et aussi pour ce partage gratuit, et je te félicites de ta patiente à répondre à tous les questions en espérant que tu fasses de même pour la mienne 😉
A priori avec ton module les urls de retour sont configurées automatiquement ? Il n’y a plus besoin de les mettre dans le fichier parmcom ?
Je pose ces questions pour essayer de tracer un peu la réponse silencieuse mais à priori le fichier n’est pas appelé car pas de log et le panier ne passe pas en commande alors qu’en fonctionnement « Je clique sur le bouton retour à la boutique » tout est ok.
Je suppose que si ça fonctionne en cliquant sur le bouton « Retour à la boutique » ça devrait également fonctionner avec la réponse silencieuse ou je me trompe ?
Je suis pourtant en pré-prod, penses-tu que je doive plutôt m’adresser à ma banque ?
Merci et bonne continuation
De nouveau moi, le site étant en phase de développement je n’avais pas pris en compte que j’autorisais seulement certaines IP à le voir, du coup la requête envoyée par la Banque avec une IP inconnue ne pouvait effectivement pas aboutir.
C’est donc ok pour mon erreur, et je peux donc dire que le module marche parfaitement sur Prestashop 1.4.4.1.
A bientôt peut-être …
Bonjour,
Je galère un peu avec ce module, en effet après le bug des 54 caractères, l’erreur 127, je bloque sur l’erreur -1.
Je tourne sur un prestashop 1.4.1.0, ce module et c’est pour une utilisation de mercanet.
Merci d’avance pour vos idées et pistes de réflexion.
Comme d’habitude: vérifier les droits du dossier bin, la désactivation du safe_mode et la compatibilité des binaires avec la plate-forme d’hébergement.
Bonjour, j’ai cherché un peu partout sur le site une réponse à cette erreur mais je ne trouve pas.
Pouvez-vous avoir la gentillesse de m’éclairer et/ou de m’aider
l’erreur en mode debug est : Error in call parameters structure (payment_means,block_order).
Grand merci
Bonjour Damien,
Bravo pour ce module vital !
Je suis passé à la v2 RC 4 il y a 2 mois, aucun soucis à relever si ce n’est aujourd’hui un mail d’erreur qui me dit :
« La banque a renvoyé une réponse invalide.
Le panier dont l’ID a été retourné dans le champs id_order n’appartient pas au client dont l’ID a été retourné dans le champs id_customer »
je ne vois pas comment cela a pu être possible ? pb du à prestashop ou au module ?
Au passage étrange que l’id_order contienne l’id du panier et pas de la commande…
Précision, je suis en prestashop 1.3.7 chez un hébergeur louant à priori des serveurs chez OVH.
Bonjour, cela peut indiquer une tentative de falsification d’une réponse bancaire.
Une autre chose qui pourrait provoquer cela : un « bricolage » raté du module pour essayer d’implémenter le retour automatique (DATA=NO_RESPONSE_PAGE). J’ai reçu beaucoup de message de personnes prétendant avoir implémenté cette fonctionnalité sur ce module mais quand je lis leur code je vois qu’elle est incomplète et provoque ce genre d’erreur. Pour information, une version du module implémentant cette fonctionnalité est prête et arrivera prochainement, je n’ai pas encore eu le temps de la diffuser.
Je vous envoie un mail pour que vous puissiez me transmettre les logs associés si vous souhaitez que je jette un oeil de plus près.
Au passage, lorsque l’on connait Prestashop, le fait que l’ID de commande ATOS contienne l’ID de panier Prestashop n’a rien d’étrange puisque le panier n’est converti en commande qu’à la confirmation du paiement.
Bonjour Damien
Tout d’abord bravo pour votre module, excellent il en est.
Ensuite je tiens à vous exposez mon problème, sachant que je ne suis ni un pro de prestashop ni du php, bien que je connaisse quelqu’un de bon qui puisse m’aider au besoin sur le php.
J’ai installé ce module sur le site d’une amie qui souhaitait créer son site de vente en ligne pour les produits qu’elle fabrique.
Le site est installé sur un serveur (non local) pour la mise au point avant d’être transféré sur le serveur distant.
Après avoir fait tous les tests sur la partie démo qui se sont bien passé, j’ai mis en place le certificat final e-transactions pour passer en mode pré production.
C’est là que les problèmes commencent.
Quand j’installe le certificat via le formulaire, une fois soumis cela m’affiche malgré tout que pour l’id marchand aucun certificat de production trouvé.
Bien sur en vérifiant via ftp, le certificat est bien en place dans le dossier param.
J’ai donc quand même effectué un test d’achat, tout se passe bien jusqu’à cliquer sur l’icone de la cb et je tombe sur un écran jaune : « transaction invalide… »
Pour l’instant je suis bloqué à cet endroit.
Le module est la rc4 sur un prestashop 1.3.7.0
Si tu penses que pour m’aider il te faille avoir les codes d’accès au site ainsi qu’à la bdd, je te les envois par mail.
Merci pour ton aide et encore bravo pour ce module.
didier
Bonjour, je ne comprends pas vraiment « pour l’id marchand aucun certificat de production trouvé ».
Le sélection de l’ID marchand se faisant par la sélection du certificat je ne comprends pas… Je vous envoie un mail.
Bonjour Damien,
Un module de bonne qualité, très facile à installer et à paramétrer. Je rejoins d’autre personne sur le besoin quasi indispensable d’un retour automatique vers la boutique, car sinon on se retrouve avec des commandes non enregistrées et il faut aller à la pêche dans les paniers pour retrouver ses petits.
Je suis preneur d’être beta testeur si besoin, car intégrant la solution Prestashop pour mes sites et les sites de mes clients, j’ai déjà de nombreux sites équipé de modules ATOS.
Bien cordialement
Patrice
Bonjour Damien,
J’évoquais dans mon post le risque de ne pas avoir la commande si pas de clic sur le bouton ‘Retour à la boutique’ de la banque. En fait, je viens de tester, et même sans cliquer sur le retour à la boutique la commande est bien enregistrée dans le back-office de Prestashop. Donc dans ce cas le retour vers la boutique est moins critique, même s’il reste appréciable.
Patrice
Bonjour Patrice,
premièrement merci pour le don ;-), cela permet de maintenir la motivation à passer toutes ces heures à maintenir le code source et le faire évoluer ainsi que tout ce qui va autour (répondre aux demandes, entretenir ce site, préparer un site plus adapté… d’ailleurs ironiquement ce sera probablement un Magento qui remplacera ce blog pour diffuser le module).
Pour ce qui est de la prise en compte des commandes sans que l’utilisateur clique sur le retour boutique, c’est bien-sûr implémenté dans la solution, c’est pour moi une fonctionnalité incontournable. Par contre deux facteurs sont nécessaires pour que cela fonctionne :
L’adresse (domaine) de retour automatique doit être routable par le serveur bancaire (donc pas d’IP ou de noms de machines locales)Ajouter l’IP du serveur ATOS dans les IP de maintenance si votre boutique est en maintenance
Pour votre proposition de bêta-test, cela tombe très bien : je m’apprête à diffuser la 2.1 RC 6, elle implémente le retour forcé entre autres, et tout bêta-testeur est le bienvenu. Je devrais publier le nouveau ticket dans la journée.
Coucou,
Je voudrais juste une confirmation, car j’ai « peut être dit une connerie » (même si ça me semblait logique). J’utilise ton module de paiement qui marche à merveille.
Certains de mes clients me disent « je ne comprends pas, parfois, certaines commandes ne sont pas loguées dans la section commande et reste dans la section panier ».
Je dis toujours » c’est normal, je pense que votre client n’a pas cliqué sur le lien « retourner à la boutique ». Du coup, le retour paiement ne peut pas cibler modules/tgg_atos/validation.php et du coup on ne put pas monter la commande dans la section commande.
Est-ce que cette constatation est correcte ? Parce que je ne pense pas que ton module logue dans les commandes un panier avant qu’il y ait eu paiement. Et le seul paramètre qui te dit qu’il y a eu paiement, c’est bien l’url de retour.
Donc… est-ce que j’ai raison en disant ça sur sips/atos en général ?
Cordialement
Bonjour,
Heureusement il existe un retour automatique (appelé aussi retour silencieux) qui permet de prendre en compte la commande même sans que l’utilisateur ne clique sur le bouton retour.
Il faut tout d’abord vérifier dans les logs que ces réponses sont bien reçues (identifiables via le champs « origin »). Si les réponses sont bien reçues, il faut plutôt chercher du côté de modules qui pourraient être liés au hooks de création de commande ou de changement de statut et qui pourraient bloquer le process.
Salut,
ton module est super mais je ne voit pas comment l’intégrer avec un spplus de la Caisse d’Epargne! Peu tu me donner la marche à suivre?
Bonjour, réponse dans la FAQ de la doc incluse avec le module.
Sinon vous pouvez aussi me transmettre le logo de la banque et leur kit de démo pour que je les ajoute au module.
Tres franchement, super ton module !! bon j’a
Bonjour et bonne année,
j’utilise ce module depuis juin et j’ai un petit soucis avec le délai de capture qui ne fonctionne pas. J’ai paramétré le module sur 30 jours et atos me signale que les parametres envoyés ne correspondent.
Cordialement
Bonjour, le mode de capture et le délai de capture sont-ils accordés en conséquence ?
Bonsoir,
J’utilise votre module sur une boutique prestashop 1.4.6.2 Il a très bien fonctionné pendant plusieurs mois … mais je reçois désormais le message classique :
Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient.
D’après la doc, si j’ai bien lu, il s’agit d’une erreur dans l’exécutable request. Je suis donc passé en mode debug et le retour est :
… [« status »]=>
int(4)
Malgré mes recherches, je ne suis pas arrivé à trouver la signification de ce code. Merci d’avance pour votre aide. Cordialement,
Bonjour,
les message d’erreur sont envoyés par mail et non affichés sur la boutique (je suis un peu las de le répéter d’ailleurs).
De plus pour comprendre ce que signifie le code de retour 4 il faut se reporter à la documentation de votre système d’exploitation.
Bonjour et bonne année,
dans quel fichier se trouve la variable « délai de capture », car j’ai beau la régler sur trente jours, le délais pris en charge est de 6 jours (celui par défaut).
Y a t-il un moyen de vérifier la variable envoyée à atos.
Atos me dit ne pas avoir de restriction et recevoir le délai par défaut.
En te remerciant
Le délai de capture se configure depuis le back office dans l’onglet configuration basique.
merci damien pour ta réponse,
le service d’atos m’avait assuré ne pas avoir de restriction de leur côté et mettait en doute l’intégrité de ton module, je pensais que la variable ne passait pas chez atos. Mais après 3 semaines ils ont découvert une restriction sur le délai de capture…
désolé pour le dérangement.
Merci pour le retour d’information
Salut, tout d’abord félicitations pour ce module et ton esprit d’entraide et de partage !
Une simple question, concernant le contrat VAD à passer avec la banque, en l’occurrence le Crédit Mutuel … il est indiqué dans leur maigre doc en ligne que :
« pour gérer les paiement en ligne (…) 2 façons :
– manuelle via un tableau de bord depuis leur site sécurisé
– ou » Par échange informatique, lorsque vous souhaitez automatiser le traitement de ces opérations. Nous mettons à disposition un format de requête informatique qui vous permet de traiter les paiements de vos clients, en temps réel ou en rafale. Ce mode de fonctionnement est disponible dans le … » pack le plus cher forcément.
Si je ne me trompe pas, pour utiliser ce module, il faut la 2ème option, non ?
source : https://www.cmcicpaiement.fr/fr/fonctionnalites/fonctionnement/index.html
Merci de cette confirmation ! … je ne voudrais pas faire souscrire la mauvaise option au client.
bonne soirée !
uGo
Bonjour,
je pense que dans la phrase « Par échange informatique, lorsque vous souhaitez automatiser le traitement de ces opérations. » ils parlent de l’automation des prélèvements automatiques ou de validation des transaction lorsque vous fonctionnez en mode validation manuelle (en ce mode de fonctionnement les transaction ne sont pas effectuée sauf sur validation de votre part dans les délais fixés soit sur leur back office soit via un système automatisé entre votre compta et la banque, ce mode est utilisé pour pouvoir annuler des transactions faute de stock pour honorer la commande dans les délais sans avoir de remboursement à faire par exemple). Mon module n’a pas besoin de ces fonctionnalités, d’ailleurs il est malheureusement en l’état incapable de les exploiter. Mais seul votre banque peut vous dire ce qu’il en est.
Bonjour
Le site donc je m’occupe tourne actuellement sous Presta 1.4.6.2 et j’utilise la version 2.0-beta4-rc-4 de votre module. Je souhaiterais savoir s’il était possible de rajouter la possibilité de payer avec la carte American Express. Mon client tient à cette possibilité.
Merci d’avance,
Julie
Je me suis penchée sur les fichiers à l’intérieur du module et j’ai vu comment on pouvait rajouter American Express. Dans la configuration du module, dans les moyens de paiement acceptés, il faut rajouter AMEX tout simplement ! J’avais essayé « American Express » ce matin mais ça ne fonctionnais pas, avec AMEX ça fonctionne à merveille ^^
Voilà
Bonne fin de journée
Bonjour, désolé pour le retard de la réponse, en effet, il suffit d’administrer les moyens de paiement en accord avec la documentation ATOS.
Bonjour Damien,
Tout d’abord bravo pour ta contribution.
Je mets en place une boutique sous prestashop V1.4.7.3.
Ton module version 2.0 RC4 m’a carrément ôté une épine du pied.
2 petit soucis lors des tests (pour aider les autres utilisateurs non experts comme moi) :
– message d’erreur code 126 « permission denied » en raison d’un mauvais paramétrage des droits d’accès aux dossiers et fichiers sur mon serveur
– message d’erreur « Error reading default parameters definition » car le fichier fournipar la banque s’appelle « parmcom.e-transactions » alors que ton module cherche « parmcom.etransactions »
Mais une fois qu’on a dépassé ces petits bugs d’install, c’est que du bonheur.
Bravo ! et je vais bien sûr apporter ma contribution financière pour soutenir la cause !!!
Steph
il faut en effet renommer le parmcom fourni par la banque pour qu’il corresponde à celui présent dans le module s’il diffère. Ce parmcom ci a été raccourci de son ‘-‘ pour gagner 1 caractère sur la limite du path vers les fichiers de paramètre tout en restant reconnaissable.
Merci pour vos retour qui peuvent effectivement aider les autres utilisateurs (enfin les quelques uns qui prennent le temps de chercher une réponse avant de poser une question qui l’a déjà été de nombreuses fois ;-))
Bonjour,
Version prestashop : 1.4.2.5 version module : SIPS/ATOS v2.0-beta4-rc-4
Hébergement :
Version de PHP: 5.2.17
Version de MySQL: 5.0.91-log
Nous avons actuellement votre module installé sur notre site pour le paiement par carte bancaire avec scellius – la banque postale (et il fonctionne parfaitement).
Nous souhaitons utiliser une autre banque (cetelem/atos) pour mettre en place le paiement en plusieurs fois par cb. Est-il possible d’utiliser 2 banques différentes avec le module ? Si oui, pourriez-vous nous indiquer la marche à suivre.
Cordialement,
Bonjour,
seule la version 2.1.7 alpha 2 à l’heure actuelle en phase de bêta-test est capable de gérer des banques différentes par l’override du pathfile (possible à partir de la version 2.1.7 alpha 2) et du merchant_id depuis le fichiers params.xml (introduit dans la branche 2.1.x).
Cela nécessite de bien connaître le système de configuration Atos.
Si vous avez l’habitude de configurer Atos à la main cela ne vous posera pas de problème, si vous trouvez la configuration de ce module déjà complexe autant abandonner et utiliser deux modules ou faire appel à un technicien compétent.
Pour participer aux bêta-test (réservé aux techniciens confirmés qui acceptent de faire l’effort de venir ensuite critiquer le module, détailler ce qui a été testé, ce qui fonctionne, ce qui devrait être amélioré ou ce qui plante en précisant les informations de contexte nécessaires à le reproduction de l’erreur) il suffit d’en faire la demande dans le fil de commentaire de l’article déclarant l’ouverture des bêta-tests privés.
Bonjour,
Tout d’abord un grand merci pour ce développement fort utile vu les lacunes du module ATOS. Malheureusement, je ne parviens pas à le faire fonctionner.
Sur une offre mutualisée pro OVH et Prestashop 1.2.5 fourni par OVH, après décompression de l’archive dans modules, l’installation se fait normalement tout est bien configuré, avec deux répertoires déplacés à cause des 54 caractères. Mais en mode test dans le choix du paiement, si j’ai bien un choix Pay with a card (l’image associée n’apparaît pas), le lien, lui, pointe sur …/modules/tgg_atos/tgg_atos-payment-redirect.php alors que ce script ne figure pas dans l’archive…
Avant cette beta 2.0 RC 4, j’avais installé une version 1.x que j’ai désinstallée et qui elle contenait ce fichier. Comme s’il restait un fichier de configuration associé à la version précédente…
Auriez-vous une piste ?
En vous remerciant,
Will
Bonjour,
Je vois deux origines probables à votre problème :
prestashop/tools/smarty/compileetprestashop/tools/smarty/cacheà chaque modification d’un template si ces caches sont actifs)/prestashop/themes//modules/tgg_atos/ ) et ne les avez pas purgés après la mise à jour. Les thèmes exportés sont prioritaires par rapport aux thèmes par défaut inclus dans le module.Par contre quitte à mettre à jour le module, préférez la dernière version ayant un âge suffisant. A moins que vous ne rencontriez un problème de compatibilité avec, la branche 2.1.x est à préférer à la 2.0.x. La 2.1.6 est actuellement la plus récente à pouvoir être qualifiée de stable.
Merci beaucoup. Cela était bien une histoire de cache. J’en ai profité pour suivre votre conseil en installant la 2.1.6. Et tout fonctionne parfaitement. Quelle différence avec le module Atos !
Il reste une fonctionnalité qui ne semble pas prise en compte (peut-être due à la version Prestashop 1.2.5 fournie par OVH ou à la limitation ATOS). Quand je sélectionne une autre devise que l’euro, mettons $ australiens et langue anglaise, les différentes étapes du paiement prennent en compte les AUD $ jusqu’au choix du paiement « Pay by card » où une information est donnée : Euro will be used.
Existe-t-il un moyen de contourner cette limitation, ou simplement d’ajouter à côté de la valeur en Euros, celle de la devise choisie par le client…
Encore merci.
Will
Bonjour,
Pour pouvoir exploiter une devise avec le module il faut respecter trois points :
Bonjour,
Effectivement je viens d’appeler la Banque Postale et leur solution Scellius. Ils m’informent qu’actuellement ils ne proposent que le mode monodivise pour leurs clients. Bien dommage.
Merci pour votre réactivité.
Bonjour Damien,
Déjà merci pour la solution gratuite, elle est top 🙂 Et puis les banques, entre payer 500€ d’activation et encore 250€ pour le module ça va … !
J’utilise ton module 2.0 BETA 4 RC 4 depuis 1 an sur prestashop 1.4.2.5
Depuis 2 mois, j’ai rencontré 2 fois le même problème :
Le client commande, paie, paiement validé envoyé en banque, il reçoit la confirmation par mail. Jusque là tout va bien.
Le problème est que moi je n’ai rien. Ni mail, ni validation, ni même erreur dans les commandes. Par contre quand je clique sur le client, je vois un panier, un paiement validé mais le statut (liste déroulante) vide et il y a en rouge au dessus : erreur invalide.
Je ne sais pas si d’autres ont déjà rencontré ce problème. Ma banque est BNP – Mercanet.
Autre petite question, je mets à jour mon site et change le répertoire (même nom de domaine) , je peux juste transférer le module et modifier le répertoire là où il faut le renseigner, où il faut re-configurer ?
Merci d’avance,
Charles
Bonjour,
vous êtes probablement confronté à ce problème induit par un autre module (je parie sur So-Colissimo, le roi en la matière).
Concernant le prix des modules il n’est pas si élevé si on considère le temps à passer en support pour aider à l’installation… (Dites-vous qu’il faudrait que je gagne en moyenne 15€ par réponse que je fais sur les commentaires si on considère le temps que je passe à étudier les différentes causes possibles, à faire des tests, des inspections de code, à demander les informations nécessaires pour répondre pour ne plus perdre d’argent sur ce projet très largement déficitaire.) Par contre ce qui est scandaleux c’est la qualité déplorable de certains modules payants… Et le fait que ATOS/SIPS ou les banques pourraient commissionner un ou des développeurs pour développer un module complet et auto-diagnostiquant, le prix de développement est ridicule par rapport à leurs bénéfices. Par exemple, un module comme le mien coûterait à l’une de ces entités, disons entre 5 000 et 15 000€ selon les prestataires commissionnés… Ce qui n’est vraiment rien pour elles… Seulement ils préfèrent vous laisser payer chacun de votre côté, et surtout il faudrait qu’ils gèrent le support par rapport au module (ce que comme une pomme je me vois au final quasiment obligé de faire à leur place).
Bonjour et bravo pour cette addon, le seul aussi performant et gratuit,
je suis en version 1.4.4.0 de prestashop, avec agg_atos 2.0 beta 4 RC4.
Je n’arrive pas à comprendre les droits dans la documentation, j’utilise FileZilla pour les attributs il y a : persmissions du proprétaire (lire, écrire, exécuter), Permissions de groupe (lire, écrire, exécuter) et permissions publiques (lire, écrire, exécuter).
Lesquelles correspondante à : « 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 et lecture par tous ».
Quelles différence il y a entre, « par tous » et « pour tous » ?
Mon module fonctionnait très bien avant que j’essaye de faire une mise à jour vers prestashop 14.8.2, heureusement que j’avais fait une sauvegarde complète de mon site. Du coup, j’ai effacé totalement mon FTP, et remis la sauverge de mon site et maintenant j’ai une erreur 139 et je penses que çà vient des droits.
Merci.