Bonjour à tous et pour commencer je vous souhaite une très bonne année 2007.
 
J'ai une question concernant le paiement sécurisé.. je viens de terminer mon appli PHP, j'ai fait mon panier qui fonctionne tres bien... j'ai recu les codes du Crédit mutuel pour obtenir la clé... j'ai donc une clé !!!
 
Génial !!!! ... et maintenant j'en fais quoi ??? j'ai aucune doc sur ce systeme et je sais pas ou le trouver... si quelqu'un l'a ce serait top !
 
j'ai deja installé un systeme de paiement sécurisé (SIS- Atos) j'espere que c'est similaire voir plus simple !
 
Merci d'avance
 
Freed

Ben le crédit mutuel devrait aussi t'avoir envoyé l'adresse de son serveur sur lequel tu dois envoyer les infos, à savoir
- N° de CB du client qui paye
- Montant de la transaction
Et autres infos du même style !!!  

Bon j'ai trouvé une doc qu'un collegue m'a sortir de derriere les fagots !
 
maintenant je suis confronté à un premier probleme.. ils demandent d'encoder une chaine (concatenation) au format HMAC-SH1 ... j'avais jamais entendu parler de ce format.. il ressemble bcp au md5... il existe donc une fonction PHP pour faire ce genre d'encodage... elle s'appelle :
 
hash_hmac
 
... le probleme c'est que PHP me retourne :
 
Fatal error: Call to undefined function: hash_hmac() in include\file_include\inc_form_paiement.php on line 12
 
 
que faire ?

et pourquoi tu demandes pas le kit à ta banque ? normalement elle aurait dû te l'envoyer, et tu as dedans des exemples et les libs dans pas mal de langages (php, java, ...) ainsi que l'outil qui te permet de générer tout ce qu'il faut à partir de ta clé

bon allez j'ai fouillé dans mes archives et j'ai retrouvé qques trucs :
- Crédit Mutuel/CIC fournit un kit "opensource" Cybermut
- selon ton environnement technique, tu vas piocher dans le kit qui t'intéresse : PHP3/4, PHP+MySQL3/4, ASP, C/C++, etc.
Vu ton cas c'est le kit PHP3/4 qui t'intéresse
Le kit PHP+MySQL est trompeur car tu auras besoin de PHP et de MySQL pour faire tes encodages et cryptages alors que le kit PHP est full PHP
- dans le kit tu as des fichiers de fonctions à charger (via include) auquel il faudra au préalable "customizer" à partir de données que tu vas générer en partie grâce à ta clé fourni par la banque
- dans le kit tu as également des fichiers exemples qui montre une transaction avec une boutique virtuelle (ainsi qu'une clé associée)
- suivant la clé fournie (SHA1 ou MD5) tu vas pouvoir utiliser un outil fourni pour générer les codes qui te permettront de customizer les fichiers à inclure dans ton site ; il suffit de se laisser guider :
  1) copier/coller la clé envoyée par la banque dans le champs correspondant
  2) compléter la clé avec un passphrase (que l'on peut générer aléatoirement)
  3) saisir le TPE fournie par la banque
  4) diverses infos qui seront utilisées pour générer le formulaire que tu enverras à la banque (nom du bouton "submit" dans le formulaire, URL pour un paiement OK, URL pour un paiement KO, etc.)
  5) une fois tout saisie, l'outil te génère du code PHP à insérer dans les fichiers à customizer : c'est pas dur, c'est à insérer entre les commentaires "begin custom OverWrite" et "end custom OverWrite"
- sur ton site, dans ta page de validation du caddie, tu n'as plus qu'à charger le bon fichier PHP et à appeler la bonne fonction avec les bons paramètres pour qu'il te génère un formulaire à envoyer à la banque
- il te restera à créer la page qui accueillera le message retour de la banque (au moment où le client a payé sur le site de la banque)
 
Il faut quand même faire attention et bien tester (quand il y a de l'argent en jeu, c'est important...) : l'exemple du kit que j'ai recu (v1.03h) comportait une erreur, j'ai dû commenté une fonction déjà définie dans une autre page car ca me générait des erreurs PHP

merci pour tous tes renseignements,j'avais commencé à coder un formulaire en PHP à la main.. mais je sais pas si ça aurait pu marcher sans le kit... je te montre mon code (des fois que par aventure j'etais pas trop sur la mauvais voie)
 

"<?="
 
C'est le crédit mutuel qui file ce code?...

non j'ai juste essayé de reproduire un formulaire qui est sur leur doc, et pourquoi tu n'aimes pas les "<?=" ? ça m'evite de faire des <?php echo $toto ?>

certes, mais si le serveur est pas configuré pour interpréter les short_tag php, ton script marche plus...

bah quoi qu'il en soit... le probleme ne se pose pas puisque ce formulaire est toujours interpreté sur notre serveur... moi j'aime bien les short tags ! )

je maintiens que c'est risqué. En plus, le short_tag de php est identique au prologue de XML...

j'ai pas lu le code : ca sert à rien, la banque étant le prestataire pour le paiement c'est à elle de fournir c'est qu'il faut pour que tu puisses te connecter à leurs services
et puis au vu de nbre de choses à faire, un dév à partir de zéro aurait été truffé de code et de choses qui n'ont pas été pensés au départ

bon... alors.. j'ai reussi à avoir un kit...
 
le probleme est que.. j'y comprend que dalle !!!
ya rien qui documente vraiment ce kit... je sais pas ce qu'il faut includer ou pas.. bref ! c la cata !

bon en gros tout le roman que j'ai raconté pour le kit cybermut n'a servi à rien, car au final "ca marche pas" parce que tu comprends que dalle sur le kit que tu utilises dont on ignore tout (nom, version, etc.)
bizarrement j'ai plus trop envie d'aider....

xcuse moi j'ai ecrit un peu vite.. j'ai pas détaillé... apres je suis parti en réunion et j'ai pas repris les choses en mains... demain je m'y remet
 
PS : je crois qu'il me manque des infos pour continuer d'installer cette interface...  
j'arrive à generer un formulaire mais quand je le submit il me retourne une erreur du genre "impossible d'identifier" quand je regarde dans la doc.. ça correspond à un erreur causée par des données erronnées ou absentes concernant le code TPE (que je n'ai pas.. j'ai une clé mais pas un code TPE), du code société (que je n'ai pas non plus)
 
PS.. la version que j'ai je crois que c'est la 1.2

le code société et le code tpe sont fournis par la banque, il te manque des infos
 
sans ces informations tu ne peux pas générer un formulaire correct, car les vérifications côté banque sont faites à partir de tout cela

j'ai demandé ces codes ce soir au client pendant la réunion... j'espere qu'il saura me les trouver !

 
Coucou c'est remoi !!  
j'ai des questions, elles vont surement te paraitre stupide mais bon...pour moi c'est confus ! :
 
1°- Quelle différence y a t il entre le code TPE et la clef ?  
2°- En ce qui concerne le clef... on la met ou ???
3°- Peut tu me preciser ce qu'est le passphrase ? est ce quelquechose que je dois "inventer" ou bien ça doit etre un code bien précis ?
 
4° - le client n'est pas sûr de ses données... il m'a donné un code à 16 chiffres pour code société... mais il m'a bien dit "là je sais pas si c'est ça !" qu'en penses tu ?
 
 
Merci d'avance

Alors, voila ou j'en suis...
 
J’ai donc paramétré les fichiers MyTpeCMCIC.inc.php et CMCIC_HMAC.inc.php avec les informations générées par l’outil extract2HmacMd5.html
 
 
 
Dans l’ordre :
 
 
 
J’ai copié/collé le contenu de ma clé dans le champ en haut
 
J’ai saisi mon code TPE dans le champ concerné pour calculer le HMAC
 
J’ai saisir mon code de société (Qui est peut etre erroné !)
 
Séléctionné le kit choisi (PHP)
 
Séléctionné la banque (Crédit mutuel)
 
J’ai laissé les url de retour par défaut vu que pour l’instant je n’ai pas d’url de retour
 
J’ai donc généré le code source
 
 
 
Et copié collé les deux blocs dans les fichiers MyTpeCMCIC.inc.php et CMCIC_HMAC.inc.php à l’endroit indiqué.
 
 
 
Le formulaire à l’air d’être généré correctement… mais quand je le valide... l’erreur suivante m’est retournée :
 
 
 
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.  
 
 
 
 
… j’en conclus donc, après consultation des spécifications techniques que cette erreur est due à un code erroné (TPE, code société ou langue)
 
 
 
 
 
Comment savoir si le code société valide ? Puis-je savoir à quoi ressemble ce genre de code ? Le client m’a donné une série de 16 chiffres… je ne sais pas si c’est conforme !
 
 
 
 
 
Merci d’avance pour votre aide
 

allénouilla !!!!!
 
avec le bon code societe.. j'ai une évolution indéniable !!!!... le serveur me reconnait !!
 
... le probleme c'est qu'il me répond ça :
 
Le Terminal de Paiement Electronique (TPE) est fermé. Nous ne pouvons pas donner suite à votre demande de paiement.  
 
 

A mon boulot précédant, on a eu pendant longtemps deux adresses de paiements: une pour les clients et une de test. Peut être que pour le moment seule celle de test est ouverte. Que ca soit ou non le cas, il va faloir que tu rapelles ton client afin de savoir ce qu'il en est et avoir la bonne adresse du TPE.
C'est domage que ton client ne t'ai pas donné toutes les infos en une seule fois par ce que là ca fait un bon moment que tu galaires bêtement à cause de ça.

ouai j'ai appelé le support technique.. ils m'ont dit comment reactiver le TPE... ça c'est fait...
 
maintenant j'ai l'erreur suivante :
 
 
Les informations transmises par votre commerçant ont une signature non valide :
Le niveau de sécurité exigé n'est pas atteint.
Notre serveur n'est pas en mesure de traiter la demande de paiement
relative à votre commande.
 
 
... celle là c'est un probleme de code MAC dans le formulaire... là je crois que je vais secher grave !

alors pour info.... j'ai appelé le support technique...
mon erreur serait causé par la clé qui est "obselete", cette clé est utilisée sur un ancien site utilisant l'ancien systeme de paiement de Cybermut (qui tournait sous Windows, avec des executables et des dll pour le hashage etc etc)
Cette clé est incompatible avec le nouveau systeme open source de Cybermut (super !!!)
 
deux solutions :
creer une nouvelle clé... engendrant des frais
ou migrer les anciens sites en open source... engendrant du temps.. donc des frais !!!

il est marrant ton client, il préfère payer un prestataire qui se galère durant 1 semaine et qui aura au finale aucune solution sans la banque, plutôt que de sortir 3 copecs et lui filer toutes les billes

3ème solution : utiliser l'ancien système de paiement cybermut

je pense que le client ne sait pas tout ça tout simplement !

oui ! j'y ai pensé aussi.. mais le support technique ne me l'a pas proposé.. allez savoir pourquoi !
 
l'autre probleme est que les autres sites sont en ASP... la configuration de l'ancien systeme ne permet peut etre pas de parametrer si facilement les adresses de retour etc etc.. enfin c'est ce que j'ai cru comprendre !

freed102 > A mon ancien boulot, on utilisait l'asp et on pouvait modifier trés facilement les adresses de retour. Par contre le cryptage du code envoyé au serveur de la banque par l'intermédiaire du formulaire utilisait un ancien algorythme (md5 de mémoire alors que maintenant ils sont passé au sha ou au ssl) qu'ils préfaireraient éviter au maximum. Je me rapelle qu'on avait galéré il y a plus d'un an et demis pour obtenir un nouvel exemplaire d'un kit compatible avec la version qu'on avait avant le passage d'un gros virus.
 
Si tu ne leur indiques pas quelle version du kit t'as besoin, eux ils vont t'envoyer la toute derniére et c'est tout à fait logique.

Coucou me revoila !!
 
Et oui ! j'ai enfin réussit à faire mon paiement apres de longues journées d'attente pour une clé valide de la banque... maintenant que je peux payer.. j'aimerai pouvoir recuperer les variables envoyées par la banque pour mettre à jour ma bdd quand un paiement est rejeté ou validé... pour ça il faut faire un CGI2... mais là j'avoue que c'est super confus... ya rien de bien explicite... j'ai fait quelquechose qui n'a pas l'air tres fonctionnel... peut on m'expliquer un peu plus clairement ce qu'il faut faire ?

J'ai donné le lien d'une page (plus ou moins vierge) à Cybermut... mais apres ??
comment on peut savoir ce qui est envoyé au CGI2 ? à quel moment c'est envoyé ? j'ai pas de page "visible" apparement...

bah t'es pas censé "regarder"' ce qui est envoyé, mais plutôt "traiter" les informations qui sont renvoyés : c'est plutôt logique
 
généralement on fait un "update table_transactions set status=un_status_qui_dit_que_la_banque_a_accepte_le_paiement;" et d'autres choses encore (points de fidélité, date et heure de validation de la transaction par la banque, etc.)

bah c ce que j'ai fait.. mais ça n'a pa sl'air de marcher.. alors j'ai pas du faire ce qu'il faut.. j'essaie de recuperer les variables code-retour et reference... mais ça update pas ma table.. alors je suppose qu'il ne se passe rien
 

bon c'est ptet moi qui doit être fou, mais j'ai l'impression que tu veux révolutionner le monde en partant de zéro
 
mon code est basé sur le kit donné par la banque, qui positionne des variables pour faciliter la vie du développeur, mais qui permet également à la banque de valider de manière sécurisée les échanges effectuées
Au moment où je dois mettre mon code, après pleins de vérifications de sécurité par le code fournis par la banque, j'utilise la table de hachage $CMCIC_bruteVars, et non pas une variable émise en POST
Donc je me retrouve avec

 
Bon c'est ptet moi suis taré, mais je te conseillerais de lire de la doc. durant 1/2 journée pour réussir en 2h plutôt que de bidouiller pendant 1 semaine et finir par demander de l'aide sur un forum où peu de gens seront capables de te répondre sur un cas aussi spécifique
Heureusement que je suis pas ton client

Ah oui et un autre conseil, utilises des fonctions natives à ta bdd qui seront plus intéressantes plus tard : avec mysql on utilise un champs de type DATETIME avec la fonction NOW() dans la requête car :
1) ca évite de faire un gros pâté en php, ca expose bien ma remarque sur le fait que tu veux refaire le monde avec ton code php
2) tu te bases sur une BDD qui est faite pour encaisser le coup, pour prendre un cas extrême on ne s'amuse pas par exemple à faire des tris en PHP après requêtage, on fait le tri directement dans la requête
3) ca évite de perdre une information extrêmement importante quand de l'argent est en jeu, qui est l'heure à la seconde près
 
Quand le site sera en production, plus tu auras d'informations et plus ce sera facile de débugguer ou de ressortir des statistiques pertinentes
Savoir qu'on a eu 100 commandes à tel jour c'est bien, savoir qu'on a eu XX commandes entre 12h00 et 14h00 c'est mieux
Savoir qu'on a eu un pète sur une commande, et qu'on a l'horodatage à la seconde permet de s'assurer qu'on a bien retrouvé la commande qui pose le problème
 
enfin je dis ca, mais je dis rien...

 
Salut,  
 
j'avais deja essayé de faire ça aussi en utilisant un fichier nommé aRenommer.php (ou quelquchose comme ça), mais ça ne marchait pas non plus, de plus le serveur est en PHP 5..09, et tout ne fonctionne pas (comme les $_HTTP_VARS_SERVER qu'il faut remplacer par $_SERVER) donc n'ayant pas de visu les éventuelles erreurs que mon script peut retourner.. c'est difficile de savoir ce qui cloche !!
Concernant la doc, je l'ai lue 20 fois, et elle est tres pauvre en informations, elle indique que certaines variables sont retournées par le serveur, et qu'il faut utilsier test_hmac() pour verifier la validité ou un truc comme ça mais c tout ! ya une page et demi là dessus mais rien d'explicite !

 
Concernant les dates.. je suis tout à fait d'accord avec toi ! moi j'utilise les timestamps en général, malheureusement les champs date me sont imposés par le CMS que j'utilise... probablement une grosse erreur de conception ? j'en sais rien ! je n'en suis pas le créateur ! mais maintenant je suis souvent confronté à ce genre de problèmes. le champ date est sous la forme yyyy-mm-dd et je ne peux pas la changer (des centaines de sites sont sur ce modèle et je n'ai pas le droit de modifier les tables)

et bien justement si : de mémoire la banque te renvoie la sortie de ton script par email
Et je crois même que par défaut il te faut un dump de la varialbe $CMCIC_bruteVars

c difficile à faire quand c'est le client qui recoit les mails et pas moi !

rien ne t'empêche de faire un dump des variables dans un fichier texte...

j'y crois pas !!!! j'avais fait un petit script d'envoi de mail dans mon cgi2, et ce matin je regarde mes mails et voila ce que je reçois :
 
Une tentative de paiement à été effectuée le 08-02-2007 à 06:34:46  
 
c'est à croire que finalement ça marche... mais faut etre patient !