Module EUROINFORMATION et bugs corrigés

ScaleDEV · January 15, 2009

Bonjour,

Je rencontre un gros soucis avec l''environnement de test du module de paiement euroinformation.
Tout fonctionne coté envoi banque et retour, par contre la commande ne s'enregistre pas et le panier n'est pas vide ...

Quelqu'un a t-il déjà résolu ce problème ?

Merci d'avance

EDIT : module mis à jour de divers bugs en date du 15/08/2010

euroinformation.zip

ScaleDEV · January 17, 2009

Bonjour,

Après avoir corrigé certains petits bugs dans le module, ma commande ne s'enregistre toujours pas ...

Voici le code en question qui devrait normalement enregistrer la commande depuis le N° du panier :

if(strtolower($BruteVars['code-retour'])=='payetest' || strtolower($BruteVars['code-retour'])=='paiement'){
   include_once(dirname(__FILE__).'/euroinformation.php');
   $EI = new EuroInformation();
   $montant = number_format(intval($bruteVars['montant']), 2, '.', '');
   $EI->validateOrder(DonneIDCart($bruteVars['reference']), _PS_OS_PAYMENT_, $montant, $EI->displayName,'Transaction EI');
}elseif(strtolower($BruteVars['code-retour'])=='annulation'){
   include_once(dirname(__FILE__).'/euroinformation.php');
   $EI = new EuroInformation();
   $EI->validateOrder(DonneIDCart($bruteVars['reference']),_PS_OS_ERROR_,0 , $EI->displayName,'Transaction EI');
}

Si quelqu'un peut m'aider sur le pourquoi du comment

Merci d'avance de votre aide

ScaleDEV · January 17, 2009

Bonsoir,

J'ai fini de débugger le script de paiement complet, voici en téléchargement le module de meandmypresta modifié pour être normalement plus fontionnel.
J'ai ajouté la gestion d'un numéro unique de paiement par mysql lié avec le numéro de panier pour éviter que l'achat bug si on lance plusieurs fois le paiement par ce module avec le même panier.
Le module enregistre également le retour du paiement complet en base de donnée => je compte ajouter l'utilisation de ces données par la suite dans la commande

Merci de me donner vos retours de problèmes

Ehinarr · January 17, 2009

Vous avez répondu à votre propre question. Merci.

ScaleDEV · January 18, 2009

De rien

C'est vrai que je n'avais beaucoup de réponses donc j'ai pris le temps d'améliorer un peu le module.
J'ai également retiré un bug qui arrondissait le montant du paiement lors de la validation du paiement par le serveur de la banque sur le fichier order.php
Dans le même fichier j'ai désactivé un bout de code qui permet d'utiliser "register_global=on" par sécurité
Lorsqu'un paiement est validé, dans le détail de la commande le numéro unique de paiement apparait afin de pouvoir par exemple vérifier facilement le paiement sur la page d'administration de la banque.

daseb · February 4, 2009

Hello !

Pouvez vous me dire, s'il vous plait, comment vous avez procédé pour le paramétrage aupres de votre banque ? J'ai utilisé votre version car même problème c'est ok . Mais le lien de retour que le CIC affiche en bas de leur page "Cliquer ici pour revenir à la société XXX" renvoi vers http://www.laroutedutek.fr/my-account.php .

Alors a quoi sert Page Interface Retour :http://www.laroutedutek.fr/modules/euroinformation/order.php ?? Je ne comprends pas...

Merci bcp pour votre aide !!

ScaleDEV · February 4, 2009

l'interface retour sert à votre banque pour vous donner le résultat du paiement
il faut donner cette adresse à votre banque

daseb · February 4, 2009

Merci bien, je comprends mais je leur ai donné les 3 : page retour, url ok url non ok. Je me demande s'ils non pas utiliser seulement les 2 dernieres.

Dites moi si je me trompe : lors du paiement validé par le cic je dois donc avoir en bas leur lien avec la page retour http://www.laroutedutek.fr/modules/euroinformation/order.phpalors ? et cela doit me renvoyer vers url ok ou non ok selon la validation ?

la page de retour prend donc en compte le resultat;de paiement c'est ca ? il y a passage de variable a cette page de la part du cic?

Car si je tape l'url directement à partir de la page de paiement CIC lorsque la transaction est validée, je n'affiche qu'une page blanche avec : Pragma: no-cache Content-type: text/plain Version: 1 Document Falsifie 0--6103739+++++1.2open++

Comment la procédure s'est passée concretement chez vous lors de vos tests ??

Merci beaucoup pour votre aide.

ScaleDEV · February 4, 2009

Tout d'abord vous devez paramétrer l'application à l'aide de votre fichier .key donné par votre banque

Ensuite vous ne devez pas leur donner les 3 urls ça ne sert à rien ...

Dites leur qu'il faut utiliser l'adresse suivante comme CGI2 :
http://www.laroutedutek.fr/modules/euroinformation/order.php

Cette URL ne doit jamais être utilisée manuellement car elle permet de vérifier que les données n'ont pas été piratées entre temps et en même temps elle permet la validation du panier de votre client.

Dans l'administration du module, pensez également à rester en "TEST" tant que vos tests ne seront pas OK avec la banque.

daseb · February 6, 2009

thanx ! bon ca à l'air de fonctionner, tout est pris en compte chez cic et dans prestashop.

Seul hic c'est que sur le lien de retour OK, le client arrive sur sa page de compte, et peux visualiser ses commandes, mais il ne reçoit pas de mail automatique qui confirme sa commande...

J'ai testé rdcupération de mot de passe, message a envoyer au client via sa fiche de commande, tout marche, la fonction mail fonctionne donc, le mail est bien envoyé et recu.

Mais pas de reception de mail de confirmation lors d'une commande... alors que je vois bien " (2009-02-06 16:05:29) [Privé]: Paiement No 4" dnas les messages envoyé au client ...

AVez-vous eu ce probleme ?

daseb · February 6, 2009

bon bizzare , c'est apres plusieurs tests d'achats que tout d'un coup ca s'est mis à marcher .... j'ai rien compris ...

ScaleDEV · February 9, 2009

salut
certainement un problème de ton serveur smtp ...

doudom · February 13, 2009

Bonjour,

Tout d'abord merci pour ce module, je me permets de réactiver ce post.

J'ai effectué l'installation du module et celui m'indique paiement OK et validé, mais par contre CGI NOT OK, ci dessous l'erreur.

Erreur 0

REPONSE DE VOTRE CGI DE CONFIRMATION :

Parse error: syntax error, unexpected $end in /homez.116/XXXXXXX/www/tools/swift/Swift/BatchMailer.php on line 218

merci pour votre aide

ScaleDEV · February 13, 2009

Bonjour

A mon avis il faudrait regarder à la ligne 218 du fichier annoncé pour voir ce qui ne va pas mais il ne fait pas parti du module

doudom · February 13, 2009

Merci pour la reponse rapide

ci dessous la fin du fichier incriminé, sachant que c'est celui d'origine

$this->restoreMessageHeaders($message);
if (($max = $this->getMaxSuccessiveFailures())
&& $successive_fails > $max)
{
throw new Exception(
"Too many successive failures. BatchMailer is configured to allow no more than " . $max .
" successive failures.");
}
//If

doudom · February 13, 2009

Apparement lorsque j'effectue une commande, je ne recois pas de mail de confirmation, c'est peut etre lié ?

doudom · February 13, 2009

Je confirme c'est un probleme mail.

J'ai essayé via contact de m'envoyer un mail et j'ai la meme erreur

Parse error: syntax error, unexpected $end in /homez.116/XXXXX/www/tools/swift/Swift/BatchMailer.php on line 219

Quelqu'un peut m'aider ?

ScaleDEV · February 13, 2009

A mon avis poste un nouveau sujet concernant ton problème sur le forum ...

doudom · February 13, 2009

Merci de ton aide c'est ce que j'ai fait ;-)

guyk · February 25, 2009

si vous recevez "Invalid REQUEST_METHOD (not GET, not POST)."
c'est que votre php5 est strict et que le code order.php cic est vieux,
il faut remplacer

$stub_method = $HTTP_SERVER_VARS["REQUEST_METHOD"]; if (($stub_method == "GET") or ($stub_method == "POST")) { $wstub_order = "HTTP_" . $stub_method . "_VARS"; $stub_order = ${$wstub_order}; } else die ('Invalid REQUEST_METHOD (not GET, not POST).');

par

$reqMethod = $_SERVER["REQUEST_METHOD"];//gk if (($reqMethod == "GET") or ($reqMethod == "POST")) { $wstub_order = "_" . $stub_method; $bruteVars = ${$wbruteVars}; }

oups au temps pour moi c'est déjà bon dans le zip de la bonne version à jour

elric · March 12, 2009

Bonjour,
je viens d'avoir un panier vide, exactement comme dans ce thread http://www.prestashop.com/forums/viewthread/11742.
Le paiement est validé, le client débité mais aucune trace de la commande .
Elle apparait juste dans les stats ( table ps_order) mais pas dans ps_order_detail.

La seule alerte est un message dans le mail du CIC sur le CGI2 not OK.

Cela c'est produit pour un client,pour les autres tout fonctionne niveau CGI2.

Après vérification dans les logs, le serveur du CIC a renvoyer deux fois l'acquittement durant cette commande:

145.226.65.30 - - [11/Mar/2009:19:32:29 +0100] "POST /xxxxxxxxxxxx/order.php HTTP/1.0" 200 87 "-" "SPM"
145.226.65.30 - - [11/Mar/2009:19:32:31 +0100] "POST /xxxxxxxxxxxx/order.php HTTP/1.0" 200 48 "-" "SPM"

Quelqu'un voit d'où cela peut venir ?

Merci d'avance,

ScaleDEV · March 12, 2009

si ça fonctionne pour les autres c'est surement quelqu'un qui a essayé de payer moins cher ...

Enfin je dis ça sans savoir, mais si le CGI2 répond NOT OK pour une seule commande c'est normalement du à une tentative de fraude.

Afin d'éviter ce genre de problème, je vais faire en sorte que le order.php enregistre la commande dans tous les cas mais en marquant la commande avec erreur de paiement si echec par exemple.
Au moins on aura dans tous les cas une trace écrite de la commande

micm · March 12, 2009

si ça fonctionne pour les autres c'est surement quelqu'un qui a essayé de payer moins cher ...

Enfin je dis ça sans savoir, mais si le CGI2 répond NOT OK pour une seule commande c'est normalement du à une tentative de fraude.

Afin d'éviter ce genre de problème, je vais faire en sorte que le order.php enregistre la commande dans tous les cas mais en marquant la commande avec erreur de paiement si echec par exemple.
Au moins on aura dans tous les cas une trace écrite de la commande

excellent ;-)

elric · March 12, 2009

Nickel,

merci mdi51 c'est parfait , ça évite de demander à la cliente ce qu'elle a commandé ...

Par contre ce qui est bizarre c'est que j'ai bien reçu le mail du CIC avec le bon montant ....

Votre CGI 2 a un accuse de reception invalide
et la commande a ete VALIDEE
-------------------------------------------------------
Numero de TPE commercant : 673992
Date du paiement : 2009-03-11 à 19:30:12
Reference du paiement : 37
Montant du paiement : 59.24 EUR
Descriptif du paiement : Commande

Donc la tentative de fraude me semble exclue , c'est le bon montant ...

ROSE · April 8, 2009

Bonjour,

Merci encore à mdi51 pour son aide par MP...

Je viens d'avoir un paiement avec une cliente qui s'était trompé dans la saisie de sa date de carte.

J'ai donc reçue le message suivant de CM-CIC :

Bonjour,

Nous vous informons que votre interface retour a emis un accuse de reception INVALIDE et la commande a ete REFUSEE.
etc....

La client a immédiatement corrigé son erreur, j'ai donc reçue le nouveau message suivant :

Bonjour,

Nous vous informons que votre interface retour a emis un accuse de reception INVALIDE et la commande a ete VALIDEE.
etc....

Dans mon panneau d'administration, j'ai le message qui indique que la commande n'a pas été payée,

Et la cliente à je suppose reçue un message indiquant que sa commande n'était pas payé, alors qu'elle a eu la confirmation de paiement de la banque.

Enfin, l'argent est bien arrivé sur mon compte et l'écriture du paiement figure bien comme payée sur mon tableau de bord du CIC.

Avez-Vous les mêmes problèmes, ou avez vous déja apportée une solution à ce problème.

Merci de votre aide.
Rose

Ast2001 · April 12, 2009

Bonsoir Rose,

Pour comprendre quelle est l'erreur exacte, il faudrait regarder

a) les messages envoyés par la banque (tu es toujours en mode test ? Les messages sont plus complets)
les logs d'erreur de ton hébergeur.

Le fait que le fichier order.php ait émis une demande invalide, peut provenir de plein de raisons. Certainement pas d'une tentative de fraude je pense :-)

Dans mon cas, il s'agissait d'une erreur de droit sur les répertoires du module de paiement. Je l'ai vu en regardant les messages d'erreur dans le log:

[sun Apr 12 23:39:12 2009] [error] [client xx.xx.xx.xx] [host www.sakapuce.fr] suexec policy violation: see suexec log for more details
[sun Apr 12 23:39:12 2009] [error] [client xx.xx.xx.xx] [host www.sakapuce.fr] Premature end of script headers: order.php

Un petit chmod 755 sur le dossier (qui était en 777 ce que n'aime pas OVH mon hébergeur) et ça roule :-)

Merci aussi à mdi51 pour ce module. J'avais bricolé (corrigé des bugs) dans le module founi sur le site creezvotre.com mais je me suis trouvé face au problème du client qui a eu sa carte refusé et qui ne peut plus passer commande car le n° de transaction ne change pas (normal, c'était le n° de panier :-) )

Avec le module de mdi51, plus de soucis de ce côté. Bravo et merci.

ROSE · April 13, 2009

Bonjour,

Merci de me répondre.

Je suis en production.

Les deux messages que j'ai donnés ci-dessus sont des extraits des messages envoyés par la banque.

Je connais l'origine du problème j'ai eu la cliente au téléphone :

C'est simplement la client qui s'est trompée en indiquant la date de sa carte bancaire, la carte a donc bien été refusée par la banque et la commande de la cliente a bien été mise à jour sur ma boutique avec le message en rouge "attention 0 euros encaissé ..."

Sans quitter le module de paiement, la cliente a re-saisie sa carte bancaire. Cette fois, le paiement a été accepté par la banque. La banque a envoyé son message de contrôle à ma boutique, qui a répondu négativement , puisque le panier et la commande de la cliente avait déja été contrôlé et modifié dans ma boutique.

En conclusion :

- La cliente est bien débitée
- J'ai bien reçue l'argent sur mon compte
- Mais la commande de la cliente dans la boutique apparait comme impayée
- Et elle a du recevoir un message pour une commande non validé.

Merci de votre aide
Rose

Ast2001 · April 13, 2009

Bonjour,

Le soucis vient du fait que votre site a répondu INVALIDE. Du coup, tout le process au niveau de Prestashop n'a pas enregistré la commande.

Il faut donc comprendre pourquoi cette réponse INVALIDE a été émise.

Il y a donc un problème dans l'installation du module euroinformation qu'il faut localiser.

Le mieux est de repasser momentanément en mode test, de faire une commande bidon et de nous donner les détails du mail envoyé par la banque.

Dans le cas où il n'est pas possible de repasser en mode test, il faudrait fournir les logs d'erreur du site. Ces infos doivent être récupérable sur la console d'administration de l'hébergeur.

ROSE · April 13, 2009

Bonjour,

Ci-joint l'extrait de `ps_euroinfo_detailpayment`dans ma base.

Je ne sais pas si c'est ce que tu souhaitais.

L'id 7 est l'erreur de paiement
L'id 8 est la nouvelle carte saisie
L'id 9 est une autre commande OK

id_payment mac tpe date montant texte_libre code_retour retourPLUS

7 077D39610A42AC6F94C6A1B381CDA0CEB2AAAAA 6000000 08/04/2009_a_13:42:33 25.90EUR Commande Annulation --cvxoui

0

9 3EB8F484C3D23CE73A6E20008A2566A8B9AAAAAA 6000000 10/04/2009_a_11:01:54 21EUR Commande paiement --cvxoui

Merci
Rose

Ast2001 · April 13, 2009

Rose,

Non, ce n'est pas ce que je voulais mais cela donne des indices. En effet, le fichier Order.php a bien été appelé (sinon tu n'aurais aucune ligne dans cette table).

Par contre, le 'retour plus' ne va pas.

Il manque un truc après le "--cvxoui"...

As-tu la possibilité de passer en mode test et de simuler une commande ?

ROSE · April 13, 2009

Merci de ton aide.

Je me suis mis en mode test.

Et j'ai fais deux tests différents, le premier avec une erreur de saisie de carte puis la correction dans une nouvelle saisie, et le deuxième avec une bonne saisie de carte directement.

1/ premier test saisie de carte refusée, puis nouvelle saisie cette fois bonne du client, les messages sont les suivants :

Bonjour,

Nous vous informons que votre interface de retour a emis un accuse de reception VALIDE et la commande a ete REFUSEE.

RECAPITULATIF DU PAIMENT :

Numero de TPE commercant : 1200000
Date du paiement : 2009-04-13 a 16:16:49
Reference du paiement : 12
Montant du paiement : 15 EUR
Descriptif du paiement : Commande

Vous trouverez ci-dessous les informations relatives a la requete emise par notre serveur ainsi que l'accuse de reception envoye par votre interface de retour.

REQUETE EMISE PAR NOTRE SERVEUR :http://www.monsite.com:80/modules/euroinformation/order.php?TPE=1200000&date=13/04/2009_a_16:17:14&montant=15EUR&reference=12&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=Annulation&retourPLUS;=--cvxoui--3DveN--3DpaN
Methode retenue : POST
TPE : 1200000
Host appele : www.monsite.com
Port : 80
CGI appele : /modules/euroinformation/order.php
Requete emise : TPE=1200000&date=13/04/2009_a_16:17:14&montant=15EUR&reference=12&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=Annulation&retourPLUS;=--cvxoui--3DveN--3DpaN

Erreur 0

REPONSE DE VOTRE CGI DE CONFIRMATION :
Pragma: no-cache
Content-type: text/plain
Version: 1 OK

Cordialement,

CM-CIC paiement
Euro Information / Commerce Electronique,

Puis

Bonjour,

Nous vous informons que votre interface de retour a emis un accuse de reception INVALIDE et la commande a ete VALIDEE.

RECAPITULATIF DU PAIMENT :

Numero de TPE commercant : 1200000
Date du paiement : 2009-04-13 a 16:16:49
Reference du paiement : 12
Montant du paiement : 15 EUR
Descriptif du paiement : Commande

Vous trouverez ci-dessous les informations relatives a la requete emise par notre serveur ainsi que l'accuse de reception envoye par votre interface de retour.

NB : Un accuse de reception invalide n'a aucune incidence sur le paiement. Vous pouvez vous connecter a votre tableau de bord pour consulter l'etat de la commande.

REQUETE EMISE PAR NOTRE SERVEUR :http://www.monsite.com:80/modules/euroinformation/order.php?TPE=6400000&date=13/04/2009_a_16:17:59&montant=15EUR&reference=12&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN
Methode retenue : POST
TPE : 1200000
Host appele : www.monsite.com
Port : 80
CGI appele : /modules/euroinformation/order.php
Requete emise : TPE=1200000&date=13/04/2009_a_16:17:59&montant=15EUR&reference=12&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN

Erreur 0

REPONSE DE VOTRE CGI DE CONFIRMATION :
An order has already been placed using this cart

Cordialement,

CM-CIC paiement
Euro Information / Commerce Electronique,

2/ Deuxième test réalisé avec une carte acceptée directement :

Bonjour,

Nous vous informons que votre interface de retour a emis un accuse de reception VALIDE et la commande a ete VALIDEE.

RECAPITULATIF DU PAIMENT :

Numero de TPE commercant : 1200000
Date du paiement : 2009-04-13 a 16:24:29
Reference du paiement : 14
Montant du paiement : 15 EUR
Descriptif du paiement : Commande

Vous trouverez ci-dessous les informations relatives a la requete emise par notre serveur ainsi que l'accuse de reception envoye par votre interface de retour.

REQUETE EMISE PAR NOTRE SERVEUR :http://www.monsite.com:80/modules/euroinformation/order.php?TPE=1200000&date=13/04/2009_a_16:24:38&montant=15EUR&reference=14&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN
Methode retenue : POST
TPE : 1200000
Host appele : www.monsite.com
Port : 80
CGI appele : /modules/euroinformation/order.php
Requete emise : TPE=1200000&date=13/04/2009_a_16:24:38&montant=15EUR&reference=14&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN

Erreur 0

REPONSE DE VOTRE CGI DE CONFIRMATION :
Pragma: no-cache
Content-type: text/plain
Version: 1 OK

Cordialement,

CM-CIC paiement
Euro Information / Commerce Electronique,

Merci
Rose

Ast2001 · April 13, 2009

Dans ce que tu viens d'envoyer, tout est bon !!!!

Le réponse est valide. D'ailleurs, si tu regardes dans la base tu devrais voir des "cvxoui—3DveN—3DpaN" et pas seulment des "cvxoui--"

Alors quid ?

Ca ne fonctionne correctement qu'en mode test ?

ROSE · April 13, 2009

Merci de ta réponse.

Non dans le premier test, tout n'est pas bon du coté de ma boutique et du mail envoyé au client.

Le client reçoit le message suivant alors que sa carte a bien été encaissé après la resaisie :

Bonjour XXXXX JEAN-MARC,

Statut de votre commande n°90025

Une erreur est survenue lors du paiement de votre commande.

Vous pouvez accéder au suivi de votre commande et télécharger votre facture dans "Historique des commandes" de la rubrique "Mon compte" sur notre site.

Et dans ma boutique, la commande apparait en erreur, alors que le client a bien été débité, cf l' aperçu d'écran suivant :

http://img140.imageshack.us/img140/803/test1c.jpg

Tu as testé chez toi si le client se troppe et resaisi ensuite la bonne carte si tout fonctionne bien ?

Merci
Rose

Buzby · April 13, 2009

Bonsoir,

J'aimerais savoir pourquoi après avoir installer le module et en ayant juste validé lec condtions et choisi test credit mutuel et qd je veux simuler un paiement ca me dit ca :

Le site de votre commerçant n'a pas été identifié par notre serveur.
Nous ne sommes pas en mesure de traiter la demande de paiement
relative à votre commande.

Comment je peux faire pour que ca marche?

Ast2001 · April 14, 2009

J'aimerais savoir pourquoi après avoir installer le module et en ayant juste validé lec condtions et choisi test credit mutuel et qd je veux simuler un paiement ca me dit ca :

Le site de votre commerçant n'a pas été identifié par notre serveur.
Nous ne sommes pas en mesure de traiter la demande de paiement
relative à votre commande.

Comment je peux faire pour que ca marche?

Tu es inscrit auprès du Crédit Mutuel ? Tu as fait toutes les manipulations de génération de clé etc... ?

Ast2001 · April 14, 2009

Non dans le premier test, tout n'est pas bon du coté de ma boutique et du mail envoyé au client.

Le client reçoit le message suivant alors que sa carte a bien été encaissé après la resaisie :

Bonjour XXXXX JEAN-MARC,

Statut de votre commande n°90025

Une erreur est survenue lors du paiement de votre commande.

Vous pouvez accéder au suivi de votre commande et télécharger votre facture dans "Historique des commandes" de la rubrique "Mon compte" sur notre site.

Et dans ma boutique, la commande apparait en erreur, alors que le client a bien été débité, cf l' aperçu d'écran suivant :

http://img140.imageshack.us/img140/803/test1c.jpg

Tu as testé chez toi si le client se troppe et resaisi ensuite la bonne carte si tout fonctionne bien ?

Merci
Rose

Il me semble que je l'ai fait dans mes tests l'autre jour.

Dans ton cas, le système répond "An order has already been placed using this cart" signifiant qu'une commande a déjà été validée pour ce panier. Je ne sais pas pourquoi.

ROSE · April 14, 2009

Bonjour, merci de ta réponse

Je pense que c'est normal que le panier soit validé dès le premier essai de saisie de la carte bancaire.

Ce qui me surpprend c'est que tu n'ai pas le même problème.

Tu peux m'envoyer par mail les deux fichiers suivant du module STP :

euroinformation.php
order.php

Merci Rose

Ast2001 · April 16, 2009

Bonjour Rose,

Mes fichiers sont ceux du ZIP ;-)

ROSE · April 16, 2009

Bonjour,

Moi aussi, ce sont donc les même, je ne comprends pas pourquoi tu n'a pas le même problème.

Merci
Rose

blasto · May 12, 2009

Bonjour,

A qu'elle adresse je pourrait télécharger ce module "gratuit" sans bugs ?

Merci !

Ast2001 · May 12, 2009

Regarde tous les messages de ce thread et tu trouveras le ZIP que tu cherches.

blasto · May 12, 2009

Je pensais que cette version était encore buggée vu les posts suivants le post contenant le fichier .

Ast2001 · May 12, 2009

Visiblement, ça dépend pour qui. Dans le cas de la boutique de mon épouse. Cela fonctionne. Ou tout au moins, nous n'avons pas rencontré de problème pour les commandes passées depuis l'installation de ce module.

Odjavel · May 12, 2009

Pour moi, ce module fonctionne aussi sans modification.

Toutefois, petite question : vous utilisez quoi comme page de retour après le paiement ?
Moi ça reviens sur history.php. Je n'ai pas réussi à faire une réelle page "Votre paiement a bien été accepté".

ROSE · May 13, 2009

Bonjour,

Les Urls de retours sont les suivantes :

Page Interface Retour :
http://www.monsite.com/order.php

Url paiement OK :
http://www.monsite.com/my-account.php

Url paiement Non OK :
http://www.monsite.com/order.php

Le module de paiement fonctionne très bien.

Il y a seulement un Bug lorsque le client se trompe lors de la saisie de sa carte et qu'il effectue sa saisie une deuxième fois.

Bien entendu, si aucun de vos clients ne c'est trompé lors de la saisie du code, vous ne pouvez pas avoir eu de problème !!!

Il suffit de faire un essai en mode test...

Merci
Rose

Ast2001 · May 14, 2009

J'ai trouvé un autre bug dans le module EuroInformation.

En effet, il ne gère pas les bons de réduction quel que soit leur type (montant, % ou frais de port). On se retrouve sur la page de paiement du Crédit Mutuel avec le montant global sans tenir compte d'un éventuel bon.

Le problème se situe ici (lignes 799 à 801 du fichier euroinformation.php):

$MyTpe["montant"]      = number_format(Tools::convertPrice($params['cart']->getOrderTotal(true, 4), $currency), 2, '.', '');
$shipping              =  number_format(Tools::convertPrice($params['cart']->getOrderShippingCost(), $currency), 2, '.', '');
$MyTpe["montant"]      = $MyTpe["montant"]+$shipping;

Il faut remplacer ces trois lignes par la suivante:

$MyTpe["montant"]      = number_format(Tools::convertPrice($params['cart']->getOrderTotal(true, 3), $currency), 2, '.', '');

Notez bien le getOrderTotal(true, 3) à la place de getOrderTotal(true, 4)

Michel.

ROSE · May 14, 2009

Bonsoir,

Bien vu !

C'est vrai que j'ai relevé également un bug sur la gestion des paquets cadeaux qui n'est pas prise en charge non plus.

Je me suis contenté de mettre en veille ce service car ce n'était pas très important.

Je regarderais demain.

Merci
Rose

Ast2001 · May 14, 2009

Il n'est pas impossible d'imaginer que ma correction règle aussi le problème des paquets cadeaux ;-)

blasto · May 18, 2009

Bonjour,

Je suis en phase de test pour le paiement en ligne avec le module EI pour cybermut.
Les produits sont renseignés comme suit :

- quantité : 0
- accepter les comandes

Le panier indique bien que le produit est disponible mais après paiement sur la plateforme, la commande indique
“ Produit(s) indisponibles “ et un mail est envoyé au client comm "produit indisponible" …

Bug ?
Comment le résoudre svp ?

Ast2001 · May 18, 2009

Je n'ai pas tout à fait compris mais pour moi, c'est normal et cela n'a rien à voir avec le module. Tu dis que tu n'as pas un produit en stock mais que tu acceptes néanmoins les commandes sur ce produit. Le comportement de PS me semble logique.

Il indique que le produit est indisponible.

blasto · May 18, 2009

Arf ...
Oui .. où j'avais le tête ...

Ast2001 · May 31, 2009

Merci de ta réponse.

Non dans le premier test, tout n'est pas bon du coté de ma boutique et du mail envoyé au client.

Le client reçoit le message suivant alors que sa carte a bien été encaissé après la resaisie :

Bonjour XXXXX JEAN-MARC,

Statut de votre commande n°90025

Une erreur est survenue lors du paiement de votre commande.

Vous pouvez accéder au suivi de votre commande et télécharger votre facture dans "Historique des commandes" de la rubrique "Mon compte" sur notre site.

Et dans ma boutique, la commande apparait en erreur, alors que le client a bien été débité, cf l' aperçu d'écran suivant :

http://img140.imageshack.us/img140/803/test1c.jpg

Tu as testé chez toi si le client se troppe et resaisi ensuite la bonne carte si tout fonctionne bien ?

Merci
Rose

Bon, nous venons d'avoir le même pb. Bouh.

Une carte refusée puis validée et le système refuse d'accepter la deuxième.

Il va falloir que je passe encore du temps dessus pour comprendre ce qui se passe.

Ast2001 · June 5, 2009

Dans le code du fichier order.php (ligne 194), il faut faire le changement suivant:

if( strtolower($bruteVars['code-retour']=='payetest') || strtolower($bruteVars['code-retour'])=='paiement'){

par

if( strtolower($bruteVars['code-retour'])=='payetest' || strtolower($bruteVars['code-retour'])=='paiement'){

Une parenthèse est mal placée et empêche d'utiliser correctement le mode test

Il y a aussi deux include_once qui ne sont pas très heureux je trouve.

// Validation et enregistrement de la commande //
if( strtolower($bruteVars['code-retour'])=='payetest' || strtolower($bruteVars['code-retour'])=='paiement'){
   include_once(dirname(__FILE__).'/cybermut.php');
   $EI = new Cybermut();
   $montant = number_format($bruteVars['montant'], 2, '.', '');
   $EI->validateOrder($idcartrecup, _PS_OS_PAYMENT_, $montant, $EI->displayName,'Paiement No '.intval($bruteVars['reference']));
}elseif(strtolower($bruteVars['code-retour'])=='annulation'){
   include_once(dirname(__FILE__).'/cybermut.php');
   $EI = new Cybermut();
   $EI->validateOrder($idcartrecup,_PS_OS_ERROR_,0 , $EI->displayName,'Paiement No '.intval($bruteVars['reference']));
}
///////////////////////////////////////////////////

jysfree · August 17, 2009

Bonjour,
J'utilise ce module pour le paiement CB via le CIC.
Le CIC permet aujourd'hui de faire du paiement fractionné jusqu'a 4 traite mensuelle.
il faurt pour cela modifier le module Euroinformation.
N'ayant pas la connaissance suffisante pour modifier ce dernier j'en appelle a votre aide, si quelqun a une idée, ou l'a deja fait
Merci en core

blasto · August 20, 2009

Bonjour,

J'ai un soucie avec le module.

Je suis en mod TEST avec banque CIC.

Les paiement sont validés mais je ne reçois pas le retour sur la boutique, enfin à part si la carte est refusée (Erreur de paiement).

Voici le retour :
--------------------------

Bonjour,

Nous vous informons que votre interface de retour a emis un accuse de reception INVALIDE et la commande a ete VALIDEE.

RECAPITULATIF DU PAIMENT :

Numero de TPE commercant : XXXXXXX
Date du paiement : 2009-08-20 a 10:49:33
Reference du paiement : 5
Montant du paiement : 15.49 EUR
Descriptif du paiement : Commande

Vous trouverez ci-dessous les informations relatives a la requete emise par notre serveur ainsi que l'accuse de reception envoye par votre interface de retour.

NB : Un accuse de reception invalide n'a aucune incidence sur le paiement. Vous pouvez vous connecter a votre tableau de bord pour consulter l'etat de la commande.

REQUETE EMISE PAR NOTRE SERVEUR :http://www.XXXXXXXXXXXX.fr:80/modules/euroinformation/order.php?TPE=XXXXXXX&date=20/08/2009_a_10:49:50&montant=15.49EUR&reference=5&MAC=F02FC7980CADC84267B14B70C6C7DBF046B5488&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN
Methode retenue : POST
TPE : XXXXXXX
Host appele : www.XXXXXXXXXXXX.fr
Port : 80
CGI appele : /modules/euroinformation/order.php
Requete emise : TPE=XXXXXXX&date=20/08/2009_a_10:49:50&montant=15.49EUR&reference=5&MAC=F02FC7980CAA47DC84267B14B70C6C7DBF046B5488&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN

Erreur 0

REPONSE DE VOTRE CGI DE CONFIRMATION :

Cordialement,

CM-CIC paiement

----------------------------

J'ai fais tous les tests avec les CB, je n'ai pas un seul CGI2 OK ... :/

Je suis chez OVH. J'ai vérifier les droits du dossier (705), j'ai testé en 755; c'est la même chose ...
J'ai vérifier s'il y avait des erreurs dans les logs du serveur. Il n'y a rien ...
J'ai fais les correction indiquées par Ast2001 en fin de topic, sur le fichier order.php .
Toujours rien de changé ...

Une idée svp ?

jeckyl · August 20, 2009

Bonjour,
J'utilise ce module pour le paiement CB via le CIC.
Le CIC permet aujourd'hui de faire du paiement fractionné jusqu'a 4 traite mensuelle.
il faurt pour cela modifier le module Euroinformation.
N'ayant pas la connaissance suffisante pour modifier ce dernier j'en appelle a votre aide, si quelqun a une idée, ou l'a deja fait
Merci en core

+1

Ast2001 · August 20, 2009

Tu as bien regardé les logs CGI ?

Tu vois l'appel de la page order.php ?

Il faut bien mettre 755 sur le dossier et les fichiers euroinformation

jysfree · August 20, 2009

jeckyl

bonjour,
as tu une reponse???
ou as tu le meme probleme????

jeckyl · August 20, 2009

jeckyl

bonjour,
as tu une reponse???
ou as tu le meme probleme????

Mêmes attentes.

J'avais pauser la question sur prestastore, tu paux d'ailleurs aller voire la réponse.

blasto · August 20, 2009

Alors je voulais faire la modif concernant le CHMOD sur les fichiers puis tester mais voilà, maintenant je me retrouve avec autre chose ... :/

Le message suivant sur la page de paiement.cgi du CIC :

La date de validité de votre commande est dépassée. Notre serveur n'est pas en mesure de traiter la demande de paiement relative à votre commande

J'ai appelé et apparement cela viendrait d'une mauvaise syntaxe du formulaire de commande (à ce qu'ils m'ont dit) mais voila je n'ai strictement rien touché :/

En voyant "date de validité de votre commande" j'ai pensé à un paramètre lié à la date du panier; j'ai donc supprimé tout le cache du browser mais rien a changé ...

Une idée svp ?

Je viens de penser à une chose, la boutique tourne avec la version 1.0 de prestashop; est-ce que cela pourrait venir de là ? Une idée avant que je passe du temps à faire toute la mise à jour svp ?

nautilebleu · August 26, 2009

Bonjour,

Je me permet d'ajouter mon problème à ce fil de discussion dédié au module euroinformation.

Mon problème est le suivant: jusqu'à il y a quelques jours, lorsqu'un client payait avec le module euroinformation, le retour se faisait vers la page http://domain.com/my-account.php

Nous avions alors des messages de la part d'euroinformation de ce type:

Nous vous informons que votre interface retour a emis un accuse de
reception INVALIDE et la commande a ete VALIDEE.

Pourtant le module de Prestashop était paramêtré avec les URLs de retour suivantes:

Page Interface Retour :
http://domain.com/modules/euroinformation/order.php

Url paiement OK :
http://domain.com/my-account.php

Url paiement Non OK :
http://domain.com/order.php

Je leur ai demandé d'utiliser l'adresse de la page interface de retour. Nouveau test ce matin: pour le TPE tout se passe bien, mais je ne vois pas dans la commande dans l'admin Prestashop ?

Avez-vous une idée du problème ?

Goulwen

Raph59 · August 26, 2009

édité pour éviter d'induire une personne en erreur

Bon en revanche je dit ca par "déduction", car je n'ai pas encore installé ce module, mais c'est prévu pour cette semaine ou la semaine prochaine

nautilebleu · August 26, 2009

la page url paiement OK et Non OK ne devrais pas être

http://domain.com/order-confirmation.php

?

Peut être. Tiens moi au courant quand tu auras tenté l'installation !

Ce qui m'embête c'est que les paramètres que j'utilise sont ceux par défaut dans la configuration du module (et d'ailleurs, on ne peut les changer.) C'est donc bizarre qu'ils ne soient pas bons, ou alors tout le monde devrait avoir le problème.

Goulwen

Ast2001 · August 26, 2009

la page url paiement OK et Non OK ne devrais pas être

http://domain.com/order-confirmation.php

?

Bon en revanche je dit ca par "déduction", car je n'ai pas encore installé ce module, mais c'est prévu pour cette semaine ou la semaine prochaine

Non. Les deux URL sont bonnes.

Ok -> On revient sur la page mon compte pour suivre la commande

NOk -> On reste dans le processus de commande pour éventuellement retenter

Raph59 · August 26, 2009

post édité pour éviter d'induire en erreur alors

nautilebleu · August 26, 2009

Donc il faut bien conserver les 3 urls telles qu'elles ?

L'url vers laquelle euroinformation doit retourner une fois le paiement OK est laquelle alors ?

Page Interface Retour :
http://domain.com/modules/euroinformation/order.php

ou

Url paiement OK :
http://domain.com/my-account.php

Si c'est my-account.php, pourquoi euroinformation émet une alerte ? Si c'est euroinformation/order.php, pourquoi les commandes ne sont-elles pas ajoutées ?

Goulwen

Ast2001 · August 26, 2009

L'alerte provient du fait qu'il y a eu un problème dans .../euroinformation/order.php . Je ne connais pas la nature du problème mais c'est dans cette unité (appelée par le site du CM) que la commande est ajoutée si tout se passe bien.

Après, les deux pages .../order.php et .../my-accountphp sont deux pages standards de Prestashop non directement liée au module euroinformation.

deknek · August 26, 2009

Hello

Je suis en train d'essayer de brancher un paiement euroinformation sur mon prestashop, et j'ai un soucis. je ne sait pas si ca vient du code ou si je doit contacter l'assistance technique CIC.

Pendant la configuration, je saisit le contenu du xxxxxxx.key que j'ai téléchargé avec les infos de la banque, ensuite je saisit le TPE, et la ca coince, j'ai une alerte avec le message suivant :

Erreur : Clef pour Hmac-MD5 !

quelqu'un aurait une idée ?

Merci

nautilebleu · August 27, 2009

L'alerte provient du fait qu'il y a eu un problème dans .../euroinformation/order.php . Je ne connais pas la nature du problème mais c'est dans cette unité (appelée par le site du CM) que la commande est ajoutée si tout se passe bien.

OK le problème est qu'il n'y a pas d'alerte, justement. Il y avait une alerte lorsque le retour se faisait sur ../my-account.php. Maintenant pour euroinformation, tout est OK, mais je n'ai pas pour autant la commande. Va falloir que je débug, sauf que du coup, ça ne peut se faire que sur le serveur en prod, vu que c'est le retour depuis le TPE qui ne marche pas.

Après, les deux pages .../order.php et .../my-accountphp sont deux pages standards de Prestashop non directement liée au module euroinformation.

Quel est le rôle de la page retour OK alors ? retour KO je comprend bien, mais si un retour qui se passe bien doit renvoyer vers euroinformation/order.php, à quoi sert retour OK vers my-account.php ?

Ast2001 · August 27, 2009

L'alerte provient du fait qu'il y a eu un problème dans .../euroinformation/order.php . Je ne connais pas la nature du problème mais c'est dans cette unité (appelée par le site du CM) que la commande est ajoutée si tout se passe bien.

OK le problème est qu'il n'y a pas d'alerte, justement. Il y avait une alerte lorsque le retour se faisait sur ../my-account.php. Maintenant pour euroinformation, tout est OK, mais je n'ai pas pour autant la commande. Va falloir que je débug, sauf que du coup, ça ne peut se faire que sur le serveur en prod, vu que c'est le retour depuis le TPE qui ne marche pas.

Attends, tu es bien en mode test ?

Tu dois normalement recevoir un mail qui te donne tous les éléments de la transaction, qu'elle se soit bien ou mal déroulée. Que veux-tu dire par "il n'y a pas d'alerte" ?

Et les tests effectivement ne peuvent se faire que sur le site de prob avec la boutique non ouverte.

Tu ne peux pas faire les tests sur un site local par exemple et partir du principe que ça marchera en prod.

Après, les deux pages .../order.php et .../my-accountphp sont deux pages standards de Prestashop non directement liée au module euroinformation.

Quel est le rôle de la page retour OK alors ? retour KO je comprend bien, mais si un retour qui se passe bien doit renvoyer vers euroinformation/order.php, à quoi sert retour OK vers my-account.php ?

Tu reviens vers ton compte où tu peux par exemple suivre ta commande.

nautilebleu · August 27, 2009

Attends, tu es bien en mode test ?

Tu dois normalement recevoir un mail qui te donne tous les éléments de la transaction, qu'elle se soit bien ou mal déroulée.

Non je suis en prod (enfin normalement!) Quand je parle de mail, je parle en fait du message envoyé par euroinformation aux contacts-client du TPE en cas de pb, et pas du mail envoyé par Prestashop.

Que veux-tu dire par "il n'y a pas d'alerte" ?

Auparavant, euroinformation avait paramétré le retour vers la page my-account.php. On avait alors un mail d'erreur de la part d'euroinformation comme quoi le paiement était validé mais l'accusé de réception de Prestashop était invalide. Maintenant, nous n'avons plus ce message, mais Prestashop n'affiche pas la commande dans l'admin.

Et les tests effectivement ne peuvent se faire que sur le site de prob avec la boutique non ouverte.

Tu ne peux pas faire les tests sur un site local par exemple et partir du principe que ça marchera en prod.

Le truc, c'est que la boutique a été ouverte sans le TPE (juste payement par chèque et par virement) avant que l'ajout du paiement par TPE. Je ne pouvais pas fermer la boutique à ce moment là…

Cependant, avec un dev bien fait de la part d'euroinformation, on devrait pouvoir faire le tests sur un serveur de test et mettre en prod sans avoir à galérer comme ça. Il suffirait de fournir un serveur mock qui se comporterait comme le vrai site…

Tu reviens vers ton compte où tu peux par exemple suivre ta commande.

Il y a encore quelque chose que je ne comprend pas. Deux retours OK et KO je comprend, mais le 3ème ? Ou alors, euroinformations fait un appel intermédiaire vers la page retour interface puis en fonction de la réponse, renvoi vers OK et KO ?

Ast2001 · August 27, 2009

Attends, tu es bien en mode test ?

Tu dois normalement recevoir un mail qui te donne tous les éléments de la transaction, qu'elle se soit bien ou mal déroulée.

Non je suis en prod (enfin normalement!) Quand je parle de mail, je parle en fait du message envoyé par euroinformation aux contacts-client du TPE en cas de pb, et pas du mail envoyé par Prestashop.

Si tu n'es pas en mode test, ça va être difficile voire impossible de comprendre ce qui se passe. Et je parle effectivement des mails envoyés par euroinformation qui donnent des infos complètes sur les échanges lorsqu'on est en mode test.

Et les tests effectivement ne peuvent se faire que sur le site de prob avec la boutique non ouverte.

Tu ne peux pas faire les tests sur un site local par exemple et partir du principe que ça marchera en prod.

Le truc, c'est que la boutique a été ouverte sans le TPE (juste payement par chèque et par virement) avant que l'ajout du paiement par TPE. Je ne pouvais pas fermer la boutique à ce moment là…

Cependant, avec un dev bien fait de la part d'euroinformation, on devrait pouvoir faire le tests sur un serveur de test et mettre en prod sans avoir à galérer comme ça. Il suffirait de fournir un serveur mock qui se comporterait comme le vrai site…

Je ne vois pas trop comment procéder sans suspendre momentanément la boutique et travailler le soir ou la nuit pour les tests (c'est ce que j'ai fait).

Tu reviens vers ton compte où tu peux par exemple suivre ta commande.

Il y a encore quelque chose que je ne comprend pas. Deux retours OK et KO je comprend, mais le 3ème ? Ou alors, euroinformations fait un appel intermédiaire vers la page retour interface puis en fonction de la réponse, renvoi vers OK et KO ?

Après que l'utilisateur ait saisi son numéro de carte, le crédit mutuel appelle la page ../euroinformation/order.php qui va recevoir l'info sur la carte (acceptée ou refusée) puis va mettre à jour la base de prestashop pour par exemple intégrer la commande lorsqu'elle a été acceptée. Cette page doit renvoyer Ok au serveur du crédit mutuel.

Le serveur va ensuite revenir vers ../order.php ou ../my-account.php en fonction du statut de la carte.

Tu vois, il y a DEUX order.php

Le plus important est celui du module euroinformation qui se charge de l'enregistrement de la carte.

Sinon, je pense qu'il est impossible de passer d'un serveur test à un serveur prod car l'URL est codée aussi dans la clé (à ma connaissance).

blasto · September 4, 2009

Bonjour,

J'ai fais la MAJ de la boutique vers la 1.1 final car vers la 1.2, je rencontrais trop de problèmes (j'étais sous une 1.0....).

Et maintenant hourrrrAAA !!! J'ai des CGI OK ! ^^

Mais voilà, j'ai toujours un soucie. Si un client se trompe il renvoie une erreur de paiement à la boutique ( problème cité auparavant dans les posts ). Alors j'ai réalisé les modifications ci-dessous, mais rien .. Là je n'ai que des CGI NOT OK, je suis revenu à la version précédente de ce fichier.

Dans le code du fichier order.php (ligne 194), il faut faire le changement suivant:

if( strtolower($bruteVars['code-retour']=='payetest') || strtolower($bruteVars['code-retour'])=='paiement'){

par

if( strtolower($bruteVars['code-retour'])=='payetest' || strtolower($bruteVars['code-retour'])=='paiement'){

Une parenthèse est mal placée et empêche d'utiliser correctement le mode test

Il y a aussi deux include_once qui ne sont pas très heureux je trouve.

// Validation et enregistrement de la commande //
if( strtolower($bruteVars['code-retour'])=='payetest' || strtolower($bruteVars['code-retour'])=='paiement'){
   include_once(dirname(__FILE__).'/cybermut.php');
   $EI = new Cybermut();
   $montant = number_format($bruteVars['montant'], 2, '.', '');
   $EI->validateOrder($idcartrecup, _PS_OS_PAYMENT_, $montant, $EI->displayName,'Paiement No '.intval($bruteVars['reference']));
}elseif(strtolower($bruteVars['code-retour'])=='annulation'){
   include_once(dirname(__FILE__).'/cybermut.php');
   $EI = new Cybermut();
   $EI->validateOrder($idcartrecup,_PS_OS_ERROR_,0 , $EI->displayName,'Paiement No '.intval($bruteVars['reference']));
}
///////////////////////////////////////////////////

Quelqu'un aurait-il une solution ? éxisterait-il comme sip-atos un paramètrage indiquant à la plateforme de paiement de ne pas renvoyer les "erreurs de paiement" ? cela simplifierait beaucoup de choses ...

Merci

Raph59 · September 4, 2009

Bonjour, est-ce que le problème suivant a été résolue? A savoir si un client fait un paiement, fait une erreur dans sa première saisie, puis revalide la saisie, le paiement passe à la banque, mais le client reçoit de notre part un email qui dit que son paiement a été refusé?

Car on voit clairement la cause dans le deuxième mail de ROSE qui dit que notre site a répondu

"An order has already been placed using this cart"

Ce qui signifie que le module vérifie si l'ID de paiement existe?

- Si oui, il envoie le message d'erreur "An order has already been placed using this cart" sans chercher à comprendre plus loin

- Si non, il confirme bien la commande?

Merci de ton aide.

Je me suis mis en mode test.

Et j'ai fais deux tests différents, le premier avec une erreur de saisie de carte puis la correction dans une nouvelle saisie, et le deuxième avec une bonne saisie de carte directement.

1/ premier test saisie de carte refusée, puis nouvelle saisie cette fois bonne du client, les messages sont les suivants :

Bonjour,

Nous vous informons que votre interface de retour a emis un accuse de reception VALIDE et la commande a ete REFUSEE.

RECAPITULATIF DU PAIMENT :

Numero de TPE commercant : 1200000
Date du paiement : 2009-04-13 a 16:16:49
Reference du paiement : 12
Montant du paiement : 15 EUR
Descriptif du paiement : Commande

Vous trouverez ci-dessous les informations relatives a la requete emise par notre serveur ainsi que l'accuse de reception envoye par votre interface de retour.

REQUETE EMISE PAR NOTRE SERVEUR :http://www.monsite.com:80/modules/euroinformation/order.php?TPE=1200000&date=13/04/2009_a_16:17:14&montant=15EUR&reference=12&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=Annulation&retourPLUS;=--cvxoui--3DveN--3DpaN
Methode retenue : POST
TPE : 1200000
Host appele : www.monsite.com
Port : 80
CGI appele : /modules/euroinformation/order.php
Requete emise : TPE=1200000&date=13/04/2009_a_16:17:14&montant=15EUR&reference=12&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=Annulation&retourPLUS;=--cvxoui--3DveN--3DpaN

Erreur 0

REPONSE DE VOTRE CGI DE CONFIRMATION :
Pragma: no-cache
Content-type: text/plain
Version: 1 OK

Cordialement,

CM-CIC paiement
Euro Information / Commerce Electronique,

Puis

Bonjour,

Nous vous informons que votre interface de retour a emis un accuse de reception INVALIDE et la commande a ete VALIDEE.

RECAPITULATIF DU PAIMENT :

Numero de TPE commercant : 1200000
Date du paiement : 2009-04-13 a 16:16:49
Reference du paiement : 12
Montant du paiement : 15 EUR
Descriptif du paiement : Commande

Vous trouverez ci-dessous les informations relatives a la requete emise par notre serveur ainsi que l'accuse de reception envoye par votre interface de retour.

NB : Un accuse de reception invalide n'a aucune incidence sur le paiement. Vous pouvez vous connecter a votre tableau de bord pour consulter l'etat de la commande.

REQUETE EMISE PAR NOTRE SERVEUR :http://www.monsite.com:80/modules/euroinformation/order.php?TPE=6400000&date=13/04/2009_a_16:17:59&montant=15EUR&reference=12&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN
Methode retenue : POST
TPE : 1200000
Host appele : www.monsite.com
Port : 80
CGI appele : /modules/euroinformation/order.php
Requete emise : TPE=1200000&date=13/04/2009_a_16:17:59&montant=15EUR&reference=12&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN

Erreur 0

REPONSE DE VOTRE CGI DE CONFIRMATION :
An order has already been placed using this cart

Cordialement,

CM-CIC paiement
Euro Information / Commerce Electronique,

2/ Deuxième test réalisé avec une carte acceptée directement :

Bonjour,

Nous vous informons que votre interface de retour a emis un accuse de reception VALIDE et la commande a ete VALIDEE.

RECAPITULATIF DU PAIMENT :

Numero de TPE commercant : 1200000
Date du paiement : 2009-04-13 a 16:24:29
Reference du paiement : 14
Montant du paiement : 15 EUR
Descriptif du paiement : Commande

Vous trouverez ci-dessous les informations relatives a la requete emise par notre serveur ainsi que l'accuse de reception envoye par votre interface de retour.

REQUETE EMISE PAR NOTRE SERVEUR :http://www.monsite.com:80/modules/euroinformation/order.php?TPE=1200000&date=13/04/2009_a_16:24:38&montant=15EUR&reference=14&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN
Methode retenue : POST
TPE : 1200000
Host appele : www.monsite.com
Port : 80
CGI appele : /modules/euroinformation/order.php
Requete emise : TPE=1200000&date=13/04/2009_a_16:24:38&montant=15EUR&reference=14&MAC=OIFGUSIODIFUSDUGSDUSODGOSD&texte;-libre=Commande&code;-retour=payetest&retourPLUS;=--cvxoui--3DveN--3DpaN

Erreur 0

REPONSE DE VOTRE CGI DE CONFIRMATION :
Pragma: no-cache
Content-type: text/plain
Version: 1 OK

Cordialement,

CM-CIC paiement
Euro Information / Commerce Electronique,

Merci
Rose

blasto · September 7, 2009

UP plz ! ( urgent !!! )

blasto · September 8, 2009

Y a t'il moyen de ne pas réceptionner les erreurs de paiement ? finalement on en pas besoin .

Ca règlerait le problème ...

heyyou · September 18, 2009

Bonjour à tous,

Je rencontre exactement le même problème, à savoir :
- lorsqu'un client se trompe lors de la première saisie de ses coordonnées bancaires, j'obtiens un message CGI2 OK
- mais lorsqu'il les saisit pour la 2e fois, j'obtiens une erreur CGI

Le paiement a tout de même bien lieu, d'ailleurs je reçois ce message :
"Nous vous informons que votre interface de retour a emis un accuse de reception INVALIDE et la commande a ete VALIDEE."

tandis que le client reçoit ce message par mail :

"Une erreur est survenue lors du paiement de votre commande.
Vous pouvez accéder au suivi de votre commande et télécharger votre facture dans "Historique des commandes" de la rubrique "Mon compte" sur notre site."

ce qui se répercute sur le backoffice de la boutique par "erreur de paiement" à côté de la commande concernée.

Help!

heyyou · September 20, 2009

Salut à tous,
Ceux qui sont chez CIC/Credit Mutuel, comment faites-vous pour le moment ?
Vous a-t-il été possible de passer en production malgré le problème que je référence dans mon message précédent ?

jeckyl · October 3, 2009

Bonjour,

Ma question va être plus simple :

Y a t il des utilisateurs de ce module en prod actuellement ????

2l-Network · October 5, 2009

Bonjour,

Le module ne fonctionne pas apparemment, la version actuelle est la 3.0 chez CICPAIEMENT.

Quelqu'un l'utilise avec la V 3.0 ?

Cordialement,

huhamanu · October 14, 2009

Bonjour,
J'ai installé ce module sur deux sites, sur le premier ca fonctionne parfaitement, sur le deuxième les commandes ne sont pas validé mais les payement sont acceptés et encaissé au crédit mutuel.
Je crois qu'il y avait d'autres personnes dans le même cas? Quelles ont été les solutions?
Merci!

krimo · October 19, 2009

Bonjour,

Y a t-il un petit tuto pour montrer comment mettre en place ce module coté backoffice ? Plusieurs tentative de mise en place, plusieurs messages d'erreur.

Merci par avance

nautilebleu · October 30, 2009

@huhamanu

J'étais dans le cas des paiements acceptés mais avec des commandes non validés. J'ai pas mal galéré pour débloquer la situation. Entre autres, j'ai retéléchargé le module depuis la page 1, et en regardant le code que j'avais et celui que je venais de télécharger, j'ai vu pas mal de différences. Toutefois, ce n'était pas suffisant pour avoir un module qui fonctionne et j'ai dû faire du debug en prod (!!) pour arriver à avoir un truc qui fonctionne.

@krimo71

Il me semble que quelqu'un en avait posté un mais impossible de remettre la main dessus, ni par la recherche sur le forum, ni par Google, désolé :/

EnveloppeBulle · October 30, 2009

Bonjour
pour répondre à quelques interrogations : OUI il est possible d'utiliser ce module de paiement en prod avec CIC. C'est notre cas.
Il n'y a que 2 problèmes :
1) comme évoqué, en cas de retour en arrière du client, ou mauvaise manip client, le 1er paiement vient en erreur et bloque la commande, mais le 2ième est ok (du côté cic) et il faut alors aller dans la BDD pour remplir le champ "total_paid_real" puis indiqué que le paiement a été reçu dans le BO. (cela nous arrive assez rarement)

2) les arrondis ! il arrive qu'il y ait une différence de 1ct entre le total panier et la somme payée par le client (même chose, intervention dans la bdd pour régler le pb). J'ai pourtant modifié toutes les fonctions de calcule/affichage de nombres mais rien n'y fait (car dans presta, pour afficher les montants, ils utilisent la fonction php "number_format" alors qu'il me semble que la fonction "money-format" serait plus appropriée). j'avais par ailleurs constaté que du côté du CiC, en accès direct avec un montant avec décimales, chez eux, les arrondis se faisaient mal.. mais bon. Nous rencontrons principalement ce pb lors de l'utilisation de bons de réducs, et quand dans le calcule intervient un montant de type xx,255 où selon les systèmes, l'arrondi se fait en supérieur ou en inférieur). Cela dit, ce cas arrive très rarement.

Je ne sais plus quelle version d'euroinformation nous utilisons, mais elle a été mise en place en juin/09.

Vinzent · October 30, 2009

Bonjour.

Quelqu'un peut-il me dire où trouver les fichiers order.php et euroinformation.php qui fonctionnent dans le module euroinformation ?

Les miens sont, soit ceux de novembre 208, et dans ce cas pas de trace des commandes, soit ceux de janvier 2009, et là j'ai un cgi2 not OK.

Merci.

jeckyl · November 7, 2009

Salut à tous,

Euh, il faut sortir de saint-cyr pour réussir à configurer ce module (68 boutons à cliquer dans un ordre incertain).

Vraiment compliqué.

EnveloppeBulle · November 8, 2009

ici, on parle plutôt professionnel : donc les remarques de ce type n'apportent vraiment rien, surtout qu'en l'occurence, pas besoin de grandes études pour comprendre qu'un module de paiement implique de l'encryptage de données et une certaine sécurisation des infos ! (à moins qu'on ne parle pas de la même chose)
Et puis ce module est hyper simple à installer (comparé à d'autres systèmes de TPE virtuel à installer soi-même en lisant 2 tomes de doc) : il suffit de faire les choses dans l'ordre en suivant les indications.

Pour conclure, en l'absence d'autre solution de paiement CB (gratuite), je trouve dommage de taper sur le seul module qui permet d'accepter les paiements cb pour CIC, CM... surtout qu'il fonctionne plutôt bien !

jeckyl · November 9, 2009

Bonjour,

Loin de moi l'idée de polluer un post fort intéressant concernant ce modules.

Je suis juste étonné des ta réaction.

Ma remarque n'était qu'une réaction a chaud face à la page de configuration de ce module.

Ma vision est assez différente de la tienne quand à l'utilisation d'un module.
De mon point de vu, même si ce module s'adresse à des professionnels, comme tu le souligne justement puisqu'il faut avoir un contrat vad avec sa banque, je suis en totale opposition au fait que cela puisse justifié un manque d'ergonomie. Puisque Prestashop même s'adresse à des professionnels, on constate qu'un effort important est fait sur ce point. J'ai trop vu des "progiciel" totalement inutilisable par les utilisateurs, car développé sans tenir compte de l'utilisation même au quotidien. Mais si tu estime que pour faire pro un module doit être compliqué, celui ci est pas mal dans le genre.

Après j'estime avoir le droit de critiquer un module, même si il est gratuit, cela peut aussi permettre au développeur de se rendre compte qu'ils ont oubliés certains points, car le développement n'est pas toujours aisé lorsque l'on a "la tête dans le guidon".

Donc je souligne comme toi qu'il est très intéressant qu'il existe des modules de paiements gratuit pour Prestashop quand on constate les prix pratiqués sur le prestastore. Et tu as bien fait de réagir car ce module est très utile.

Pour finir, je clôture cette parenthèse dans ce post et si tu le désires, nous pouvons continuer cette discussion en MP ou même de vive (enfin pas trop) voix.

EnveloppeBulle · November 9, 2009

non tu as raison, inutile qu'un module soit compliqué pour faire pro, loin de moi cette pensée.

Ce que je voulais dire en fait, c'est qu'il faut être "pro" pour utiliser presta et ses modules de manière avancée (= installation / mise en palce, paramétrage et config de modules , config de système de paiement cb...).. et donc ta comparaison avec St Cyr m'a fait réagir, car entre un jeune diplômé militaire et une agence de com spécialisée dans la création de site, j'aurais plutôt tendance à penser que le 1er soit moins à l'aise avec un simple module prestashop :)

Non mais, ce qu'il faut savoir, c'est que ce module n'est qu'une adaptation du système de paiement distribué par la/les banques : bien-sûr ils n'ont pas fait en sorte que tout soit super intuitif et organisé simplement. Ils ont juste repris le formulaire de paramétrage fourni et adapté pour qu'on puisse utiliser ça en module.

je suis le 1er à dire que les critiques sont nécessaires pour faire avancer les choses (maintenant, perso, je ne vois rien à changer à ce module, si ce n'est faire en sorte qu'il n'y ait plus de pb d'arrondis, ce sui empêche toute revente du système à des utilisateurs lambda)

pour info, je ne suis ni diplômé d'une grande école, ni spécialiste web, ni même expert en informatique

Johnwinshark · November 9, 2009

Première phase de test pour ma part.
Je suis content d'avoir trouver un module gratuit qui permette de faire l'interface avec CMCIC... merci a son auteur !
Je n'ai pas encore rencontrer de problème pour l'instant ... les arrondis ca va ... mes prix sont plutôt rond et je fais pas de réduction ! nah :-) ( joke, venez voir mon site quand meme :-) )
Par contre, un petit conseil pour l'auteur, si ce n'est déjà fait, tu devrais avoir un petit site rapide ou on peut télécharger la dernière version du module et des news sur les mises a jour que tu y fais ... j'ai un peu hésiter au début a trouver ou télécharger tes fichiers...

---------------------------------
John
www.kijoo.fr
Votre boutique en ligne de jeux de société

EnveloppeBulle · November 9, 2009

Pour info (rien à voir directement avec les modules de paiement) voici am modif permettant de corriger les arrondis en cas de réduction en pourcentage :
ça se passe dans le fichier "discount.php" qui se trouve dans le dossier "classes"
ligne 231 (environ) vous avez le retour :

return $amount;

il suffit d'insérer cette ligne avant :

$amount = money_format('%8.2i', $amount);
return $amount;

Conséquence, un bon de 5% utilisé dans une commande qui ferait une réduction de 0,857 euros s'affichera bien 0,86 euro mais comptera vraiment comme 0,86 euro alors qu'avant, cela affichait 0,86 et ça comptait 0,85 !!

infobarquee · November 10, 2009

bonjour,
je viens de trouver ce module, je vais passer en phase de test.
j'aurais aimé savoir s'il était sécurisé correctement?
faut il aussi faire des manips sur le server, style ssl ou autre?
car j'utilise mon propre server, donc j'ais main sur toute la configue s'il y a besoin.
merci d'avance

lakeup · November 16, 2009

Bonjour à tous,

Je rencontre exactement le même problème, à savoir :
- lorsqu'un client se trompe lors de la première saisie de ses coordonnées bancaires, j'obtiens un message CGI2 OK
- mais lorsqu'il les saisit pour la 2e fois, j'obtiens une erreur CGI

Le paiement a tout de même bien lieu, d'ailleurs je reçois ce message :
"Nous vous informons que votre interface de retour a emis un accuse de reception INVALIDE et la commande a ete VALIDEE."

tandis que le client reçoit ce message par mail :

"Une erreur est survenue lors du paiement de votre commande.
Vous pouvez accéder au suivi de votre commande et télécharger votre facture dans "Historique des commandes" de la rubrique "Mon compte" sur notre site."

ce qui se répercute sur le backoffice de la boutique par "erreur de paiement" à côté de la commande concernée.

Help!

meme probleme ici, ce n'est arrivé que 2 fois, si cela se renouvelle trop je ferai installer un module payant.

Seo Organique · November 16, 2009

Peut-être pour cela qu'il est est payant dit donc!...il est clean.

jeckyl · November 24, 2009

Salut à tous,

Problème avec le paiement j'ai une erreur avec un paiement validé mais pas de commande presta (je peux trouver le panier mais pas créer une commande) voici les messages de CIC :

Nous vous informons que votre interface retour a emis un accuse de reception
INVALIDE et la commande a ete VALIDEE.

Références de couleur rouge  : votre serveur commerçant n'a pas (ou mal)
répondu à la confirmation d'enregistrement des informations de paiement
émise par notre serveur de paiement au moment de l'achat

Avez-vous eu ce genre de problème en ce moment ?

Raph59 · November 24, 2009

Bonjour,

J'ai eu l'erreur aujourd'hui également, jamais eu de problème auparavant..

Pour ma part, il a suffi de cliquer sur le lien qui était présent dans l'email de la banque pour valider la commande dans Prestashop, en revanche j'ai eu la chance par pur hasard d'avoir remarqué l'erreur très peu de temps après la commande, je ne sais pas si ca fonctionne tout de même si ca fait un petit moment...

Donc c'est tout de même bizarre, car le lien que le serveur de la banque devrais envoyer automatiquement dit que notre réponse est invalide, mais si nous on clic dessus ca fonctionne...

jeckyl · November 24, 2009

Pour ma part, il a suffi de cliquer sur le lien qui était présent dans l'email de la banque pour valider la commande dans Prestashop, en revanche j'ai eu la chance par pur hasard d'avoir remarqué l'erreur très peu de temps après la commande, je ne sais pas si ca fonctionne tout de même si ca fait un petit moment...

Super, la commande est crée, c'est génial.

Mais peut être que le client n'a pas finaliser la chaine en retournant sur notre site après paiement ?

Raph59 · November 24, 2009

Non selon moi il y a eu un réel problème plutôt du coté de la CM-CIC car qu'on soit 2 à qui c'est arrivé le même jour c'est une drôle de coïncidence je trouve

De plus selon moi le serveur CM-CIC doit surement envoyé la réponse à notre serveur dès le paiement accepté pour confirmer la commande, je ne pense pas que ce soit au client de finir la chaîne, en plus le courrier de la banque stipule bien qu'il y a eu une réponse de notre serveur INVALID... mais bon sincèrement je ne pense pas que ce soit nous le problème, j'attends le prochain paiement pour confirmation, car sinon il faut repasser le paiement en TEST pour avoir le détail de l'erreur... :s

EnveloppeBulle · November 24, 2009

je confirme de manière sûre et certaine que la commande est validée (l'info de paiement est envoyée au lien spécifié) à la fin du paiement, et qu'il n'y a pas besoin que le client fasse quoi que ce soit.
Ce pb a dû m'arriver une fois : j'avais alors plutôt supposé un pb au niveau de l'hébergement (ovh), car il suffit d'une micro indisponibilité juste au moment du retour cgi pour que ça foire.
D'ailleurs, dans le cas cité, le paiement a bien été accepté donc le paiement est bien validé.

Pour être sûr de ce qu'il s'est passé, n'est-il pas possible d'appeler le centrecom pour avoir + d'infos ? (le cas ne s'est présenté qu'une fois pour moi, réglé rapidemment, donc je n'ai pas cherché davantage)

ce serait p-ê intéressant d'en savoir + sur ce pb, histoire de ne plus le rencontrer...

lakeup · November 25, 2009

j'ai appelé le service centrecom CIC. j'ai eu toute sortes d'explication différentes suivant les interlocuteurs. cela va du serveur time out a un problem prestashop.... bref si quelqu'un les appele, merci de poster ici les réponses obtenues

Module EUROINFORMATION et bugs corrigés

Recommended Posts

Link to comment

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment