Bonjour à tous,
premièrement désolé pour le manque de nouvelles dernièrement : j’étais pas mal occupé à réécrire une bonne partie du code source du module pour améliorer les fonctionnalités de débogage pour permettre de faire cela proprement sur une boutique en production.
La mauvaise nouvelle : Il n’y aura pas de 2.0 stable car le système de débogage n’était pas assez propre à mon goût. Cela dit la 2.0 RC4 fonctionne très bien dans 99% des cas, et peut elle-même être considérée comme stable.
La bonne nouvelle : la branche 2.1 du module avec des modifications relativement lourdes et intéressantes.
Au programme :
- Un module Prestashop ATOS SIPS toujours accessible gratuitement.
- La possibilité de forcer le retour client (supprimer la page de confirmation de commande ATOS) si la configuration de votre hébergement ne bloque par les paramètres GET très longs. L’intérêt ? Améliorer la prise en compte des commandes avec des solutions javascript telles que Google Analytics et d’autres outils d’analyse du ROI.
- La possibilité d’ajouter des frais de paiement, fixes ou proportionnels au montant du panier, selon le nombre de versements choisi (paiement en 1, 2 ou 3 fois). Attention, ces frais bancaires ne figureront pas dans la confirmation de commande, dans la commande et le panier que ce soit sur la boutique ou l’administration. Je n’ai aucune idée de la légalité de la chose, mais c’est une fonctionnalité réclamée de nombreuses fois, et donc finalement implémentée. Renseignez-vous sur les implications légales avant d’utiliser cette fonctionnalité si vous ne les connaissez pas. Pour que ces frais soient bien pris en compte partout il faudrait que ce soit Prestashop qui implémente cette fonctionnalité, le faire depuis un module serait du pur bricolage.
- Un système d’ajout de paramètres dans l’appel à l’exécutable request pour permettre des configurations plus complexes par des personnes au niveau technique suffisant. Cf. fichier /tgg_atos/param/params.xml. Permet entre autres l’utilisation de templates pour les pages de paiement, ou le changement des modes de paiement disponibles selon le nombre de versements.
Je n’ai eu le temps de faire que des tests sommaires sur cette version, en fait de très nombreux tests ont été faits sur les 2.1 RC 1 à 5, que je n’ai pas eu le temps de diffuser car j’avais toujours quelques (plus ou moins) petites améliorations à apporter pour satisfaire le plus de commerçants possible, mais le résultat final RC 6 doit encore être testé de fond en comble. Comme sur la preview précédente (2.0 RC 4), je n’ai pas eu le temps de faire le package intégralement sous linux, les droits par défaut ne sont donc pas fixés sur les fichiers.
De plus, la solution a principalement été testée sous Prestashop 1.4.1, ma boutique de test principale, si vous testez sous d’autres versions il serait sympathique de poster vos retours sur le bon fonctionnement ou non du module en précisant la version Prestashop ainsi que celle de Smarty (V2 ou V3) utilisée.
Télécharger le module gratuit ATOS/SIPS pour Prestashop
Si vous appréciez le travail fourni, pensez aux dons. Il sont nécessaires à la survie du projet puisque celui-ci est coûteux pour moi.
Bonjour, après avoir testé plusieurs modules bancaire pour prestashop, je dois vous féliciter pour celui ci ! Très simple d’installation, très bien documenté, que du bonheur.
Un grand merci @ vous
Bonjour,
J’ai le message suivant :
« Aucune adresse mail n’a été configurée pour recevoir les alertes de dysfonctionnement du module. Tant qu’aucune adresse n’aura été définie, l’adresse mail de contact de la boutique sera utilisée pour envoyer les rapports d’erreur en cas d’incident. »
La boutique est sous PS 1.4.4.1 et le message n’apparaissait pas avec l’ancienne version de votre module.
Je ne trouve aucun champs pour renseigner l’adresse mail, … celle de la boutique est bien renseignée.
Merci pour pour votre travail.
Salutations.
Bonjour, cette alerte n’existait effectivement pas sous la branche 2.0 puisque l’on ne pouvait pas configurer l’adresse de destination des messages d’erreur, c’était automatiquement l’adresse de la boutique.
Le champs a renseigner se trouve sur l’onglet avancé. Si vous ne voyez pas ce champs, il y a de très fortes chances que cela soit dû à un oubli de purger les caches Smarty (qui doit être purgé chaque fois qu’un module utilisant des template est mis à jour).
Cordialement, TgG.
Bonjour,
Merci Damien pour votre réponse rapide.
Je vous tient informé.
Cordialement.
Martin.
bonjour
effectivement votre travail est un regal!!!
facile a mettre en place et tout a fait fonctionnel…
je ne manquerais pas de faire une donation prochainement!!!
Salut Troglo
Merci pour ton excellent travail, le module est tellement simple à installer.
Ça mérite amplement un pti don sur Paypal.
J’invite les autres utilisateurs à faire de même, donner quelques euros ce n’est rien en comparaison du travail accompli pour mettre à disposition GRATUITEMENT ce module.
Bonne Continuation et encore merci
voila…
don fait
et encore un grand merci
Bonjour,
Je viens de tester ce module sur une version 1.4.5 de Prestashop, il n’y a rien à dire, tous fonctionne correctement.
J’utilise déjà ce module dans une de ces version précédente sur une version 1.3.5 de Prestashop, et j’en suis très contente.
Merci à toi pour ce formidable module !
Bonjour,
tout d’abord merci pour ce module qui fonctionne sur la version 1.4.6.2
J’ai juste un petit soucis de template qui m’empêche d’utiliser ce module actuellement , je dois enlever la colonne de gauche lors du paiement avec le thème « prestashop_new » et je ne trouve pas.
Merci d’avance.
J ‘essaye d’installer ce module sur un Windows server 2003, mais sans succès…
J’ai le message : Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient.
Pourtant les fichiers sont bien en lecture / ecriture. (pas de chmod sous windows :-S)
est ce que quelqu’un a réussi à la faire tourner sur cette OS ?
Testé sous Windows 7 de mon côté.
Prière de lire la documentation du module et de fournir les informations de débuggage pour les demandes de support.
Bonjour,
Avez vous une adresse mail ou nous pouvons vous contacter si on a un problème avec le module.
Je suis débutante sur prestashop et j’ai un message d’erreur 139 sur le module. Je me suis référencé à la doc fournis avec le module et j’aurai besoin de plus de précision. (car le module a été retransmis sur le ftp en binaire mais rien de plus)
Je suis sur une version prestashop 1.4.4.1 et pour le module, c’est atos v2.1.6.
Avez vous la possibilité de m’aider ?
Bonjour, il n’existe pas d’erreur désignée par un numéro sur ce module, je suppose donc que vous parlez d’un code de retour shell à l’appel de l’exécutable request. La signification de ce code d’erreur devrait être dans la documentation de votre système d’exploitation. Généralement de telles erreurs à l’appel d’un exécutable sous linux on trois principales causes :
– manque de droits de lecture et/ou exécution sur l’exécutable et/ou le dossier qui le contient
– incompatibilité entre la version de votre noyau et celle du compilateur (mais il ne peut pas s’agir de cela puisque, comme l’indique la documentation, vous avez substitué les binaires du module par ceux correspondant a votre version de linux fourni par votre banque, n’est-ce pas ? ;-))
– incompatibilité du nombre de bits (16, 32 ou 64) du systeme et de l’exécutable. A savoir qu’il y a une librairie a installer pour faire tourner des binaires 32bits sur un système 64bits.
Bonjour et bravo pour ce module qui s’installe sans encombre.
Juste une petite remarque : je ne trouve pas CITELIS / CREDIT MUTUEL DE BRETAGNE
Est-il possible d’utiliser une autre banque pour un fonctionnement similaire ?
Encore merci,
Kahuitel
Si je me souviens bien les instructions sont dans la documentation jointe, l’avez-vous ouverte ?
Bonjour,
Tout d’abord, merci beaucoup pour ce super module ! il est top !
J’utilisais la version PrestaShop™ 1.4.4.1 et mes tests d’achats se passaient bien avec le certificat de Pré-Production. Pour des raisons liées à des bugs sur Prestashop, j’ai migré mon site sur une base PrestaShop™ 1.4.6.2. Parallèlement, je suis passé à une version Production du certificat de la banque.
Le problème, est que maintenant, j’ai un message d’erreur juste après avoir choisi le moyen de paiement (la Carte Bancaire) :
sh: /homez.441/mon_site/www/modules/tgg_atos/bin/request: Permission denied
Est-ce que le module SIPS/ATOS v2.0-beta4-rc-4 est toujours compatible avec la version 1.4.5.2 de Prestashop ?
Merci d’avance.
Ce n’est manifestement pas un problème de compatibilité mais de droit (lecture + exec sur le dossier ainsi que sur les executables)
Merci beaucoup !
J’ai modifié les droits sur le dossier et exécutables comme vous me l’avez conseillé et ça fonctionne maintenant !
Merci beaucoup!
Bonjour,
Merci pour ce module.
Je souhaite utiliser ce module tgg_atos-2.1.6 pour deux sites
Je suis en version 1.4.7.0 pour l’un et 1.4.4.0 pour l’autre.
Je rencontre le problème :
« Tgg_Atos: Erreur durant l’appel de l’exécutable request
L’exécutable request a retourné une erreur. »
…modules/tgg_atos/bin/request: Permission denied.
Je suis désolé, je n’ai pas compris la réponse donnée aux autres posts, pouvez-vous m’aider SVP.
Merci
Bonjour, il faut lire la documentation incluse
Bonjour et bravo pour ce module!
J’ai un problème avec le mode Démonstration et la Banque Sherlocks – LCL :
le POST https s’effectue vers https://sherlocks.creditlyonnais.fr/cgis-payment-sherlocks/demo/callpayment mais le nom de domaine ne semble plus valide !
Je n’ai aucune idée ou dans le code on peut modifier cette URL et quelle est la bonne URL pour LCL
Merci de me mettre sur la voie 🙂
Bonjour,
J’ai effectivement constaté cela aujourd’hui sur un magento modifié. Je pense que les URL sont encryptées dans les certificats, il faudrait donc obtenir le nouveau certificat de démonstration de la lcl.
Merci de votre réponse, j’avais déjà essayé avec le certificat du LCL reçu avec la doc et l’API sans succès.
Après un coup de fil à LCL, il se trouvent qu’ils livrent toujours le vieux certificat de démonstration avec l’API :-/
Ils viennent de m’adresser le nouveau.
Merci encore
Bjr,
Quel est le but de ceci svp?
« Adapter l’apparence du module à celle de votre boutique (optionnel). »
Je ne vois pas les effets de de ces réglages?
Merci par avance pour vos éclaircissements.
Bonne soirée
Bonjour,
cf documentation Prestashop, ceci sert à copier vos templates de module dans votre dossier de thème pour pouvoir les modifier proprement.
Bonjour,
Félicitation pour ce module !
Sur la dernière version du module, la 2.1.6 que j’utilise déjà depuis 1 mois sur une boutique Prestashop 1.4.5, les commandes sont bien validées et payées avec ATOS, par contre quelques jours plus tard, certaines commandes passent en l’état annulé alors que le paiement a bien été effectué et que nous avons bien l’argent sur le compte. Une idée d’où le problème peut-il venir ?
Merci par avance.
Bonjour,
Je voudrais vous remerciez pour votre module, dès que j’ai finalisé l’installation je manquerais pas de vous faire une donation pour votre super travail.
Une question, si je met des dossiers bin log param au même niveau que www sur OVH est ce sécurisé ?? car vous dites de ne pas le mettre à la racine dans la doc.
Cordialement
Alex
Bonjour,
« Idéalement, vous devriez déplacer les dossier /bin/, /param/, /log/ hors de la racine web de
votre serveur »
Ceci signifie que vous devez par sécurité placer ces fichiers dans un dossier qui n’est pas accessible par votre serveur http ou tout autre service publique (ftp non sécurisé etc…).
Ne pas confondre la racine web (/var/www par exemple) et la racine du serveur (/), les fichiers en question peuvent généralement être mis dans un dossier à la racine du serveur sans problème.
Au fait, merci pour la donation et désolé pour le temps de réaction, mon activité principale requiert énormément de mon temps depuis un an, cela devrait j’espère s’améliorer.
Re bonjour,
J’ai un problème, en mode test tout fonctionne, je suis passé en pré production j’ai envoyé le certif via le module tout est ok. mais par contre au moment de passer commande j’ai la page jaune avec 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.
J’ai regardé la table tgg_atos_transactions_today elle s’incrémente correctement.
J’ai lu tout les post sur votre site et je ne trouve pas. Si quelqu’un avait une solution. Merci par avance.
Alex
Bonjour,
je rencontre le même souci sur un prestashop 1.3.2.1
certains paiements sont en erreur de paiement alors que la transaction cote client se déroule correctement (j’ai reproduit le cas)
dans les logs, je vois 2 traces pour une même transaction, une venant du client l’autre du serveur, parfois les reponses sur le champ complementary code sont 99, parfois 0
ce champ correspond à « le serveur SOGENACTIF a un rencontré un problème lors
du traitement d’un des contrôles locaux complémentaires », cf doc Atos
———————————–
merchant_id: 0522393xx
merchant_country: fr
amount: 009
transaction_id: 23
payment_means: MASTERCARD
transmission_date: 20120122203317
payment_time: 213342
payment_date: 20120122
response_code: 00
payment_certificate: 711bb7c02b3b
authorisation_id: 133242
currency_code: 978
card_number: 4973.43
cvv_flag: 1
cvv_response_code: ??
bank_response_code: 00
complementary_code: 99
complementary_info:
return_context:
caddie:
receipt_complement:
merchant_language: fr
language: fr
customer_id: 4880
order_id: 39091
customer_email: xx@xxx
customer_ip_address: 78.240.40.163
capture_day: 0
capture_mode: AUTHOR_CAPTURE
data:
: 0
origin: silent_response
caller_ip_address: 193.56.46.18
———————————–
merchant_id: 0522393xx
merchant_country: fr
amount: 009
transaction_id: 23
payment_means: MASTERCARD
transmission_date: 20120122203317
payment_time: 213342
payment_date: 20120122
response_code: 00
payment_certificate: 711bb7c02b3b
authorisation_id: 133242
currency_code: 978
card_number: 4973.43
cvv_flag: 1
cvv_response_code: ??
bank_response_code: 00
complementary_code: 99
complementary_info:
return_context:
caddie:
receipt_complement:
merchant_language: fr
language: fr
customer_id: 4880
order_id: 39091
customer_email: xx@xx
customer_ip_address: 78.240.40.163
capture_day: 0
capture_mode: AUTHOR_CAPTURE
data:
: 0
origin: client_return
caller_ip_address: 78.240.40.163
Bonjour, je ne peux répondre à la place d’ATOS sur les problèmes rencontrés sur leurs serveurs, il faut prendre directement contact avec eux.
Hola TGG !
Et encore merci pour ce module, du velour !
Ce qui m’intéresserait, c’est de pouvoir interdire le 2x et/ou 3x à certains pays. pour l’instant, ce que je vois, c’est installer le même module xfois. Ma question et donc simple : puis-je aisement ? J’utilise pour l’instant la 2.0 beta4 rc4.
Merci !
PS : Pour les dons, possible d’avoir une « facture », ou un reçu ? Comment ça se passe ? y’a une doc quelque part ? Ou bien c’est dans la doc et j’ai rien vu ? 🙂 Olé¡
Bonjour,
cette fonctionnalité n’est effectivement pas prise en charge par le module.
La manière la plus efficace de faire ceci est effectivement de dupliquer le module ce qui est une manœuvre un peu complexe (pas mal de remplacements à faire pour que les deux modules aient deux noms différents, cela dit le module a été pensé pour limiter les actions nécessaires dans ce cas de figure, il faut aussi qu’ils tournent sur la même table de génération des ID de transaction ou bien segmenter la plage d’ID) et d’en utiliser un pour le paiement en une fois, l’autre pour le paiement en plusieurs fois.
Concernant les dons, je voulais monter une société dédiée à mes interventions payantes et pour émettre des factures pour les donations malheureusement je manque de temps pour cela ces temps-ci (depuis un an en fait), de plus je risque fort d’être déficitaire d’un point de vue frais de gestion. Donc pour l’instant la chose est en standby, désolé.
Hola Damien,
Merci pour la réponse, que j’ai complétée avec d’autres de tes interventions sur le sujet (un peu plus bas ici, concernant la table des transactions notamment, ce qui m’a confirmé ce que j’ai trouvé en regardant ton code et les tables en base).
Finalement, j’utilise la 2.1 RC6 pour cette duplication.
Ce que j’ai fait :
– Modification de toutes les occurrences ‘tgg_atos’ par ‘tgg_ceQueJeVeux’. Petite remarque : on a une « fatal error Configuration -> length 32 » lors de l’install et/ou désinstall du module. On touche ici la limite du nombre de caractère pour le nom d’une table dans mysql ? (alerte se déclenche chez moi à 31 caractères, soit un de plus que strictement ‘PS_tgg_atos_transactions_today’ et
pourtant’PS_tgg_atos_TEST_transactions_today’ se crée sans problème) ;
– Modification de toutes les occurences « Tgg_Atos » par ‘Tgg_CeQueJeVeux’ ;
– Modification de tous les noms de fichiers dans admin-tpl/ et tpl/ en ‘tgg_atos_nom-fichier’ par ‘tgg_ceQueJeVeux-nom-fichier’ ;
– Renommage du répertoire du racinbe du module de ‘tgg_atos’ en ‘tgg_ceQueJeVeux’ ;
– Renommage du fichier ‘tgg_atos.php’ en ‘tgg_ceQueJeVeux.php’ ;
– Pour faire propre et distinguer le nouveau module dans la liste, mise à jour dans le fichier fr.php, ligne 4, première occurence : le ‘SIPS/ATOS’ par ‘Il était une fois dans l’Ouest’ ;[-)]
– [Si j’ai rien oublié] Dernier point, et là où j’ai une question, c’est pour lui faire utiliser la même base d’ID des transactions journalières. Est-il correct de modifier, dans le fichier tgg_ceQueJeVeux.php, toutes les occurences (hors guillemets) « ._DB_PREFIX_.$this->name. » par « ._DB_PREFIX_.tgg_atos. » ?
Aussi, une chose bizarre que je viens de constater, c’est dans ma table ps_configuration du preprod, où le module écrit ses paramètres, tout a été effacé et ne reste que les param du module tgg_atos… je me demande où j’aurais fais une bourde, je ne me rappelle pas avoir vu/touché une valeur de code de type mysql (j’imagine que por faire ça, l’aurait fallut que je rajoute un DROP juste avant un insert je ne sais où… ce que je n’ai pas fait, of course). Une idée ?
Merci !
[a effacer du message online] PS : possible d’échanger par mail pour le don ? tiscarabee@gmail.com
Aussi, modifier, dans tgg_ceQueJeVeux.php, ligne 256 :
CREATE TABLE `’._DB_PREFIX_.tgg_atos.’_transactions_today` (
par
CREATE TABLE IF NOT EXISTS `’._DB_PREFIX_.tgg_atos.’_transactions_today` (
« Aussi, une chose bizarre… »
Désolé, un tri de requête qui trainait via phpmyadmin, mon ps_configuration va pour le mieux…
Faudrait presqu’un petit module forum pour ce site :]
Désolé… ->[]
Bonjour,
je fais ici un condensé des réponses aux trois messages :
Oui pour les modifications de nom, sans oublier de mettre à jour les clés du fichier de langue (j’ajoute cela pour les lecteurs qui pourraient être intéressés car dans votre cas je suppose que vous l’avez fait sinon vous n’auriez plus les traductions françaises).
Concernant
ceci vient du fait que le nouveau nom est trop long. Il faut savoir que contrairement à pas mal de modules, celui-ci préfixe ses variables de configurations par son propre nom pour éviter des collisions avec d’autres modules (les paramètres de configuration des modules et de Prestashop sont stockés dans une unique table, il faut donc faire attention à ce que deux modules n’utilisent pas les même nom de variable, oui je sais tisc0, vous le savez manifestement déjà, j’explique pour les autres ;-)). Lors de la modification du nom de module il faut donc éviter de rallonger le nom (par exemple tgg_atos => mod_atos ou alt_atos …).
Concernant le cas de deux modules exploitant la même table (l’idéal lorsque les instances utilisent le même certificat et sont sur le même serveur, sauf si vous désirez pouvoir faire la différence entre les transactions des deux modules par l’ID de transaction), vous avez raison pour la modification de
Pour ce qui est de l’installation de la table, pas de problème pour le « IF NOT EXISTS » que je n’ai pas utilisé car provoque des problèmes sur de vieilles versions de MySQL, sinon on peut aussi commenter l’appel à la fonction d’installation de la table ou placer un return true au début.
re-bonjour,
je rencontre encore le souci d »Erreur de paiement » sur plusieurs transactions par jour.
j’ai un même client qui a passé 2 commandes aujourd’hui, une OK, l’autre KO
voici le détail (env Prestashop 1.3.2.1)
OK
VISA
xx
amount: 4675
merchant_id: 052239xx
transaction_id: 1
transmission_date: 20120124021226
payment_time: 031325
payment_date: 20120124
response_code: 00
payment_certificate: 1ca4a01a6c03
authorisation_id: 699344
currency_code: 978
cvv_flag: 1
cvv_response_code: ??
bank_response_code: 00
complementary_code: 00
complementary_info: ,CARD_COUNTRY=FRA,IP_COUNTRY=FRA,
return_context:
receipt_complement:
merchant_language: fr
language: fr
customer_email: xxx@live.fr
customer_ip_address: 77.198.251.126
capture_day: 0
capture_mode: AUTHOR_CAPTURE
data: NO_RESPONSE_PAGE
KO
VISA
xx
amount: 2685
merchant_id: 052239xx
transaction_id: 4
transmission_date: 20120124102207
payment_time: 112300
payment_date: 20120124
response_code: 00
payment_certificate: e9c626ff97ed
authorisation_id: 995119
currency_code: 978
cvv_flag: 1
cvv_response_code: ??
bank_response_code: 00
complementary_code: 00
complementary_info: ,CARD_COUNTRY=FRA,IP_COUNTRY=FRA,
return_context:
receipt_complement:
merchant_language: fr
language: fr
customer_email: xxx@live.fr
customer_ip_address: 77.198.251.126
capture_day: 0
capture_mode: AUTHOR_CAPTURE
data: NO_RESPONSE_PAGE
La version utilisée est-elle bien la 2.1 RC6 ?
Le module ne crée pas de commande en statut erreur de paiement sauf s’il a été configuré pour passer les commandes en ce mode après validation du paiement (ce dont je doute). Il s’agit donc d’une routine de vérification de sécurité de Prestashop qui bascule la commande en ce mode, cela peut venir d’une problème de clef de sécurité (probablement un de mes wrappers de compatibilité qui pose problème) ou d’erreur d’arrondi sur le montant de la commande (s’il y a ne serait-ce qu’un centime de différence avec le montant du panier la commande passe en erreur, cela peut venir soit d’un problème de règle de calcul ou bien une mise à jour d’un prix durant le passage en banque), pourriez-vous commencer par comparer le champs AMOUNT des logs avec le montant réel du panier de la commande ?
Bonjour,
les montants sont bien les mêmes, le pire, c’est que certains clients voyant l’erreur, repassent commande et là, pas de pb…
j’ai l’impression que c’est un souci qui arrive parfois mais pas tout le temps….
Bonjour,
Pour l’erreur concernant la page jaune « Erreur de Sécurité » j’ai contacté Elysnet, ils m’ont dit que le numéro de transaction était déjà utilisé, je leur ai dis que la table s’incrémentais correctement, ils m’ont répondu que cela venait peut être de chez eux, que l’infos serait remonté au technicien, résultat le lendemain matin je fais les tests et ça fonctionne maintenant.
Si ça peut aider ceux qui étaient dans mon cas ..
Encore merci pour votre module, je vous fais une donation.
Cordialement
Alex
Oui, comme tout prestataire ATOS n’est pas à l’abri d’erreurs.
Bonjour, bravo et encore merci pour ce module qui nous enlève une épine financière du pied. Jeune société, c’est pas qu’on est radin mais vu les charges qui tombent, on fait gaffe.
J’ai installé sans problème le module 2,1 rc6 sans problèmes, surpris moi même que cela fonctionne pratiquement sans erreurs (via l’aide du super tutorial de T.Godin).
Fort de cette expérience, je me suis lancé dans l’installation sur une autre Boutique (autre url) du même compte VAD/certif.xxxxxx et la big problème, ça a planté la première … aujourd’hui corrigé via les CHMOD.
voici ma question: peut t’on installer sur 2 sites distincts le même VAD ?
merci pour vos réponses 😉
Bonjour,
cela est tout à fait possible mais un même ID de transaction ne peut pas être utilisé deux fois sur une même journée pour un même certificat. Donc soit vos deux modules doivent partager une même table de génération des IDs, (tgg_atos_transaction_today) soit vous devez segmenter les ID en affectant par exemple un ID minimum de 500 000 sur la page de configuration avancée de l’un des deux et laisser le réglage par défaut sur l’autre, auquel cas vous pourrez faire 499 998 affichages de la page de départ en paiement sur chacun des deux sites par jour. Une fois la logique comprise, vous pouvez utiliser un même contrat VAD pour autant de boutique que vous le souhaitez à condition qu’elles ne dépassent chacunes pas le nombre d’ID affectées.
… yessssssss , j’y suis presque, encore une chtite erreur et c’est bon !!!
L’exécutable request a retourné une erreur.
(126): sh: /homez.xxxx/piairsol/www/modules/tgg_atos/bin/request: Permission denied
ca ressemble a un manque de droits sur pathfile ? … j’ai un doute, une chtite soluce comme ça a l’arrachée ?
Cette erreur est générée par le shell de votre système d’exploitation, et, comme il l’indique, signifie que les droits sur les binaires n’ont pas été installés convenablement, cf documentation.
Bonjour,
Bravo pour ce module que nous utilisons maintenant en production sous PS 1.3.2 (oldschool) sur la plate-forme Merc@net.
Nous avons toutefois trois remarques :
– le numéro de référence d’opération qui est transmis à Merc@net est celui du panier et non celui de la commande ou de la facture, ce choix n’est pas pratique pour les rapprochements comptables ou de simple gestion. Offrir le choix en back-office serait préférable.
– lors de modifications de la traduction en-fr du module, le fichier fr de traduction localisé dans le répertoire du thème est réinitialisé, il faut re-copier le fichier comme précisé dans la doc.
– enfin, la doc pour appeler un template ou un css pour personnaliser la page de paiement sur le serveur Merc@net n’est pas super claire du coup, voici un exemple : on utilise la personnalisation par template (fichier « merchant_template » transmis à Merc@net) et on veut supprimer la ligne de copyright sur la page de paiement (NO_COPYRIGHT).
dans « param.xml », on a complété la section car on veut appliquer ça à toutes les situations.
[...]
!! DO NOT FORGET CDATA WRAPPER !!
!! READ CAREFULLY "DATA DICTIONNARY" PART OF ATOS/SIPS DOCUMENTATION !!
!! 'pathfile' cannot be overriden because it is set after parsing this file, it didn't change this way of working because i didn't see the point of it, let me know if I'm wrong !!
-->
NO_COPYRIGHT;
merchant_template
En espérant que cela sera utile.
Encore merci et on n’oublie pas de passer par la case Don.
les balises « code » ont tout mangé du coup :
!! DO NOT FORGET CDATA WRAPPER !!
!! READ CAREFULLY « DATA DICTIONNARY » PART OF ATOS/SIPS DOCUMENTATION !!
!! ‘pathfile’ cannot be overriden because it is set after parsing this file, it didn’t change this way of working because i didn’t see the point of it, let me know if I’m wrong !!
–>
NO_COPYRIGHT;
merchant_template
bonjour, nul besoin d’utiliser le balisage pour décrire vos modifications du fichier xml, vous pouvez utiliser une syntaxe xpath par exemple :
//params/default/language = CDATA(en)
pour reprendre l’exemple des commentaires dans le fichier
Bonjour,
Prestashop est un système qui ne génère de numéro de commande qu’au retour de banque, cela a ses avantages et ses défaut, si vous souhaitez un numéro de commande dès le départ en banque on peut « bricoler » Prestashop mais on perd alors la consolidation des numéros de commande (certains numéros de commandes seront utilisés pour des paiement en échec ou annulés). Je vous conseille de vous tourner vers un e-Commerce plus adapté à vos besoins.
Bjr,
Est il possible d’éviter d’écrire le message avec tous les paramètres de la transaction dans la partie messages de la commande? J’aimerais l’enlever car je veux faire figurer les messages clients sur les bons de livraison et dans ce cas le message tgg_atos ne m’est pas utile.
Merci par avance pour votre aide
Bonne soirée
Bonjour,
Le cas n’est pas prévu mais la modification est très simple.
Il faut éditer le fichier tgg_atos/tgg_atos.php
chercher la fonction
protected function _makeOrderMessage($Response, $mode) {
$retval = $Response->payment_means . "\n"
. str_replace('.', ' #### #### ##', $Response->card_number) . "\n";
foreach ($this->_responseFieldsLoggedInOrder as $k)
$retval .= $k . ': ' . $Response->$k . "\n";
return $retval;
}
et ajouter au début de cette fonction la ligne
return '';(deux guillemets simples)
ce qui nous donne
protected function _makeOrderMessage($Response, $mode) {
return '';
$retval = $Response->payment_means . "\n"
. str_replace('.', ' #### #### ##', $Response->card_number) . "\n";
foreach ($this->_responseFieldsLoggedInOrder as $k)
$retval .= $k . ': ' . $Response->$k . "\n";
return $retval;
}
Bjr,
Est il possible de ne pas afficher ceci dans la page de commande:
CB
#### #### ##
merchant_id:*********
transaction_id: 1
transmission_date: 20120129094057
payment_time: 104307
payment_date: 20120129
response_code: 00
payment_certificate: edrfgt
authorisation_id: 59652
currency_code: 9
cvv_flag: 1
cvv_response_code: ??
bank_response_code: 00
complementary_code:
complementary_info:
return_context:
receipt_complement:
merchant_language: fr
language: fr
customer_email: *******
customer_ip_address: 83.198
capture_day: 0
capture_mode: AUTHOR_CAPTURE
data: ?
Merci par avance pour votre aide.
cf réponse ci-dessus
Bonjour Damien,
Attention, le certif de démo fournit dans le package pour la banque LCL n’est pas le bon (en dépit du fait qu’ils fournissent toujours le mauvais dans leur package sherlocks, ils en renvoie un après).
Le domaine n’est plus creditlyionnais.fr mais lcl.fr
Voulez vous que je vous l’envoie ?
Moon One
Bonjour,
je cherche une réponse au sujet de l’erreur 132 générée par votre module, merci d’avance pour tout renseignement 🙂
Bonjour, quelle est l’origine de cette erreur ? S’il s’agit du return code fourni par le mode debug ou les mails de rapport d’erreur, il s’agit d’un code d’erreur généré par votre système d’exploitation, pas par le module.
Cordialement.
Bonjour,
J’ai installé votre module il y a quelques jours sur un presta 1.4.4.0 et je constate une chose étrange lorsque je passe des commandes en so colissimo Liberté. Elles s’enregistrent de manière alléatoire. Parfois les points de relais sont pris en compte, parfois c’est l’adresse perso du client qui est prise en compte.
Avez-vous déjà constaté ce souci auparavant ?
Merci par avance. 🙂
Bonjour, je n’ai pas de boutique à part à des boutiques factices servant au développement de ce module, je n’ai donc pas de compte So-Colissimo, mais on m’a déjà appelé en renfort sur une boutique où ce module foutait la merde à cause de la lenteur de réponse du webservice.
Mon module ne touche pas aux données de livraison, vous devriez vous tourner vers le support So-Colissimo. D’ailleurs en commandant sur internet j’ai déjà eu ce problème avec la boutique Ankama-Shop qui n’a pas l’air de tourner sur Prestashop, et qui n’utilise en tout cas pas mon module pour le paiement : le colis a malheureusement été livré à l’adresse de destination plutôt qu’au relais. Je qu’il y a un soucis avec le service So-Colissimo ou avec certains modules pour utiliser ce service.
Bonjour,
Ton module est top par contre énorme problème lorsque l’hébergeur bloque la fonction exec(), a dut ou est tu en train de développer une version PERL pour ces hébergeurs quelques peu rétissant en terme de sécurité.
Merci d’avance pour ta réponse et encore bravo pour ton travail….
Bonjour,
non désolé, j’ai tendance à considérer qu’on n’installe pas une boutique sur un hébergement low cost.
Sinon il existe la solution de Pierre-Yves : http://www.pierreyves.be/2010/03/16/module-atos-cgi-perl/
Cordialement, Damien VERON.
bonjour damien et merci pour le module j’ai commencé par l’installer mais j’ai un problème de mise en page du tpl:
tgg_atos-front-payment-redirect.tpl il se trouve dans la div#center_column au lieu d’être dans la div.table_block voir l’image ci-joint tout est décalé.
cliquez ici pour voir l’erreur au format png
Bonjour,
vous pouvez modifier les templates du module après avoir suivi la procédure de duplication des templates et ressources dans votre dossier de thème Prestashop décrite dans la documentation du module ou après avoir utilisé la procédure d’export automatisé des templates du back-office si les droits sur les fichiers du site le permettent.
le problème c’est qu’il n’y a pas de css adéquat, il faut modifier le tpl en lui même, mais pour l’intégration dans la mauvaise div je sèche.
Re-bonjour,
je ne comprends pas votre problème, puisque vous avez besoin d’un wrapper .table_block il vous suffit de l’ajouter dans le template ?
ps: merci d’utiliser la fonction répondre pour répondre à un commentaire, évitant ainsi de créer un nouveau fil inutilement.
Bonjour,
Sympa le module, c’est ce que je cherchai !
Par contre, je n’arrive pas à utilisez vos hooks que vous avez mis à notre disposition. J’ai fait un module, dans la fonction install me suis enregistrez comme un hook classique. Mais aucun passage dans les fonctions tggAtosOrderConfirm( params .. ) ! Il y à t-il une manip à faire?
Sinon, autre petit point, pour le test de carte : ça peut toujours servir :
-Les numéros de cartes bleues de test dont composés de 16 chiffres, donc les 2 derniers doivent finir par 00
– Le numéro de 3 chiffres derrière la carte doit finir par 00
-La date d’expiration doit être postérieure à la date actuelle
Il se trouve que j’ai aussi ces erreur là :
[13-Feb-2012 15:56:46] PHP Notice: Undefined property: stdClass::$data in /var/sites/vhs/trunk/modules/tgg_atos/tgg_atos.php on line 1243
Je m’auto répond, la manip pour pendre en compte tes hooks, réinstall du module and that works 🙂
En réalité les deux derniers chiffres doivent être le code de retour souhaité, pas forcément 00.
Ce que l’on sait de toutes manières si l’on a lu la doc d’intégration fournie par Atos, point de passage obligé avant d’installer quelque module Atos que ce soit.
$retval .= $k . ': ' . $Response->$k . "\n";est-ce cette ligne-ci ? (pour moi ligne 1241, la ligne 1243 étant une fermeture de fonction sur le fichier non modifié il ne peut s’agir de cette ligne)
Auquel cas la notification PHP est anodine mais peut être supprimée en remplaçant par :
$retval .= sprintf('%s: %s%s', $k, isset($Response->$k) ? $Response->$k : '', "\n");Merci damien, ça marche impec 🙂
Merci Damien pour cette contribution de qualité.
Je viens de déployer la 2.1RC6 sur un Prestashop 1.3.6 équipé d’une version 2.0 de ton module.
La mise à jour c’est bien passée. Toutes la configuration précédente a été récupérée.
Pour info, j’utilise également le mode en paiement 3x.
Bref, du bonheur.
Si j’ai effectué cette mise à jour, c’est pour tester le retour automatique (NO_RESPONSE_PAGE) que je n’ai pas réussi à le mettre en oeuvre.
J’ai tenté de forcer BOOL_FORCE_RETURN à true dans _setDefaults() mais sans résultat.
Il y aurait quelque chose qui m’aurait échappé ?
Merci encore pour ton travail 🙂
Bonjour,
Avez-vous coché la case de configuration correspondante (onglet de configuration basique) ?
Si cette option n’est pas apparu sur votre back office c’est que vous n’avez pas purgé le cache smarty après mise à jour du module (je le rappelle à tout hasard: ceci devrait être fait après chaque mise à jour d’un module utilisant des templates smarty ou après modification d’un template)
Effectivement, cette option n’apparaissait pas dans l’onglet de configuration Basique.
J’ai vidé mon dossier tools/smarty/compile/ comme demandé, activé l’option, et effectué un test de paiement avec retour automatique, qui a été concluant.
Merci encore pour ce module, et la qualité de ce support.
Une donation est amplement méritée 🙂
@ bientôt
Bonjour Damien,
J’ai ce deux messages d’erreur après la MAJ de PS en 1.4.7 :
Le ou les modules suivants n’ont pu être chargés:
[atos] Erreur dans le fichier de configuration: Entity 'Ecirc' not defined
[atos] Erreur dans le fichier de configuration: Entity 'ocirc' not defined
Bonjour,
D’où proviennent ces messages ?
Dans la partie module en BO.
Re !
Désolé du « stress » mais cela ne vient pas de ton module mais de celui par defaut de PS (atos) qui génère un config.xml avec des é, ô qui foutent la merde.
C’est du à la MAJ de prestashop via le module autoUpgrade
par ailleurs, j’ai remarqué que l’interclassement de ta table pour le module est en : « latin1_swedish_ci »
Bonjour,
C’est probablement l’interclassement par défaut de votre base de donnée, de toutes façon l’interclassement n’est par exploitée sur cette table (pas de champs texte)
D’accord 🙂 ! Merci de tes réponses
Saut Damien,
Je voudrais savoir comment faire si l’utilisateur ferme la fenêtre au lieu de retourner à la boutique ? Du coup, les hooks ne sont pas appellés
Bonjour, c’est pour ce cas qu’existe la fonction de forçage du retour (avez-vous au moins lu l’article sur lequel vous postez ?)
Bonjour,
Merci de ta réponse pour le moins sèche !
Sache que oui j’ai lu la doc et j’ai déjà essayé le mode forçage nous ne voulions pas forcer les gens à revenir.
Surtout que le hook sera appeler même si le paiement n’est pas un succés ?
Désolé c’est parce que je répond pour la 50ième fois a la même question ce qui est fatiguant et décourageant.
Pas d’autre solution que le forçage (vous pouvez jouer sur le wording pour inciter le retour), je n’y peux rien, la solution Atos est ainsi faite.
L’un des deux hooks est systématique, l’autre uniquement en cas de validation de paiement.
Bonjour
Je viens d’installer le module SIPS/ATOS v2.1.6 sur ma boutique prestashop 1.4
Les tests en préproduction sont ok coté prestashop (aussi bien dans l’interface d’admin que les emails).
Par contre je ne pas la trace de ces transactions sur l’interface sherlocks LCL.
https://sherlocks-gestion.secure.lcl.fr/Login.jsp
Cela est il normal en mode préproduction ?
Comment être certain que tout fonctionne correctement avant d’envoyer le pv de recette ?
voici mon log :
Le 29-02-2012 19:25:07 de Privé :
CB
4974 #### #### ##65
amount: 100
merchant_id: 044177408000010
transaction_id: 1
transmission_date: 20120229182350
payment_time: 192506
payment_date: 20120229
response_code: 00
payment_certificate: 9e163196b5de
authorisation_id: 527667
currency_code: 978
cvv_flag: 1
cvv_response_code: ??
bank_response_code: 00
complementary_code:
complementary_info:
return_context:
receipt_complement:
merchant_language: fr
language: fr
customer_email: okaoma@voila.fr
customer_ip_address: 82.246.126.74
capture_day: 0
capture_mode: AUTHOR_CAPTURE
data: 3D_LS=;TRANSACTION_CONDITION=SSL;3D_RELEGATION_CODE=0;
Merci
Bonjour,
les transactions pré-production ne sont pas forcément visibles sur l’interface fournie par la banque. Le meilleur moyen d’en avoir le coeur net est de les contacter.
Bonjour Okaoma,
Je viens de voir que vous venez d’installer avec succès le module pour LCL…je suis hyper incompétente pour installer quoi que ce soit, pourriez-vous m’aider à « traduire » les étapes à faire? Je vous laisse mon mail perso celine@lesballet.com
Mille merci 🙂
Céline.
Bonjour,
Avant toute autre chose, merci Damien pour votre travail!
J’utilise actuellement la 2.0 Beta 4 RC4, et sauf erreur je n’ai vu personne dans ce fil reportant avoir installé cette version du module sur une vieille version the PS.
Quelqu’un a-t-il installé ce module sur presta 1.2.5?
Ce qui m’intéresserait c’est la fonction pour forcer le retour en boutique qui n’était pas présente sur la version du module que j’utilise actuellement.
Vu que le site est en prod, je préférerais être sur de mon coup avant de faire un MAJ.
Mais bon au risque de tout « casser » je préfère m’en passer si je n’ai pas le choix ou à défaut trouver une autre solution intermédiaire.
Donc si quelqu’un a déjà installé la nouvelle version du module sur un presta 1.2.5 sans soucis, merci de me le faire savoir.
Cordialement.
—
Muad’Dib
Normalement la solution devrait fonctionner sur un 1.2.5, cela fait du moins partie du cahier des charges que je m’impose, mais je dois avouer que je n’ai pas pris le temps de vérifier pour les dernières versions car je n’ai à priori rien modifié qui puisse casser cette compatibilité. Cette version étant vieille et largement obsolète étant donné les nombreux bugs, elle ne bénéficie plus d’un support actif de ma part, c’est à dire que je ne la teste plus étant donné le temps à y passer par contre je continue à corriger les bugs que l’on pourrait me rapporter sur cette version.
Il faudrait prendre le temps de créer un duplicata de votre site pour tester en mode démonstration.
Bonjour,
je vous remercie pour ce module atos mais, pas moyen de le faire fonctionner… j’ai deux message erreur sous mercanet bnp…
Il y a des erreurs
Le chemin vers les logs n’existe pas ou les droits sur les fichiers le rendent invisible.
Le chemin vers les fichiers de configuration est trop long, 54 caractères maximum, cf documentation du module.
Que faire ?
Merci,
Dany
Je n’ai plus qu’un message d’erreur…
Il y a des erreurs
Le chemin vers les logs n’existe pas ou les droits sur les fichiers le rendent invisible.
Je n’ai plus ce message d’erreur mais au moement de payer…
Page avec message :
The server encountered an internal error or misconfiguration and was unable to complete your request
{ Prestashop 1.4.3 – Banque LCL – Hébergement OVH Pro- tgg_atos-2.1.6.tar.gz }
Bonjour Damien,
désolé mais je ne sais plus ou regarder j’ai constamment cette erreur:
TGG_ATOS DEBUG OUTPUT
Tgg_Atos: Erreur durant l’appel de l’exécutable request
L’exécutable request a retourné une erreur.
(127): sh: request: command not found
Bonjour,
très probablement un problème de droit sur le binaire ou son dossier, ou un binaire incompatible.
Bonjour,
le module est maintenant installé sans message d’erreur par contre, les commandes passent même si les cartes sont refusées !!!
Donc rique d’envoyer des commandes non payées alors qu’elle apparaissent payées dans le BO !
Donc, svp, comment faire pour les cartes refusées n’apparaissent pas comme commande valide payées par cb, dans l’admin ?
Merci
Bonjour,
ce problème n’a jamais encore été rencontré (bientôt 3 000 téléchargement du module pourtant), le module ne crée la commande que si la transaction est acceptée par la banque.
Avez-vous fait des modification sur le module ?
bonjour Damien et merci pour ce module que j’ai commencé à installer mais j’ai un problème pour le configurer via le back office de prestashop.
Aprés avoir transféré via ftp le dossier /tgg_atos/ dans le dossier /modules/
J’ai configuré les droits d’accès aux fichiers tel que dans la doc
Dans la liste des modules, tgg_atos apparait avec le statut ‘installé et activé’ mais lorsque je clique sur ‘configurer’ je reviens sur la liste des modules et le message ‘module désinstallé’ apparait a coté du module, cependant le module a toujours le même statut.
j’utilise ps 1.4.0.17 , sur un serveur linux 64bits, php5 et mysql 5.0.44
Bien cordialement.
Ben
re-bonjour, je viens de résoudre mon problème
il venait de la configuration de prestashop qui était configuré pour mettre en cache les fichiers (Préférences ->Performances -> Cache )
Aucuns problèmes avec ton module 🙂
Une petite question quand même :
La réponse silencieuse du serveur bancaire ne-fonctionne t-elle que lorsque l’on active la fonction ‘Forcer le retour client’ ?
Bien cordialement.
Ben
Bonjour,
La réponse a ceci se trouve encore une fois dans la documentation Atos : la réponse silencieuse est toujours active, attention cependant au mode maintenance de Prestashop qui bloque ces réponses si vous ne spécifiez pas l’IP du serveur bancaire dans les IP autorisées en maintenance, si vous désirez obtenir cette IP adressez-vous a votre contact technique chez Atos ou votre banque (je le rappelle à tout hasard: je ne fais que fournir une passerelle permettant d’exploiter les fonctionnalités de la passerelle Atos, pour obtenir des informations sur ces fonctionnalités adressez-vous a votre technicien Atos, surtout que les fonctionnalités peuvent varier légèrement selon la banque et le contrat passé. De plus ils sont censés connaitre le sujet bien mieux que moi, et puis n’oubliez pas que vous leur payez un abonnement mensuel, autant le rentabiliser ;-))
bonsoir et merci pour ce fabuleux travail ,
mais probleme, je viens d’installer le module sur ma boutique, tout est ok sauf :
je tombe sur le fameux « Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient »
j’ai beau activer le debugg, je ne vois rien, donc impossible de trouver d’ou vient la « panne »
une piste ( probleme standard ? que des newbies comme moi rencontre ? )
ersion de Prestashop: 1.4.6.2
Informations sur votre serveur: Linux #1 SMP Thu Jan 26 14:55:34 UTC 2012 x86_64
Version du logiciel serveur: Apache/2.2.X (OVH)
Version de PHP: 5.2.17
Version de MySQL: 5.1.49-3-log
encore merci d’avance
Bonjour,
Je debute totalement avec Prestashop…et je suis entrain d’installer votre module qui me semble vraiment efficace…
J’ai par contre un petit problème…Quand j’essaie de faire un test… j’obtiens l’erreur 139 ? Je suis chez OVH…
Auriez-vous une solution à mon problème svp ?
Merci d’avance
Bonjour,
l’erreur 139 est une erreur liée à l’hébergement : contactez votre hébergeur ou consultez la documentation de votre distribution linux.
cf réponse à question identique
Bonjour Damien! Encore merci pour le travail que vous effectuez sur ce module, il me sauve toujours un peu plus chaque jour.
Cependant, j’ai un soucis avec en ce moment.
je n’ai effectué aucune modification dans le coeur du module, juste fait les modifications liées à votre tuto d’install. En mode de test et de preprod, tout fonctionne bien. Il y a quelques jours un premier client a tenté le paiement via le module atos. Le paiement a bien été effectué mais la commande n’est pas apparue avec le statut « paiement acceptée » coté back-office.
J’ai remarqué dans le compte-rendu de la transaction fourni dans les logs du module, que le champ cvv_response_code est systématiquement à ??. De plus, le champ « data » est toujours vide. J’ai sans grand succès tenté de trouver dans le coeur de presta, l’endroit exact où le statut lié à une commande basculait en « accepté », « annulé »,etc… Je ne suis sûr de rien, même pas du fait d’avoir un soucis avec voter module, car en effet, le virement est bien effectué de la banque du client vers la notre.
Pourriez vous m’apporter quelques lumières? en vous remerciant d’avance !
Bonjour,
ce sont les modules de paiement qui choisissent le statut de commande à appliquer lorsqu’ils appellent la méthode PaymentModule->validateOrder() pour convertir un panier en commande.
Les ?? dans cvv_response_code et le fait que data soit vide ne sont pas de choses anormales (contactez votre technicien ATOS pour plus d’informations).
Si la commande n’a pas été créée, cela peut venir de certains modules qui se greffent sur le hook de validation de commande et font planter le processus (par exemple So-Colissimo et certains modules d’analyse ROI non javascript, donc autre que Google Analytics, font planter parfois la validation de commande parce qu’ils essayent de contacter une URL qui ne répond pas avant le délai maximal d’exécution pour un script).
Bonjour et merci pour ce module
J’ai changé d’hébergement aujourd’hui pour prendre un simple hosting chez gandi mais en gros j’ai le même problème que maxence, pour ma part j’obtiens cette erreur :
(126): sh: 1: /srv/data/web/vhosts/www.designstickers.fr/htdocs/modules/tgg_atos/bin/request: Permission denied
Les droits sont pourtant bien configurés, je ne comprend pas ce qui se passe …
Quelqu’un peut-il m’aider ?
Bonjour damien as-tu déjà fait un suivi d’installation e-transaction credit agricole.
j’ai installé le module 2.1.6, j’ai reçu les mails credit agricole, je suis un peut perdu, ils me proposent de télécharger un exec CGI à place dans le cgi-bin etc…. avec des codes site et id transaction même en mode test.
J’aimerais savoir s’il faut suivre toute l’install même en mode test ou ton module est déjà préformaté.
Contact moi par mail si jamais ou tout autres personnes d’ailleur qui aurait installé e-transaction sur le module.
Bonjour,
commencez par suivre la procédure d’installation décrite dans la documentation PDF du module.
Prenez juste les exécutables request et response qui correspondent à votre hébergement pour remplacer ceux du module, puis votre certificat de production et votre ID marchand pour lorsque vous voudrez passer en mode pré-production.
Vous pouvez aussi mettre à jour le fichier de paramètres par défaut si vous le souhaitez (.parcom) en le remplaçant par celui fourni par la banque. Renommez au besoin pour conserver le même nom de fichier que celui du module.
Désolé de vous dire ça mais là je sèche complètement,
Le module 2.1.6 ok j’ai reçu les codes de test du credit-agricole e-transaction
avec un numero de site, un numero de rang et un id e-transaction pour faire les essais en mode demo.
Si j’ai bien compris avec le module on a juste besoin d’une certif et d’un id pour passer en preproduction.
Le problème c’est que la version test annule le paiement avec un vrai nuero de carte ou le numero que m’a fourni CA seulement l’expiration est jusqu’en 2008 hihi
dans la notice il y a un numero marchad rang etc pour les essais mais je suppose qu’on ne peut les rentrer nulle part.
en faite j’aimerais réaliser des tests et de verifier tous les cas de figures.
Quelqu’un a-ti déjà installer la methode e-transaction credit agricole cà m’aiderait beaucoup.
Merci.
Bonjour, les n° marchand pour les essais sont automatiquement pré-remplis par la module en fonction de la banque sélectionnée dans la configuration.
Effectivement, mis à part les connaissances techniques en hébergement nécessaires au déploiement du système ATOS il faut juste votre ID et votre certificat pour passer en mode pré-production.
Quant au numéro de carte de test, en réalité seules les deux derniers numéros sont utilisés pour déterminer la réponse, changez donc juste la date limite de validité par une date encore non expirée. (ces informations sont dans la documentation que la banque devrait vous avoir fournie, les numéros de carte de test dont vous parlez ne sont que des exemples pour illustrer ce principe.)
Bonjour Damien,
Utilisateur depuis plus d’un an de votre module, je viens de migrer la boutique de mon épouse en PS 1.4.7. Suite à une erreur de manipulation sur la version 2.0 RC4, j’ai installé la version actuelle 2.1.6.
Comme d’habitude, c’est de l’excellent travail hormis le fait que j’avais laissé dans le thème le répertoire modules/tgg_atos qui était nécessaire avec la 2.0 RC4.
En lisant votre documentation, j’ai compris que ce n’était plus nécessaire et le problème de traduction et de retour en cas d’annulation est résolu.
Comme quoi, une doc ça sert encore faut-il que les utilisateurs de votre module la lise…ce que j’ai fait !
Bonne journée.
Jean-Luc
http://www.sid-pro.fr
Bonjour, et félicitation pour tout le travail que vous abattez…
Je tente depuis quelques nuits de configurer une version 2.1.6 sur une version prestashop 1.4.7.0…
En suivant bien la doc pdf
droits sur les fichiers et repertoire ok
configuration vers les rep /bin /param /log ok
fichiers request et reponse tranfere en binaire
Bref je pensais avoir fait tout comme il fallait…
Mais il ne m’etre impossible de le tester, lorsque j’arrive sur la page de paiement… il m’indique l’impossibilite d’executer resquest ou encore que le rep ne peut etre lu….
Apres avoir parcouru moulte forum et blogs, je n’ai toujours pas trouvé de solution…
Je me tourne donc vers vous afin de trouver une solution.
Il peut s’agir de l’un de ces problèmes ou d’une interdiction depuis la configuration PHP (le safe_mode activé par exemple). Contactez votre technicien en hébergement qui devrait pouvoir vous indiquer la cause du problème.
Bonjour,
Tout d’abord merci pour ce module qui permet de faire des tests complets avec l’environnement de paiement SIPS.
Je travaille actuellement sur un projet (futur) sur le nouveau Prestashop 1.5 (une petite merveille en passant), en intranet sous Linux (avec Apache 2 à jour)… Et j’ai bien entendu testé votre module, dans sa dernière version !
Pas trop d’adaptations à faire, il s’installe bien et se configure correctement.
Une fois cela fait, le bloc de paiement SIPS est bien ajouté à la page panier avec les autres moyens de paiements. Aucun souci jusque là 🙂
Ensuite, je tente le règlement de ma commande, en mode test, et le site bancaire valide avec succès la transaction.
Je clique alors sur le bouton « RETOUR BOUTIQUE » et là je rencontre une erreur fatale qui empêche la validation de la commande sur le site.
Voici les détails, ça ne doit pas être grand chose, car à première vue, le code à l’air compatible avec la 1.5 (j’ai vérifié plusieurs fois) :
Fatal error: Uncaught exception ‘PrestaShopException’ with message ‘Can’t load Order state status’ in /home/info/www/prestashop/override/classes/PaymentModule.php:57 Stack trace: #0 /home/info/www/prestashop/modules/tgg_atos/tgg_atos.php(627): PaymentModule->validateOrder(21, NULL, 59.68, ‘SIPS/ATOS’, ‘VISA?1234 #### …’, Array, NULL, false, ‘8eace17891b195a…’) #1 /home/info/www/prestashop/modules/tgg_atos/front-ctrl/payment-return.php(23): tgg_atos->processResponse(Object(stdClass), Object(Customer), NULL, Object(Currency), 59.68, 0) #2 {main} thrown in /home/info/www/prestashop/override/classes/PaymentModule.php on line 57
En gros, l’objet Order ne semble pas suivre… le second paramètre de la fonction validateOrder() est à NULL.
Si vous avez une idée sur la question, je suis tout ouïe 🙂 Je continue mes recherches de mon côté.
Bonne journée.
Re !
Bon en fait j’ai résolu tous les problèmes rencontrés ( et oui, y en a eu plusieurs :p ).
Je veux bien votre mail pour communiquer tout ça 😉
A bientôt et bon courage.
Bonjour,
non, je n’ai pas fait de modification sur le le module 2.1.6,…
Boutique : 1.4.4.0…
Merci
Bonjour,
non, je n’ai pas fait de modification sur le le module 2.1.6,…
Boutique : 1.4.4.0…
Merci…
encore un problème avec le paiement cb… la commande est passée, je l’ai dans l’admin mais,
sur mercanet de la bnp… pas d’argent sur le compte… il est ecrit « commande à valider (sans autorisation) ». Je ne comprends pas.
Ah, vous auriez dû mieux décrire votre problème, nous y aurions gagné tous les deux du temps (à votre premier commentaire j’ai pris le temps de ré-inspecter tout le code par sécurité, près de 5h de travail inutile et non rémunéré dont je me serais bien passé).
Le paiement a bien été validé par la banque contrairement à ce que vous me disiez. Le paiement est cependant mis en attente car vous avez configuré le Mode de capture sur VALIDATION dans la configuration du module. Repassez-le à AUTHOR_CAPTURE (qui est la configuration par défaut du module !) et le paiement sera fait automatiquement. Vous devriez lire la partie sur LA CAPTURE DIFFERE de votre documentation ATOS.
Il ne s’agissait en fait pas d’un bug mais d’une erreur de configuration.
Désolé… mais je viens de contacter Mercanet… Ils me disent que cela vient du module prestashop, en me précisant de régler la partie « envoie en banque du module sur automatique »… pourtant il me semble que cela est effectué partout sur le BO… Il y a un autre endroit ou aller régler cela ?
Merci
Toujours aussi avare en détails les techniciens d’ATOS hein ?
Configurez cela dans la page de configuration du module, onglet de configuration Basique et reportez-vous à la partie « Capture différée » de la documentation ATOS, ce n’est pas une bonne approche que de modifier les paramètres d’une liaison bancaire sans savoir ce que l’on est en train de faire, cela risque de vous apporter de gros ennuis au final.
Enfin, je suis au moins rassuré de savoir que mon module n’y est encore une fois pour rien, la stabilité/fiabilité étant ma principale préoccupation durant tous mes développements sur celui-ci j’étais étonné que des commandes puissent passer sans validation de la banque.
Bonjour,
je viens de passer un certain mais je ne suis pas arriver à trouver une réponse.
Mon chemin est : /homez.333/imprimen/www/4×4-ProAccess/atos/log
qui fait moins de 54 mais ca me met toujours le message.
Une petite idée ?
Merci d’avance
Robin
Bonjour,
/homez.333/imprimen/www/4×4-ProAccess/atos/logest à priori votre chemin vers les logs, et non votre chemin vers les fichiers de paramètres… Ce dernier se configure dans l’onglet de configuration Avancée.En effet ca marche mieux,
désolé de t’avoir fait perdre ton temps.
Merci encore
Cordialement
Robin
Bonjour,
Je suis développeur et je rencontre actuellement un problème qui serait assez redondant sur votre module. Je suis sous Presta 1.4.5.1 et j’ai essayé plusieurs versions de votre module. Serait-il possible de vous contacter par e-mail ?
En vous remerciant par avance.
Cordialement
Bonjour,
Sauf si le problème ne peut être exposé publiquement sans nuire à la sécurité des installations du module, les problèmes doivent être exposés ici car ils peuvent intéresser d’autres personnes.
Bonjour Damien,
Suite à tes règles voici mes configs :
– PS 1.4.7
– TGG ATOS : 2.1.6 RC6
– PHP 5.3
– Debian lenny
– Apache
Je voulais savoir si le module TGG_atos devait être modifié pour les tests en pré-prod. ? Si ce n’est le changement de certificat ? J’ai un peu peur de faire des betises lors de mes tests de ma boutiques. !
Je peux l’utiliser telle qu’elle en prod (en ayant changé les certifs avant, évidement)
Peux tu éclairer ma lanterne à ce sujet, je voudrais pas que des paiements ne soient pas fait à cause d’un mauvais param’ !
Merci d’avance de ta réponse, Bon week end 😉
Il n’y a rien a faire sur Prestashop (et donc sur le module) pour la bascule entre pré-production et production, tout cela se passe coté banque. On ne change pas non plus de certificat.
Ah oui, donc juste pour la bascule test ->pré-production, je met les certifs de mon compte mercanet ?!
J’ai juste modifié ton module pour prendre en compte mes paiements en 2 fois avec 30% & 70%. Je sais que ton module permettais cela via la configuration mais j’avais des contraintes pour le prix total (TVA, Remise client PRO…). Donc je n’est pas trop d’inquiétude à faire ?
Je te remercie des tes réponses 😉
Bonjour,
Oui lorsque vous allez basculer en production/préproduction le module va vous réclamer un certificat (ou vous demander de le sélectionner dan la liste si vous l’avez déjà mis en place dans le dossier).
C’est le certificat standard que le module exploite, pas les certificats dits « PHP ». Vous pouvez ensuite basculer à loisirs entre le mode démo et (pré-)production sans avoir a changer de certificat (le module reprend automatiquement le certificat de démonstration de la banque lorsque vous le basculez dans ce mode, même si vous avez mis en place le certificat de production).
Concernant votre modification, si elle est faite proprement il n’y a pas de raison de s’inquiéter, et de toutes façons le paramètrage de mon module ne vous aurait pas permis de faire cela, vous étiez donc bien obligé de modifier le coeur du module. (Il ne faut pas oublier que ce module n’est pas financé par qui que ce soit et à l’heure actuelle, ce projet me coûte plus d’argent que ce que je reçois occasionnellement en dons, idéalement ce serait aux banques de soutenir le projet puisqu’elles ne vous fournissent pas de module. Ce qui explique pourquoi je ne peux me permettre de pousser trop loin la paramétrabilité du module, mais je pense qu’à l’heure actuelle il est déjà pas mal, j’en ai vu beaucoup de payant bien moins flexibles…)
Bonjour,
Je tiens à préciser que le dernier message n’est pas de moi mais bien d’un homonyme 😉
Alors j’explique mon problème.
C’est un problème récurrent et malheureusement visible aussi sur certains autres moyens de paiements. Rare, et aucune solution n’est présente, et vu que vous avez développé un module en directe relation, vous pourrez peut-être m’aiguiller…
Je suis sous Prestashop 1.4.5.1, et j’ai testé plusieurs versions de votre module, actuellement je suis sur la 2.0.b4, bien que le problème soit identique sur chaque version.
En fait, en production, quand on commande, la commande est visible dans le compte client, dans le tableau de bord, dans le Front Office, mais PAS dans l’onglet Commandes. En fait, la commande arrive Systématiquement en Annulé, en commande Invalide. Cependant, les paiements et les retours de la banque se font correctement.
J’ai regardé dans le message de retour, le code de réponse est bon, la clé de sécurité posait un problème mais j’ai forcé la variable à True dans paymentModule.php, il n’y a donc pas d’erreur apparente dans le code de retour.
Le fait que la commande n’apparaisse pas dans les commandes implique qu’il n’y a pas d’entrée dans la table ps_order_history. Si l’entrée est faite manuellement, il n’y a pas de problème bien entendu. Mais je n’arrive malheureusement pas, en fouillant dans les classes et contrôleurs appelés par le retour, à trouvé l’endroit où l’insertion est faite dans cette table.
Bref, vous l’aurez compris, j’ai passé des heures à chercher dans le code d’où pourrait provenir le problème, ce n’est pas un problème de production ou de préprod, et ce problème est déjà connu mais personne ne l’a encore résolu…
Auriez-vous une idée ? Il me semble que ce n’est pas en rapport avec votre module, mais vous avez dû vous rapprocher du fonctionnement et le connaître davantage….
En vous remerciant par avance…
Cordialement
Bonjour,
désolé de vous décevoir mais ce problème a déjà été résolu. ^^
Du moins l’une de ses causes les plus probables.
Sur les boutiques sur lesquelles ont m’a demandé de traquer l’origine de ce problème il provenait d’un module greffé sur l’un des hooks directement ou indirectement appelés depuis la méthode
PaymentModule::validateOrder().Cela peut être soit une erreur fatale causée par l’un de ces modules, soit un dépassement du délai maximum alloué à l’exécution du script. Le cas que j’ai le plus rencontré est un module inscrit sur le hook de création de commande ou le hook de changement de statut de commande qui effectue un appel distant (fopen, CURL, RPC…), par exemple pour déclarer la commande à un webservice. Le moyen le plus simple pour débusquer le coupable est de profiler ces hooks en notant le timestamp d’entrée et de sortie de chaque interruption (hook) assignée à un module. Vous vous retrouverez très probablement avec une interruption de module commencée mais jamais terminée, le coupable est alors tout trouvé. Le script ne s’exécutant pas jusqu’au bout, si votre profiler fonctionne par écriture d’un fichier log, assurez vous bien qu’il ouvre et referme le handle sur le fichier de log à chaque appel, c’est très mauvais en terme de performances mais cela évite de perdre des logs bufférisés mais non écrits physiquement sur le disque.
Je me souviens de deux modules ayant déjà été désignés coupables pour ce problème : So-Colissimo (le webservice ne répondait pas et le timeout était paramétré trop haut ou pas paramétré du tout), et un module dont j’ai oublié le nom qui servait de pont avec un comparateur de produits qui récoltait des stats sur les commandes de produit et qui avait le même soucis de conception.
Une erreur fatale durant les envois de mail pourrait aussi être une cause probable (que je n’ai jamais rencontrée).
Voilà, je pense qu’avec ceci vous ne devriez pas avoir de mal à trouver la cause exacte de votre problème, si vous n’y arrivez pas seuls vous avez normalement mon adresse mail, ou si vous souhaitez faire appel à une agence sérieuse je peux vous conseiller http://unebelleagence.fr/, j’y travaille et peux vous assurer que le travail y est fait sérieusement.
Cordialement,
TrogloGeek.
Bonjour
Je confirme… SoColissimo est bien le fautif dans mon cas…
Je remonte mes manches et vais essayer de trouver une solution.
@Vince : Le même coupable chez toi ou un autre ? tu as réussi à t’en sortir ?
Au plaisir
Pierre
A mon avis il faudrait corriger le module en ajoutant une gestion de timeout sur l’appel distant (cURL si je me souviens bien) et augmenter la durée d’exécution du script php.
Bonjour cher Damien,
J’utilise votre module sur prestashop 1.4.5.1
– TGG ATOS : 2.1.6 RC6
– Apache
– hébergement mutualisé (chez Oxito.com)
Lors de l’installation de votre module j’ai rencontré le problème (« chemin d’accès aux binaires trop long »)
Mais l’hébergeur ne m’as pas permis de créer de lien symbolique
j’ai dupliqué le dossier du module à la racine du serveur mais ce chemin était encore trop long.
Dans le champ « chemin des fichiers de config ATOS », j’ai remplacé :
/vdir/www.myshop.com/var/www/vhosts/www.myshop.com/web/modules/tgg_atos/param/
par
/var/www/vhosts/www.myshop.com/web/tgg_atos/param/
et mon installation a pu continuer..
pour info les autres chemins pointent toujours vers
/vdir/www.myshop.com/var/www/vhosts/www.myshop.com/web/modules/tgg_atos/bin/
et
/vdir/www.myshop.com/var/www/vhosts/www.myshop.com/web/modules/tgg_atos/log/
Le problème est que lorsqu’une commande CB est validée par la banque, le fichier log est renseigné, le mail d’alerte de nouvelle commande est envoyé au propriétaire du site, et les paiements sont encaissés, mais cette commande n’apparait pas dans l’onglet des commandes comme ‘commande validée’ elle apparait seulement dans la fiche client avec le status ‘commande invalide’, le propriétaire du site doit modifier manuellement cette commande pour qu’elle apparaisse dans la partie commande.
Voici un enregistrement du fichier log :
merchant_id: xxxxxxxxxxxxxx
merchant_country: fr
amount: 2500
transaction_id: 6
payment_means: MASTERCARD
transmission_date: 20120402194029
payment_time: 215341
payment_date: 20120402
response_code: 00
payment_certificate: xxxxxxxxxxxx
authorisation_id: xxxxxx
currency_code: 978
card_number: xxxx.xx
cvv_flag: 1
cvv_response_code: ??
bank_response_code: 00
complementary_code: 00
complementary_info: IP_COUNTRY=FRA,CARD_COUNTRY=FRA
return_context:
caddie:
receipt_complement:
merchant_language: fr
language: fr
customer_id: 69
order_id: 194
customer_email: xxxxx@orange.fr
customer_ip_address: xx.xx.xx.xx
capture_day: 0
capture_mode: AUTHOR_CAPTURE
origin: client_return
caller_ip_address: xx.xx.xx.xx
Connaissez-vous la cause de ce problème ?
Merci d’avance
Cordialement
Ben
J’ai déjà vu ce problème lorsque l’on cherche a arrondir les prix pour ne plus avoir de centimes. Vérifiez que le montant payé correspond bien au montant réel de la commande.
Que se passe-t-il lorsque vous utilisez une autre moyen de paiement (par cheque ou par virement par exemple) avec le même panier, rencontrez-vous le même problème ?
Bonjour et merci pour votre réponse si rapide 🙂
Tout les prix de produits de ma boutique sont entiers (pas de centimes) et les montants payés correspondent tous aux prix des paniers.
Je viens de faire un test avec un panier identique en utilisant le paiement par chèque -> la commande s’est directement enregistrée dans la partie ‘commandes’ mais elle est aussi en status invalide dans la fiche client…
Après quelques recherches sur les forums de tashop il se pourrait que le problème vienne de l’obligation pour les clients de remplir la deuxième ligne d’adresse
Merci encore pour votre aide
Cordialement
Ben
Bonjour,
Mon affiliateur me demande de lui fournir l’url de la page de confirmation de commande, autrement dit l’url de la page qui est chargée dans le navigateur dès que le règlement est validé.
Or, je n’ai pas trouvé d’info sur cette url.
Pouvez-vous m’aider à ce sujet ?
Cordialement,
R. PIBOLLEAU
Cette URL ne dépend pas du module mais de la configuration de Prestashop.
Passez une commande et voyez ce que cela donne.
bonjour,
j’ai un petit souci avec mon site prestashop version: 1.4.3
j’utilise le module: SIPS/ATOS v2.1.6
hébergé chez OVH
lors du clic sur le logo du paiement CB, j’arrive sur cette page:
modules/tgg_atos/front-ctrl/payment-redirect.php
et la page bloque sur une page blanche…
avez vous une petite idée?
merci par avance.
Bonjour,
activez l’écriture des logs d’erreur PHP et Apache si ce n’est déjà fait puis récoltez les logs correspondant à l’erreur.
Sur un serveur OVH cela peut éventuellement venir de droits sur les fichiers fixés trop haut (pratique interdite sur les mutualisés OVH, et dangereuse).
merci pour votre réponse si rapide,
le payement-redirect affiche maintenant ma page mais avec:
« Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient. »
et /homez/monsite/www/modules/tgg_atos/bin/request: No such file or directory
alors que les bin sont à la bonne place…
je vois que ma demande ne semble pas valide pouvez vous me dire se qu’il vous manque comme informations?
merci beaucoup.
Les informations à fournir sont affichées dans le formulaire de soumission de commentaire.
Vous trouverez dans la documentation fournie avec le module les informations sur les droits à appliquer selon les fichiers pour ne pas obtenir ces erreurs.
voici mes réglages:
–tgg_atos/ 755
– tgg_atos/images/ et son contenu 505
– tgg_atos/card_logo/ et son contenu 505
– tgg_atos/logo.gif 505
– tgg_atos/front-ctrl/ 705 et son contenu 505
– tgg_atos/log/ 700
– tgg_atos/param/ 700
– tgg_atos/fr.php 700
– le contenu de tgg_atos/bin/ 755
– fichiers .htaccess 644
Salut Damien,
– PS 1.4.7
– TGG ATOS : 2.1.6 RC6
– PHP 5.3
– Debian lenny
– Apache
notre équipe avons remarqué un bug, mais je n’arrive pas à déterminer si ça vient de ton module. Je t’explique :
Lors d’une commande, au moment du payment (au niveau du choix des CBs) si tu ouvre un nouvelle onglet et que tu ajoutes un produit à ta commande, le premier onglet contiendra bien le nouveau produit (lorsqu’on l’on passe à l’étape mercanet) mais le montant n’est pas changé… !
Du coup, facturation d’un produit pour une commande en contenant deux… !
Pourtant dans ton module tu appels bien le panier courant, il me semble…
peut-être un bug de corrigé dans la 2.1.7 ?!!
Merci d’avance,
Bonjour,
Il s’agit d’un problème dont je suis bien conscient mais qui est dû à la manière dont Prestashop fonctionne (vous aurez le même problème avec les autres modules de paiement).
De plus, il faut savoir que lorsque vous voyez les logos de carte de paiement, il s’agit du formulaire de redirection généré par Atos, donc à ce stade le montant de la commande a déjà été fourni au système ATOS et je n’ai plus la main. Par contre si vous rafraîchissez cette page après avoir modifié votre panier les modifications sont bien prises en compte.
Cela dit, Prestashop doit vous afficher une alerte sur la non correspondance du montant payé lorsque vous consultez la commande, et il me semble que le statut de la commande passe automatiquement en erreur de paiement.
Accessoirement, il faut savoir que cette démarche que vous décrivez (modification de la commande depuis un autre onglet puis retour à la page de paiement pour valider) peut-être considérée comme frauduleuse, voir même comme un tentative de piratage, puisque vous avez validé le résumé de votre commande avant d’accéder à la page de paiement, le fait de modifier depuis un autre onglet votre panier puis de payer sans repasser par le récapitulatif final de commande n’a rien d’une démarche honnête.
Effectivement, mais notre travail serait moins passionnant si nous avions à faire qu’a des gens honnêtes !
En plus, je doute que nous aurions connu la même évolution.
Toujours est-il, que j’ai essayé sur d’autre site et il semble « bloqué » cette utilisation. La valeur du panier est bien mise à jour…!
Vous avez bien les mêmes effets chez vous ?
Pourriez-vous mieux décrire ce que vous appelez « bloquer cette utilisation » ? Je ne comprends pas ce que vous voulez dire.
Le système ATOS requiert l’affichage d’un formulaire généré par l’exécutable request. Ce formulaire contient les données chiffrées sur le paiement à effectuer. Une fois le formulaire affiché, on n’a plus la main. On peut éventuellement tricher avec du javascript par exemple en inscrivant un évènement javascript sur la soumission du formulaire pour vérifier en AJAX que le panier n’a pas bougé pour savoir si on doit rafraîchir le formulaire avant d’accepter la soumission de ce dernier.
Bonjour,
J’ai lu dans la doc qu’il était possible d’utiliser le hook tggAtosOrderConfirm, avec un certain nombre de paramètres. Je souhaiterais configurer un tag de confirmation de commande, à afficher dès que la commande est validée. Or, je ne sais pas trop comment récupérer les informations de la commande dans un module à accrocher sur ce hook.
Avez-vous plus de détails sur cette fonctionnalité, voire un exemple de module à accrocher sur ce hook ?
Merci de votre aide.
Salut,
Voici un tout petit exemple : ode.troll.sh/iiK1Wk.xml
(vraiment minimaliste). Je pars du principe que tu as fais accroché ton module au hook tggAtosOrderConfirm.
Tu peux récupérer les objets Cart, Order… (voir la doc) !
ensuite traiter ces objets de façon classique.
Pour voir les attributs/propriétés des objets en question, voir dans le dossier
/classes/Lobjet (exemple pour Cart /classes/Cart.php)
Au tout début de la classe, il y à les attributs/propriétés de classe et ensuite ses méthodes.
Tu peux donc faire :
$moncartconfirm = $param['cart'];
$mon_id_cart_confirm = $moncartconfirm->id;
$la_lang_du_cart = $moncartconfirm->id_lang;
🙂
Mince, j’ai fais le toto pour le lien :
http://code.troll.sh/iiK1Wk.xml
Merci pour le coup de main au support Vince, cela m’aide beaucoup.
@PIBOLLEAU: les hooks mis à disposition par le module sont des hooks procéduraux et non des hooks graphiques et ne peuvent par conséquent pas être exploités pour afficher quoi que ce soit (cela briserait les redirections). Pour ce que vous souhaitez faire il y a le hook graphique standard de Prestashop ‘OrderConfirmation’ qui sert à faire ce que vous souhaitez. Le plus simple que je puisse vous conseiller si vous débutez est de prendre exemple sur le module ganalytics fourni en standard avec Prestashop qui fait entre autres exactement ce que vous souhaitez faire.
Bonjour,
J’utilise Prestashop 1.4.7.3, Tgg_Atos 2.1.6, PHP 5.3.6, Centos 5.8, httpd 2.2.3.
Lorsque j’installe le module depuis le backoffice de prestashop, j’obtiens toujours ces erreurs:
Hook declaration: La déclaration de mise à disposition du hook « tggAtosBankReturn » est un échec.
Hook declaration: La déclaration de mise à disposition du hook « tggAtosOrderConfirm » est un échec.
En effectuant un débogage, j’ai constaté que cela venait du champs ‘title’ de la table ‘hook’ qui n’a pas de valeur par défaut. Or personne ne semble n’avoir ce problème.
Y-a-t-il un problème dans mon installation, quelque chose m’échappe?
Merci de votre aide.
Je regarde cela dès que possible.
De toutes manière si vous ne comptez pas utilisez ces hooks pour créer un module interagissant avec tgg_atos vous pouvez totalement ignorer ce problème. Ces hooks servent uniquement à lier des actions complémentaires lors de la reception d’une réponse bancaire et ne sont pas utiles au module tgg_atos.
Effectivement, je viens d’inspecter et c’est un bug de Prestashop.
Le champs title n’a comme vous le dites pas de valeur par défaut et ce champs n’existe pas sur les instances de classe.
Les versions touchées (le bug était déjà là en 1.2.4 et est toujours là en 1.4.7) ne peuvent donc pas créer de nouveaux hooks (à part en le créant directement en SQL mais ce qui n’est pas une bonne approche en terme de compatibilité avec les différentes versions de PS).
Voilà pourquoi je préfère utiliser Magento ^^, le développement de cette application mené avec beaucoup plus de sérieux, et accessoirement l’application est extrêmement flexible pour peu que l’on sache développer des modules, par exemple http://www.happy-post.com, une alternative performante à So-Colissimo, est monté en Magento et pourtant est très loin de l’application Magento d’origine.
Reste à comprendre pourquoi sur mes instances PS les hooks se créent correctement alors qu’ils ne devraient pas…
Merci pour votre réponse!
Bonjour,
Tout d’abord, un grand merci pour ce module et toutes ces explications. J’ai eu beaucoup de facilité à l’installer et à le configurer jusqu’à maintenant grâces aux nombreuses informations.
Toutefois je rencontre un problème étrange. J’ai tout configuré correctement il me semble, j’ai même réussi à effectuer un paiement en mode test mais lorsque j’essaye d’en faire un deuxième j’ai l’erreur suivante :
« 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 »
Bonjour,
J’ai finalement trouvé la solution. J’avais changé le nom de mon logo et mis l’extension .png du coup il fallait bien évidemment changer cela dans la parcom.xxx ou xxx = cyberplus, elysnet, etc.. la solution que vous utilisez.
Si ça peut aider quelqu’un.
Bonjour,
le nommage du logo ne devrait pas déclencher d’erreur de sécurité, au pire vous devriez avoir une image « brisée ».
Je vous conseille de vous rapprocher de votre contact ATOS pour obtenir plus d’information sur l’erreur.
Merci pour ta réponse j’ai réussi à résoudre le problème.
Toutefois, j’ai une autre question : le paiement est bien fait, la commande se retrouve bien dans le back-office tout est nickel par contre, le stock ne se décrémente pas. Est-ce dû au mode démo ? (ou sinon à un bout de code perso que j’aurai oublié d’enlever)
Dans quelle direction puis-je chercher ?
Ceci est géré par la configuration Prestashop, pas par le module (le statut de commande pour les paiement réussi dans la config du module peut intervenir)
Encore une fois merci pour ta réponse. J’ai effectivement cherché dans cette direction et un développement perso prenait le dessus. Tout est maintenant opérationnel 😀
Bravo pour ton module !
Bonjour Damien,
Je n’arrive absolument pas à installer votre module. Je suis désolé, je suis nouveau sous Prestashop.
Dans les faits, je n’arrive à rien sauvegarder depuis le backoffice, ni la banque, ni le ID commerçant, ni le ID transaction, ni l’adresse email. Rien :[
Dans cette réponse, vous acceptez de nous aider moyennant rétribution :
http://prestashop.blog.capillotracteur.fr/2010/07/27/module-atos-sips/#comment-543
Seriez-vous disponible pour m’aider à installer votre module ?
version PHP :
PHP 5.3.8
système d’exploitation et version :
FreeBSD 8.2 – amd64 (64bit)
serveur HTTP et version :
Apache 2.2.21
Merci !
Bonjour, désolé pour le retard, je prenais un peu de vacances.
Je suis disponible si vous avez toujours besoin d’un coup de main, je vous envoie un mail pour que nous puissions communiquer.
Bonjour,
Est ce qu’il existe un module à graffer ou pré-installé permettant à TGG_ATOS de faire du 3Ds car je n’ai pas trouvé cette option?
Si inexistant, quel serait le coût de développement ?
Merci et bonne journée.
Config:
Version de Prestashop: 1.4.7.0
Module TGG_Atos: 2.1.6
Informations sur votre serveur: Linux #1 SMP Tue Dec 29 14:41:12 UTC 2009 x86_64
Version du logiciel serveur: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.8g
Version de PHP: 5.2.5-pl1-gentoo
Version de MySQL: 5.0.44-log
Bonjour,
Le module n’a besoin d’aucun développement complémentaire pour utiliser le mode 3D-Secure, pour cela il faut simplement utiliser le bon certificat fourni par l’organisme avec lequel vous avez signé votre contrat VAD.
Pour pouvoir utiliser le mode 3D-Secure dès l’étape de démonstration vous devez prendre contact avec votre contact technique ATOS et suivre ses instructions en s’appuyant sur la réponse à la question « Comment ajouter une nouvelle banque utilisant le sysème ATOS/SIPS 600 au module ? » de la FAQ contenue dans la documentation fournie avec le module pour connaitre les différences de manipulation entre le fichiers call_request d’exemple que la banque utilise pour ses explication et le principe propre au module.
Ce n’est pas simple, mais je n’y peux rien si ATOS aime compliquer les choses.
Bonjour,
Voici ma config :
– PS 1.5.09
– TGG ATOS : 2.1.6 RC6
– PHP 5.3
– Debian sur dedibox
– Apache
J’ai donc installé le module et paramétré la banque (e-transaction). Et ça fonctionne … ou presque !
Pendant la phase de test, je fait mon paiement, le valide, le retour de la banque s’affiche et quen je veux retourner à la boutique. Erreur 500 sur modules/tgg_atos/front-ctrl/payment-return.php.
Et quand je vais dans le back office, sur les paramètres du module, je n’ai rien dans la liste déroulante pour l’état de la commande lors d’un paiement validé.
Où sont les valeurs ?
Merci d’avance,
Franck
Bonjour,
le module n’a pas encore été porté en PS 1.5.x puisqu’il n’existe encore aucune version stable de cette branche (déjà que les versions labélisées stables ou final de prestashop contiennent encore souvent pas mal de bug évidents…).
Votre problème semble venir de l’abandon de la constante _USER_ID_LANG_ dans cette branche de Prestashop, apparemment il faut maintenant aller chercher l’ID de langue courante dans un objet de contexte.
Si vous n’aimez pas mettre les mains dans le code je vous déconseille vivement d’utiliser une version de Prestashop encore en cours de développement. 😉
Bonjour et merci pour la réponse.
C’est la première install de Prestashop que je fait et j’ai vu que la version 1.5 était dispo. Je n’ai pas vu qu’elle était en Beta.
Du coup, je suis à la limite de la prod avec ce « petit bug ». Je veux bien un coup de main contre une donation proportionnelle. Sinon, je dois tout remonter en version 1.4.7 !
Me contacter sur ma BAL au cas où.
Merci d’avance
Franck
Bonsoir Damien !
Merci encore pour ce formidable module, avec lequel j’ai quand du passer quelques temps car n’ayant pas trop de connaissances dans ce domaine la.
Je pense à présent avoir compris le fonctionnement, j’ai effectué plusieurs paiements test, le retour sur le récapitulatif du paiement est bon, j’ai bien la commande dans mon historique (mon compte), et tout est notifié dans le back office.
Mais étant donné que j’ai quand même quelques doutes sur les droits donnés à certains dossiers/fichiers, j’ai peur d’avoir un trou de sécurité, et j’aimerais également vous demander de jeter un oeil voir si tout est bien en place.
Pourriez vous me contacter par mail (voir adresse de contact du commentaire) pour que l’on puisse voir cela ensemble.
J’ai besoin d’etre sur d’avoir tout bien fait car je ne veux pas d’ennuis par la suite. Bien entendu, je serais prompt à faire un don (qui était prévu d’ailleurs) pour le service rendu.
Je vous laisse quand même mes infos :
Prestashop : 1.4.7.3
Version de Prestashop: 1.4.7.3
Informations sur votre serveur: Linux #1 SMP Thu Jan 26 14:55:34 UTC 2012 x86_64
Version du logiciel serveur: Apache/2.2.X (OVH)
Version de PHP: 5.3.10
Version de MySQL: 5.1.49-3-log
Merci d’avance !
Laurent
Je viens de retenter un paiement, et j’ai eu cette erreur :
« 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 »
Bonjour,
si ce message vient du serveur bancaire c’est cotre contact technique ATOS qu’il vous faut contacter.
Un soucis au niveau des droits de certains fichiers/dossiers peut être ?
Je vous contacte par mail.
Non, plutôt le fait que l’ID de transaction a déjà été utilisé par un autre site (le certificat de mode démonstration est partagé entre tous les clients d’une même banque !) je pense. Je n’ai trouvé aucun problème dans votre installation, you’re good to go.
Bonjour et avant tout merci de mettre a disposition un module que d’autre vendent fort cher !
Je me trouve confronté à un soucis que je ne m’explique pas.
Lorsque j’installe le module j’obtiens tout le temps l’erreur juste avant de passer sur le serveur atos :
(255): !-1!Invalid Keyword in parameter (2>&1)!!
En mode debug ça m’a donné ça :
TGG_ATOS DEBUG OUTPUT
array(3) {
[« cmd »]=>
string(646) « request « amount=2036 »
« automatic_response_url=XXXX/modules/tgg_atos/front-ctrl/payment-autoresponse.php »
« cancel_return_url=XXXX/modules/tgg_atos/front-ctrl/payment-return.php »
« capture_day=0 » « capture_mode=AUTHOR_CAPTURE » « currency_code=978 »
« customer_id=20 » « customer_email=XXXX@orange.fr »
« customer_ip_address=XX.XX.XX.XX » « language=fr »
« merchant_id=XXX »
« normal_return_url=XXXX/modules/tgg_atos/front-ctrl/payment-return.php »
« order_id=41298 » « transaction_id=1 »
« pathfile=/home/WwwBSD/XXX/modules/tgg_atos/p/pathfile »
2>&1″
[« status »]=>
int(255)
[« system_result »]=>
string(41) « !-1!Invalid Keyword in parameter (2>&1)!! »
}
Je suis hébergé par Icodia sur un serveur Php5 sous linux
Les versions exactes du noyau par exemple je ne les connais pas (je n’ai pas accès a un shell)
En attendant j’ai mis un module super simple qui marchouille mais tres peu de fonctionnalité (par exemple absence d’auto reply …)
Toute aide sera la bienvenue et je vous remercie par avance
Bonjour,
il semble que vous soyez confronté à un problème d’échappement de caractère sur la ligne de commande,
je vous envoie un mail pour que vous puissiez me transmettre les informations de debug dans un fichier texte qui ne sera pas altéré.
Bonjour et merci a toi pour ce module tout simplement excellent et qui fait ce pour quoi il a été écrit ! 🙂
Donner du temps pour développer un module de qualité doit te prendre sur ton temps libre, et le partager ensuite …. Bravo !
La doc ATOS est un peut imbuvable 😉
J’ai a migrer de la version 1.4.5.1 a 1.4.8.2 et j’espère pourvoir de faire le maximum de feedback a l’avenir pour que tu puisse évoluer tranquillement cette petite bombe.
100% pour te faire de la pub
Bonjour et merci pour ce module
Suite à de nombreux essais, je reste bloqué sur un problème de retour, la commande est bien validée, mais non prise en compte sous prestashop..
Version de prestashop : 1.4.7
PHP: 5.2.17
système exploitation : free bsd 8
serveur http : certified hosting
banque: Crédit agricole
TGG_ATOS DEBUG OUTPUT array(4) { [« cmd »]=> string(649) « /home/jbdzncom/public_html/d-tonan.com/modules/bin/request « amount=399 » « automatic_response_url=http://d-tonan.com/modules/tgg_atos/ front-ctrl/payment-autoresponse.php » « cancel_return_url=http://d-tonan.com/ modules/tgg_atos/front-ctrl/payment-return.php » « capture_day=0 » « capture_mode=AUTHOR_CAPTURE » « currency_code=978 » « customer_id=2 » « customer_email=klemsy26@gmail.com » « customer_ip_address=82.246.253.98 » « language=fr » « merchant_id=013044876511111 » « normal_return_url=http://dtonan.com/modules/tgg_atos/front-ctrl/payment-return.php » « order_id=76 » « transaction_id=9 » « pathfile=/home/jbdzncom/public_html/d-tonan.com/modules/ param/pathfile » 2>&1″ [« status »]=> int(0) [« atos_return_code »]=> string(1) « 0 » [« atos_result »]=> string(2134) « – Si vous payez avec votre portefeuille virtuel »}
Merci d’éclairer ma lanterne afin de savoir d’ou vient le problème (banque, serveur, module, atos…) et encore une fois merci pour ce module open source
Cordialement,
James
Bonsoir,
il faut regarder vos logs PHP & HTTP (après les avoir activés au besoin et avoir passé une nouvelle commande) pour savoir si une erreur a été produite.
La cause la plus courante est un time-out serveur dû à un module (généralement So-Colissimo) greffé sur le hook de confirmation de commande ou de changement de statut et qui bloque Prestashop à cause d’une requête fopen ou CURL mal configurée.
Il y a déjà pas mal de réponses à ce problème sur le blog.
Bonjour,
Tout d’abord, je vous remercie d’avoir créer ce module et vous félicite pour le temps que vous y consacrez.
J’aurai donc besoin de votre aide.
Prestashop Version 1.3.1.1
Hebergeur : OVH
Hébergement mutualisé Perso
PHP Version 5.2.17
System Linux web351.60gp.ha.ovh.net 3.2.2-grsec-mutu-grs-ipv6-64 #1 SMP Thu Jan 26 14:55:34 UTC 2012 x86_64
Crédit Agricole e-transaction
J’ai donc installé votre module. Tout s’est bien passé au niveau de l’installation. Effectivement, j’ai eu un message d’erreur sur le nombre de caractère. J’ai donc copié le dossier à la racine du site, le niveau au dessus du dossier www, et corrigé les urls dans le backoffice du module.
Je teste dans le frontoffice et au moment où je choisi le moyen de paiement, je tombe sur la page avec la phrase « Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient. »
Donc d’après votre documentation, j’aurai une erreur.
Effectivement je reçois par mail :
L’exécutable request a retourné une erreur.
(126): sh: /homez.358/demeton/m/bin/request: Permission denied
J’ai fait des recherches sur google, donc soit je cherche mal, soit je ne trouve pas. Et je ne sais plus quoi faire. J’ai testé des tas de choses sans succès.
Pourriez-vous m’aider ?
Merci
Bonjour,
c’est pour cela que les implémentations ATOS/SIPS doivent toujours être installées par des techniciens en hébergement (ce n’est pas un contrainte de ce module mais une réalité pour toute implémentation de passerelle ATOS/SIPS dû à la manière dont leur système fonctionne).
Votre linux vous dit ce qui ne va pas :
(126): sh: /homez.358/demeton/m/bin/request: Permission denied.Il semblerait que vous n’ayez pas suivi correctement le point 3. de la documentation section Installation (se reporter aussi à la section liée Droits nécessaires sur les fichiers) et que l’utilisateur PHP de votre site n’ait pas les droits nécessaires à l’exécution du binaire request ou que les binaires soient incompatibles avec votre kernel. Une fois les droits réglés sur ce binaire, pensez à faire de même sur le binaire response. Cela pourrait éventuellement aussi venir de l’activation du safe_mode PHP mais j’en doute vu le message d’erreur.
Si vous installez une implémentation ATOS/SIPS sans avoir un niveau technique suffisant en hébergement et sécurité web vous êtes légalement coupable de négligence criminelle car cela peut compromettre la confidentialité des informations bancaires de vos clients, ce qui pourrait vous coûter bien plus cher qu’une intervention de votre technicien habituel ou contracté pour l’occasion et ruiner votre image de marque. Pensez-y car je ne saurais être tenu responsable d’une mauvaise manipulation de la solution.
Merci pour ces informations. Je vais voir ce que je peux faire auprès de mon hébergeur.
Sinon j’avais déjà fait les tests sur les chmod, et ca n’avait rien donné. J’ai passé les données aussi en binaire (tout ca via winSCP), pour que tout soit fait proprement. Et j’ai bien suivi ta documentation.
Je te fais suite dès que j’ai de nouvelles informations.
Merci pour ta réponse et pour ton aide
Bonjour Damien,
Félicitations pour le module. Je suis sous la version 2.1 rc6 et j’ai testé ce dernier en mode de test avec les fichiers adéquats.
Le mode test a fonctionné parfaitement, mais je bloque maintenant en pré production.
J’ai configuré ton module avec la nouvelle ID transmis par la banque. Le certificat est maintenant dans le bon répertoire à la place du certificat de démo. Il a été renommé comme il se doit.
Pour le fichier PARMCOM, il a également été renommé et je n’ai aucun message d’erreur sous prestashop version 1.4.6.2..
Bref en dehors du changement de certif et de renommé le fichier ci dessus tout est ok. Sauf qu’arrivé au moment crucial, l’adresse url de la banque me renvoi
https://sherlocks.lcl.fr/cgis-payment-sherlocks/prod/callpayment
Transaction invalide
Nous regrettons de ne pouvoir donner suite à votre demande, merci de prendre contact directement avec le commercant en indiquant votre problème
« Le tout sur fond jaune et écriture rouge. Pas d’autre info et la doc d’atos ne me rapporte que le tableau ci après pour ce type de message d’erreur : »
Invalid Transaction
Un des paramètres de paiement n’est pas valide (mauvais format)
Vérifiez le format des paramètres de la transaction
ou
message modifié
fraude suspectée, Appelez l’équipe technique
ou
Un des paramètres de paiement ne correspond pas à votre configuration bancaire
Vérifiez la cohérence entre votre contrat vente à distance et votre transaction (devise acceptée par exemple)
Je ne vois pas ou chercher pour trouver la solution ???? As tu une idée, merci encore
Cordialement
didier
Non, si tout a été fait correctement, pas d’idée, mais pourquoi ne contactez vous pas simplement l’équipe technique comme le serveur de banque vous y invite ?
Je ne comprends pas, comme beaucoup de gens, vous payez (grassement) un abonnement Atos mais c’est moi (que vous ne payez pas) que vous contactez généralement en premier au moindre problème technique Atos…
Si cela continue le module deviendra payant vu que je passe plusieurs heures par semaine en support dessus…
Merci pour ce module.
Installation serveur dédié.
PS 1.4.8.2
Smarty 3
Banque : Société générale
Aucun problème à signaler, bien lire la documentation très complète. Bravo pour ce travail impeccable.
Bonjour,
Un simple message pour vous féliciter. Le module est très simple d’utilisation, très bien documenté. Je vais recommander ce plugin sur mon blog.
Un grand bravo, et bon courage pour la suite =).
Infos : Chez moi cette version fonctionne très bien sous PS 1.4.7.0, smarty 3, Sherlocks. J’ai simplement du mettre à jour les certifs qui n’était plus à jour pour Sherlocks en les demandant à LCL.
Bonjour,
Tout d’abord, merci pour ce module, il est simple d’utilisation et d’installation.
Je voudrais revenir sur le problème de commande annulée après paiement par carte validé.
J’ai installé un module appelé « Mail by Order State » qui permet d’envoyer un mail avec la facture juste après paiement validé au client.
Ce module semble poser problème pour le passage du statut « commande validée » dans le back office.
Ce n’est pas grand chose, mais si ça peut aider certains… parce que j’ai cherché des heures et des heures d’où pouvait provenir le problème…
Après désactivation de ce module, je n’ai plus eu de problème de commande annulée. Pourvu que ça dure ! 🙂
Seb