Bonjour,
juste un petit billet rapide pour vous faire savoir que le module est bien compatible Prestashop 1.6, j’ai effectué quelques vérifications hier soir.
Donc bonne nouvelle
Je n’ai pas encore eu le temps de me pencher sur les modifications d’architecture 1.6 ni de faire des tests extensifs sur l’interaction entre les fonctionnalités Prestashop et du module, donc n’hésitez pas à me faire savoir si vous voyez des problèmes d’intégration avec cette nouvelle branche de Prestashop, de préférence sur l’interface Issues de GitHub.
Rappel de l’emplacement du projet GitHub :
https://github.com/TrogloGeek/prestashop-tggatos-module
Attention à penser à consulter les problèmes actifs sur l’interface Issues du projet GitHub.
————————————–
Version PrestaShop : 1.5.4.1
Module Tggatos Version : 3.1.0
Version PHP : 5.3.3-7+squeeze15
systeme d’exploitation : Linux x86_64
Apache 2.0 Handler
————————————–
Damien, Bravo!
Ce module fonctionne au top! Mode Démo et Prod nickel !! 😉
Merci pour tout ce travail et ces xxxx heures de code.
En plus d’être gratuit, il est beau!
Bonne Journée
Hello,
Je découvre ton module, je te ferais un rapide retour prochainement sur cette config:
Debian 7.0.4 x64
Nginx 1.4.7 + PHP5.4-fpm + Fastcgi
Prestashop 1.6.0.5
Avec CA E-Transactions 🙂
Bon bah le CA m’informe qu’ils abandonnent ATOS d’ici la fin de l’année, dommage :/
Très bonne chose au contraire, ATOS SIPS est le plus problématique des systèmes de paiement que je connaisse.
Yep, je disais dommage par rapport à ton module qui m’intéressait beaucoup pour étudier son fonctionnement pour mon rapport de fin d’études :/
Faut que je me motive à faire un équivalent Paybox :p
Bonjour,
quelle est votre source quant à l’arrêt de ATOS par le Crédit Agricole ?
Merci
Bonjour,
Ou puis je telecharger cette nouvelle version svp ?
j aimerais la tester !
merci d avance
Article mis à jour avec un rappel de l’emplacement du projet sur GitHub.
Bonsoir,
J’ai téléchargé le module sur prestashop 1.5 -> « Module téléchargé avec succès »
Mais il n’apparait pas dans la liste des modules ni dans répertoire /modules/
Avez-vous une idée ?
Merci
Josselin
Bonsoir, commentaire déplacé, merci de ne pas poster de demandes d’aide sur un article sans rapport avec la demande.
Merci de lire les règles de soumissions de commentaires avant de poster.
——
Quelle version ? Où vous l’êtes vous procurée ?
Vous assurer que vous avez bien utilisé une version 3.x, la branche 1.x est totalement obsolète, et la branche 2.x n’est pas compatible PrestaShop >= 1.5
Si ce n’est déjà fait, lire https://github.com/TrogloGeek/prestashop-tggatos-module#installation-differences-with-a-simple-prestashop-module
Bonsoir,
Merci pour votre réponse,
Je ne suis toujours pas parvenu à installer ce joli module téléchargé via un lien sur votre blog.
Module : Version : 3.2.0
Prestashop : 1.5.6.2
On doit ouvrir la boutique rapidement et je suis en galère !
Merci d’avance, Josselin
Si le module n’apparaît pas dans PrestaShop il est plus que probable que l’étape de renommage n’ait pas été respectée : le dossier téléchargé sur GitHub porte le nom du projet, il doit être renommé en tggatos, un renommage correctement effectué peut se contrôler facilement par la présence du fichier tggatos.php dans le sous-dossier tggatos/ du dossier des modules PrestaShop.
Si vous souhaitez une intervention, vous pouvez passer par l’agence Webasun pour un accompagnement complet dans vos démarches et paramètrages, si vous souhaitez seulement une intervention purement technique vous pouvez passer par moi si vous le désirez.
Bonjour, je cherche à savoir si un mode d’emploi existe pour mettre le certificat et tout le reste dans le module 🙂 Merci d’avance
Version PrestaShop : 1.5.4.1
Module Tggatos Version : 3.1.0
Version PHP : 5.4
Systeme d’exploitation : Linux x86
Apache 2.0
1&1
Pour le certificat, la manière de faire est expliquée sur la page de configuration du module :
Pour les autres fichiers, il suffit de remplacer les fichiers existant si la banque en question est déjà prise en charge par le module, sinon il faut éditer les listing statiques déclarés au début du fichier de classe du module, après les déclarations de constantes.
Bonjour,
J’aimerai savoir si American Express est repris dans le module ou plus simple si vous auriez la liste des banques autorisées?
Merci d’avance pour votre réponse.
Bonjour, le module est compatible avec American Express (et normalement n’importe quel autre mode de paiement ATOS/SIPS) pour peu que vous configuriez la liste des moyens de paiement en ajoutant AMEX à l’un des blocs (cf. doc SIPS). Il est évidemment nécessaire que votre contrat SIPS vous permette d’utiliser ce mode de paiement.
Par contre ne comprenant pas vraiment vos questions je ne peux y répondre plus précisément.
Version PrestaShop : 1.6.0.8
Module Tggatos Version : 3.4.0
Version PHP : 5.5.13-1
Systeme d’exploitation : Linux Debian 7.5 64bits
Apache Apache/2.2.22
Dédié OVH
Bonjour à tous,
Je viens d’installer un nouveau serveur avec Prestahop 1.6.0.8 (pas un update).
J’ai donc installé TggAtos »bien comme il faut » et l’installation s’est bien passée.
Le problème est, que ce mode de paiement n’apparaît pas dans la liste au moment de payer.
J’ai contrôlé les droits d’accès etc… Tout va bien en back Office mais il ne veut rien savoir coté client.
Si vous avez une idée, je suis preneur.
Bonne journée à tous et bien sûr, MERCI à Damien.
Bonjour, quelques idées :
Le déboggage mode pas à pas, sa configuration sur le serveur et sur une EDI (NetBeans, Eclipse…) est quelque peu fastidieux mais apporte toujours la solution à un problème reproductible.
Bonjour,
Toutes mes excuses, je me suis trompés lors de l’envoie de mon commentaire. Je me permet de vous le poster ici.
Bien entendu, vous pouvez supprimer celui-poster sur l’autre article.
Tout d’abord, un grand merci pour tout ce travail autour de ce module.
Celui-ci fonctionne parfaitement, les paiements en 1, 2 et 3x se passent très bien et la configuration de ce module est très simple à mettre en place.
Cependant, ma question peut semblé bête mais nous avons normalement le 3D Secure actif que nous souhaitons paramétrés un seul de déclenchement pour cela.
Nous avons contactés notre banque ainsi que la plateforme WebAffaire qui nous confirme que le 3D Secure est en place et que c’est à nous de le mettre en place dans une requête, voici leur réponse:
« Le 3D Liberté s’active à partir du champ DATA de la requête de paiement qui
doit contenir le mot clé 3D_BYPASS. »
Concernant notre environnement lié:
– Nous passons par la banque Crédit du Nord / Webaffaire
– Prestashop v.1.5.6.2
– TggAtos v.3.4.0 obtenu via le lien de cet article chez GitHub
Pourriez vous m’indiquez ce qui serait nécessaire de faire pour activer le 3D Secure avec votre module?
Bien à vous,
Cordialement,
Rémi
Très simple à mettre en place ? J’avais pourtant un peu l’impression que le back office était quelque peu devenu une usine à gaz. Mais très content que cela vous plaise.
Depuis la version 3.3.0 vous avez la possibilité d’ajouter des paramètres dans le champ DATA depuis le back office, onglet avancé. Inscrivez votre mot clef et validez.
Le module « untouched » ne permet par contre pas de poser une condition arbitraire (comme un montant de panier de seuil) pour déclencher une telle option.
Pour une telle chose, à votre place je modifierais le contrôleur « controllers/front/payment.php » pour y inclure, lorsque les conditions sont réunies, lors de l’appel à $this->module->getPaymentRedirectionForm(), vos paramètres DATA supplémentaire en tant que valeur pour la clef ‘data’ du paramètre $mergeParams de type tableau.
Pour le 3D_BYPASS, je te conseille un truc du genre :
Juste après le
if ($this->get(self::CNF_FORCE_RETURN))
array_push($data, 'NO_RESPONSE_PAGE');
Mettre :
$haveOrders = Db::getInstance()->getValue('
SELECT COUNT(`id_order`) FROM `'._DB_PREFIX_.'orders` o WHERE o.`id_customer` = '.$this->context->customer->id.' AND o.valid = 1
');
if ($params['amount'] < 12000 || $haveOrders)
array_push($data, '3D_BYPASS');
12000 correspond a un montant de 120€00 a modifier comme tu le souhaites. Dans ce cas précise je désactive aussi le 3D Secure si le client a deja passé une commande.
J’espère que cela pourra être utile.
Attention ici à bien caster en int
$this->context->customer->id
avant de l’utiliser dans la requête car sans cela on expose ici une faille par injection SQL.Ensuite, plutôt que de hardcoder la valeur 12000 il vaudrait mieux ajouter une option configurable par exemple dans l’onglet des options basiques https://github.com/TrogloGeek/prestashop-tggatos-module/blob/RC_3.4.0/tggatos.php#L1049 (après avoir déclaré la constante de classe avec le nom système de l’option, disons TggAtos::CNF_NO3D_IFHASORDER_MAXAMOUNT) pour ensuite utiliser la valeur de cette option:
if ($params['amount'] < $this->get(self::CNF_NO3D_IFHASORDER_MAXAMOUNT)|| $haveOrders)
.Bonjour,
J’ai eu l’occasion de tester votre module dans sa version 3.4.0 sur un Prestashop 1.6.0.9 multiboutique. Tout fonctionne à merveille, un vrai bonheur.
J’avais néanmoins une suggestion : vous proposez notamment pour le paiement en une fois d’ajouter des frais, lié très certainement au fait que la banque prélèvera un pourcentage de la somme payée.
Or, dans le milieu de la vente B2C, il n’est pas rare au contraire de proposer un escompte, car le paiement par CB est passé avant la livraison effective des produits.
J’ai bien entendu essayé de rentrer un pourcentage négatif, mais évidemment vous avez dû prévoir le coup et remettez à 0 le champ. Est-il envisageable d’offrir au contraire la possibilité d’appliquer des frais négatifs ?
Merci par avance
—
Serveur Linux #134 SMP Wed Aug 27 12:51:49 CEST 2014 x86_64
Version du logiciel serveur Apache
Version de PHP 5.4.34
Hello et merci.
La restriction à des valeurs positive est en effet un choix arbitraire de ma part (je ne voyais pas de cas dans lequel on pourrait vouloir mettre ici une valeur négative, donc par sécurité…).
Modifié, mais non testé :
https://github.com/TrogloGeek/prestashop-tggatos-module/tree/unstable-feat-signed-fees
Il faudra aussi modifier les templates pour que les frais négatifs s’affichent plutôt en tant qu’escompte positif.
Cordialement,
Damien VERON.
Version PrestaShop : 1.6.0.9
Module Tggatos Version : 3.4.0
Version PHP : 5.5
Mutualisé OVH
Bonjour,
Tout d’abord merci pour tout le travail fourni pour ce module gratuit !
J’ai passer ma boutique prestashop 1.5.2 en 1.6.0.9, et de la même manière mis à jour le module tgg_atos v2.1.7alpha2 en RC_3.4.0.
Je configure le module pour faire disparaître les erreurs (les chemins des log, param ect) mais il me reste seulement encore 2 erreurs :
Error when calling request binary, system exit code: 126, text output:
Error when calling response binary, system exit code: 126, text output:
J’ai mis le transfert des fichiers par FileZila en mode binaire pour tenter de corriger cette erreur. Cela n’a pas fonctionné.
Par ailleurs, est ce à cause de cette erreur que le module ne s’affiche pas sur mon front office lors du choix du type de payement ?
Merci d’avance.
Bonsoir,
il faut vérifier que les binaires sont compatibles avec votre kernel (version kernel et architecture).
Le moyen le plus simple pour cela reste de mon point de vue de se connecter en SSH sous le même utilisateur que celui sur lequel le traitement PHP se fait, puis d’appeler manuellement les binaires.
Le module effectue quelques tests de santé avant affichage en tant que moyen de paiement durant le parcours de commande, mais il me semble que celui-ci n’en fait pas parti, il doit y avoir un autre soucis quelque part (accrochage au hook ? contraintes de panier configurées non respectées, pays…)
Bonjour,
Merci pour votre réponse rapide.
En effet, il s’agissait bien de la compatibilité des binaires…
Cela fonctionne maintenant.
Pour l’affichage sur le front office cela venais de cette erreur.
Le hook était bien configuré ainsi que les contraintes panier.
Merci et bonne journée
Version PrestaShop : 1.6.0.11 /Thème : Default-Bootstrap
Module Tggatos Version : 3.4.0
Version PHP : 5.5
Mutualisé OVH
Bonjour,
Je reviens vers vous pour savoir où est déclaré votre variable smarty qui génère le formulaire de choix de paiement.
En effet, le formulaire {$tggatos_form} est appelé dans le fichier suivant /views/templates/front/payment_redirect_to_bank.tpl mais je ne trouve pas le fichier source qui déclare tout ses paramètres.
Dans un souci de validation W3C je souhaiterai reprendre le formulaire.
Je pourrai poster mes modifications ou les apporter à une branche github.
Je vous remercie d’avance
Cordialement Mat
Le contenu de cette variable est généré par appel au binaire request de l’API SIPS.
Le meilleurs moyen de cleaner ce superbe code HTML des années 90 serait probablement de regarder du côté de la lib HTML Purifier qui est inclus dans PrestaShop.
Je vois x)
Je vous remercie !
Bonjour,
Je suis sur
Prestashop 1.6.0.11
Linux 3.18.3-xenU-grsec #1 SMP Tue Jan 20 01:09:37 CET 2015 x86_64
PHP Version 5.4.36-0+deb7u3
MySQL 5.5.41
Apache API Version 20051115
En fait je viens de bien installer le module (après une migration depuis une 1.4, dont j’avais conservé le certificat). Tout a l’air ok dans la config du module.
Sur le front, j’ai une erreur, avec ce message :
e paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient.
Je n’ai pas de log dans le dossier adéquat.
Je n’ai pas désinstallé ou supprimé l’ancien module. Peut-être faudrait-il.
Merci beaucoup pour ce module et merci pour votre aide.
Alain
Ok, bon je suis désolé, il suffisait de renseigner correctement la langue … je m’étais trompé !
Et la log a juste mis un peu de temps à apparaitre sur le FTP et dans l’admin !!
Tout marche nickel, c’est parfait !
Bonjour,
Content de voir que ce module est toujours maintenu. Je l’avais découvert il y a 3-4 ans de ça.
Y a t-il prévu de prendre en charge SIPS 2.0 ?
Yannick
Bonsoir,
supporter SIPS 2.0 pourquoi pas (ou plutôt une v4 pour SIPS 2.0), mais je n’ai pas les documentations de cette API.
Sont-elle librement accessibles ?
Je dois les avoir dans mes mails.
Tu peux m’envoyer ton adresse ?
Le mode de paiement CB disparait régulièrement de la page des paiements !
Je n’arrive pas à trouver le problème, aucun message d’erreur dans les logs.
=> si je vide le cache depuis la page admin Performances le mode de paiement CB revient.
Je n’ai ce problème que depuis que j’ai passé la boutique en 1.6.0.14
Si vous avez une idée, je suis preneur !
Je reviens avec mon problème récurrent.
En fait, le moyen de paiment Atos disparait, dès que je clique sur l’onglet module en admin.
Je n’ai aucune erreur PHP, aucune erreur avec le mode DEBUG actif.
Je sèche totalement !
PS : 1.6.0.14
Module : 3.4.0
Je dois vider le cache pour que le paiement CB revienne sur la page commande pour les clients.
Si vous avez une piste, je suis preneur !
————————————–
Version PrestaShop : 1.5.4.1
Module Tggatos Version : 3.4.0
Version PHP : 5.3.3-7+squeeze15
systeme d’exploitation : Linux x86_64
Apache 2.0 Handler
————————————–
Bonjour,
nous avons un problème avec ce module, car lorsqu’une commande est passée et payé une fois sur 2 elle n’est pas prise en compte ni dans les logs du module ni dans les commandes, cependant il n’y a aucune erreur dans les fichiers de logs mais la commande et bien débité
Cordialement
Après plusieurs tests, le problème viendrait du fait que lorsque l’on ferme la fenêtre une fois le payment validée aucune réponses n’est envoyer par au site prestashop. Donc la commande n’est pas créée.
Cela peut venir du mode maintenance de la boutique qui bloque les réponses bancaires, ou que vous utilisez un domaine non publiquement routable pour le retour bancaire (exemple: vmdev.local, localhost…)
Bonjour,
J’utilise votre module qui fonctionne très bien depuis plusieurs années mais une question me vient par rapport à la plateforme Prestashop Addons.
Je ne retrouve en effet pas votre module dessus. Y-a-t-il une raison à cela ?
Oui, il ne respecte pas certains prérequis Addons (sur la version PHP par exemple et il faudrait que je le réécrive lourdement pour qu’il passe au validateur), de plus être sur Addons pour un tel module (qui requière un peu de connaissances à installer et un cerveau valide) = être submergé sous les demandes de support. Il est de plus en concurrence directe avec le module officiel Addons.
Bonjour,
je suis sur :
Prestashop 1.6.0.9
Linux #1 SMP Wed Jul 15 10:13:09 UTC 2015 x86_64
PHP Version 5.3.3
MySQL 5.1.73-log
Apache/2.2.15 (CentOS)
Je viens d’installer votre module (v 3.4) avec succès sur la partie Back-office cependant il n’apparait pas dans la liste des moyens de paiement sur la partie Front.
Auriez-vous une piste?
Merci d’avance.
Kevin
Oui : il faut activer au moins une méthode de paiement 😉
Bonjour,
Merci pour ce travail!
Prestashop : 1.6.0.8
version php : 5.2.17
Apache Linux #1 SMP Thu Apr 16 08:53:31 UTC 2015 x86_64
Tggatos version 3
Tout fonctionne ce n’est pas forcément un problème.
Je voudrais juste savoir comme faire un retour automatique sur la boutique lorsque l’on est sur la banque et que le payement c’est bien déroulé?
Merci encore.
Onglet avancé, case à cocher « Force user return from bank: Disables transaction summary on bank server, see NO_RESPONSE_PAGE data param in ATOS doc. »
Version PrestaShop : 1.6.1.0
Module Tggatos Version : 3.4.0
Version PHP : 5.4.41
Debian 7 sur VPS OVH
Apache 2 / modules suphp et suexec
Bonjour,
Je migre une boutique sous ps 1.5.6.0 avec le module tgg_atos en version 2.1.8
Après l’installation du module en 3.4.0 sur ma nouvelle version de ps (1.6.1.0) j’ai une 2 erreurs :
Error when calling request binary, system exit code: 139, text output:
Error when calling response binary, system exit code: 139, text output:
Et dans la boutique, après avoir choisi le paiement par carte j’ai le message suivant :
Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient.
Pour la configuration j’ai récupéré les dossiers et fichiers de la version actuelle, qui fonctionne correctement (bin/ param/ etc.)
Pouvez- vous m’aider à résoudre ces erreurs ?
Merci d’avance
Bonjour,
un code retour shell 139 signifie normalement une faute de segmentation (tentative de manipuler de la mémoire n’appartenant pas au programme). Vous avez probablement corrompu les binaires en les manipulant (je pense particulièrement à des transferts FTP en mode ASCII). Vous pouvez vérifier cela en lançant manuellement les binaires via une console SSH sur votre serveur.
Si tel est bien le problème, remplacez simplement vos binaires corrompus par des binaires sains fournis par la banque.
Bonjour,
Je viens de reprendre l’administration d’un prestashop (1.6.1.2) et de nombreux problèmes sont à constater lors des paiements :
– De nombreuses erreurs de paiement
– Les commandes sont enregistrées en double dans la base de donnée (avec un numéro de commande différent) que le paiement soit validé ou non
J’ai remarqué que le module est en version 3.0.0 et qu’une MAJ est disponnible, cependant je vous avoue que cela me fait un peu peur de la faire dans un environnement de prod, il ya il une marche à suivre spécifique ?
De plus le module affiche l’erreur suivante :
Check version error: Check version call failed: no response
Auriez vous une solution ou des conseils à m’apporter ?
Cdt,
Pledger
Bonjour,
Veuillez utiliser https://github.com/TrogloGeek/prestashop-tggatos-module/issues pour tout dialogue sur un éventuel bug ou anomalie. Les commentaires sur le blog ne recevront pas forcément de réponse de ma part, et le troubleshooting est totalement ingérable via des commentaires.
Les doublons sont dus à une modification du système SIPS côté bancaire qui ne garantie plus la non concurrence des deux réponses. La version 4.4.1 est nécessaire pour corriger ce défaut comportemental des nouveaux serveurs bancaires.
Pour mettre à jour l’idéal est d’utiliser git, sans quoi il faut faire le tri à la main des fichiers qui ne sont plus nécessaires. Une fois les fichiers mis à jour il faut consulter la page de configuration du module pour qu’il applique les mises à jours côté base de données. Sur un site en exploitation, tout ceci ainsi que des transactions de vérification de bon fonctionnement doivent se faire en mode maintenance, attention à configurer les IPs des serveurs bancaires utilisés lors de la réponse silencieuse dans les IPs de maintenance pour que les tests se déroulent convenablement. Pour obtenir ces IPs, consultez votre contact technique bancaire, ou à défaut récupérez celles dans vos logs d’accès. Il vaut évidemment bien mieux tester la mise à jour sur une instance de préproduction du site (oui, la maintenance d’un eCommerce représente du travail).
Concernant le webservice de vérification de version du module il est hors ligne, je n’ai pas eu le temps de le remettre en ligne après restitution du serveur qui l’hébergeait.
Je vous remercie pour cette réponse claire et précise.
En ce qui concerne la Mise à jour , via git cela me semble impossible (hébergement mutualisé OVH) je suppose que je vais devoir faire tout sa à la mano.
Faire une copie de l’environnement de production en local, puis re transférer le module en ftp (en mode binaire) cela peut il être fait ?
Cdt,
Pledger
Dans le cas d’un transfert depuis une autre instance il faudra de toutes manière repasser par la configuration pour mettre à jour le pathfile SIPS (mis à jour à chaque soumission des options).
Le plus simple est d’archiver l’ancien module et de déployer la nouvelle version à la place puis de passer par l’interface de configuration.
Il est possible d’utiliser GIT sur les espaces d’hébergement mutualisés sans SSH en utilisant une interface console PHP via HTTP. (je n’ai pas d’exemple de solution existante à fournir, je fais les miennes sur mesure).
Merci de toutes ses informations,
Je vais voir pour effectuer le meilleur scénario de mise à jour