Voici la première étape d’un tutoriel qui en compte deux et qui va vous permettre d’installer un paiement sécurisé basé sur la solution ATOS SIPS (le leader sur le marché Français).
Avant toutes choses sachez que votre banque vous demandera pas mal d’informations et montera tout un dossier avant de vous autoriser (ou pas) à utiliser leur serveur pour vos paiements sécurisés. Cela prend du temps et je vous conseille de ne pas trop attendre avant de vous lancer dans ces démarches.
Les éléments nécessaires
Une fois le coté administratif réglé, vous devriez recevoir par mail:
- La documentation qui comporte notamment le dictionnaire des données et le guide d’installation.
- L’API (que nous détaillerons plus loin).
- Le certificat crypté (un fichiez .zip contenant un .exe qui porte le nom de certif.fr.xxxx)
Vous allez recevoir également par courrier la clé de décryptage du certificat crypté.
Description du contenu de l’API
L’API comprend les fichiers et dossiers suivants:
Le dossier Bin qui comprend:
- request_2.4.18_2.96
- response_2.4.18_2.96
- request_2.6.9_3.4.2
- response_2.6.9_3.4.2
- request
- response
Normalement vous ne devriez avoir besoin que des fichiers request et response (nous allons expliquer plus loin comment s’en servir).
Le dossier logo comprend les différents logos de cartes bleues et clés.
Le dossier param comprend:
- certif.fr.xxxxxxxx
- pathfile
- parmcom.sherlocks (ici sherlocks correspond au système du LCL cela peut changer selon la banque choisie)
- parcom.xxxxxxxx
Certif.fr.xxxxxx est un certificat de test qui va vous permettre d’effectuer vos tests avant la mise en production.
Pathfile est un fichier de configuration où il faudra indiquer les différents chemin des dossiers et fichiers utiles.
parmcom.sherlocks est un fichier de configuration de la banque déjà configuré, vous n’aurez pas à le modifier.
parmcom.xxxxxx est un fichier de configuration de test (les xxx sont remplacés par des numéros identiques pour certif.fr et parmcom).
Le dossier sample comprend des fichiers d’exemples:
- call_autoresponse.php
- call_request.php
- call_response.php
- et les mêmes fichiers en .pl (inutile pour une implantation en php)
Nous verrons plus loin comment se servir de ces fichiers.
Principe de fonctionnement
Là je ne me suis pas fatigué, j’ai repris le schéma de Thierry Godin qui a fait un excellent tuto sur le sujet également (même si dans mon cas certains points n’étaient pas tout à fait justes).
- Le client a rempli le caddie et le valide pour procéder au paiement.
- Le fichier call_request.php est exécuté et interroge le binaire request.
- Affichage des moyens de paiement.
- Le client clique sur la carte bancaire. Les données de la transaction sont envoyées au serveur du fournisseur.
- Affichage du formulaire de saisie de carte bancaire.
- Le client saisit ses numéros de carte puis valide. (Si le client abandonne, il est redirigé vers la page d’annulation : 6a -> 6b).
- Le serveur du fournisseur demande l’autorisation auprès d’une institution financière (réseau bancaire)
- La réponse est traitée par le fournisseur.
- La requête est renvoyée vers le fichier de réponse automatique call_autoresponse.php et le fichier de réponse manuelle call_response.php (9 et 9.a).
- Ces deux fichiers sont exécutés et interrogent le binaire response pour interpréter le résultat (10 et 10.a).
- Le fichier de réponse manuelle call_response.php affiche la page de résultat (Succès ou échec).
Envoi des fichiers request et response sur le serveur
A cette étape il y a deux possibilités, soit la variable safe_mode de votre serveur est placée sur ON soit sur OFF.
Dans le premier cas vous devrez alors envoyer vos fichiers request et response dans le répertoire indiqué par la variable safe_mode_exec_dir.
Dans le second vous pourrez envoyer vos deux fichiers où bon vous semble.
Pour connaître le statut du safe_mode et le répertoire du safe_mode_exec_dir sur votre serveur il suffit d’utiliser la commande phpinfo();
Le fichier pathfile
C’est le fichier qui va contenir les chemins d’accès aux fichiers de configuration, vous allez y indiquer:
- Le chemin vers le dossier logo. Ce chemin devra être relatif.
- Le chemin vers le fichier de configuration de la banque parmcom.sherlocks.
- Le chemin vers le fichier de configuration du commerçant parmcom.xxxxxxx.
- Le chemin vers le certificat du commerçant certif.fr.xxxxx.
- La mention YES ou NO pour le DEBUG.
Ce qui va vous donner au final:
######################################################################### # # Pathfile # # Liste des fichiers parametres utilises par le module de paiement # ######################################################################### # # #------------------------------------------------------------------------- # Activation (YES) / Désactivation (NO) du mode DEBUG #------------------------------------------------------------------------- # DEBUG!YES! # # ------------------------------------------------------------------------ # Chemin vers le répertoire des logos depuis le web alias # Exemple pour le répertoire www.merchant.com/sherlocks/payment/logo/ # indiquer: # ------------------------------------------------------------------------ # D_LOGO!/cbatos/logo/! # # -------------------------------------------------------------------------- # Fichiers paramètres liés a l'api sherlocks paiement # -------------------------------------------------------------------------- # # fichier des paramètres sherlocks # F_DEFAULT!/homez.316/monsite/www/cbatos/parmcom.sherlocks! # # fichier paramètre commercant # F_PARAM!/homez.316/monsite/www/cbatos/parmcom! # # certificat du commercant # F_CERTIFICATE!/homez.316/monsite/www/cbatos/certif! # # -------------------------------------------------------------------------- # end of file # --------------------------------------------------------------------------
Le fichier parmcom.xxxx
Ce fichier permet d’indiquer les urls de réponse automatiques et manuelles. Mais, vous le verrez après, il est possible de spécifier ces urls (et bien d’autres choses) directement dans le fichier call_request.php et c’est ce que nous allons faire. Donc pour le fichier parmcom.xxx nous allons simplement mettre en commentaire certaines lignes.
############################################################################### # # Fichier des parametres du commercant # # Remarque : Ce fichier parametre est sous la responsabilite du # commercant # ############################################################################### # URL de retour automatique de la reponse du paiement #AUTO_RESPONSE_URL!http://www.monsite.fr/cbatos/call_autoresponse.php! # URL de retour suite a paiement refuse #CANCEL_URL!http://http://www.monsite.fr/cbatos/call_autoresponse.php! # URL de retour suite a paiement accepte #RETURN_URL!http://! # Code devise ( 978=EURO ) CURRENCY!978! # Logo du commercant #LOGO2!commercant.gif! # flag d'edition des libelles des blocs de paiement HEADER_FLAG!no! # Liste des moyens de paiement acceptes PAYMENT_MEANS!CB,2,VISA,2,MASTERCARD,2! # END OF FILE
Ici je n’ai pas commenté les lignes:
- CURRENCY!978! qui indique la monnaie utilisée (ici l’euro).
- HEADER_FLAG!no! qui précise si on veut voir afficher le logo « clé » (ici on n’en veut pas).
- PAYMENT_MEANS!CB,2,VISA,2,MASTERCARD,2! qui indique les moyens de paiement proposés (ici CB,visa et mastercard).
J’aurai pu les commenter et spécifier ces éléments dans mon fichier call_request.php, à vous de juger ce qui sera le mieux dans votre cas.
Le fichier recap.php
Je vous entends déjà raler.. « oh ! c’est quoi ce fichier on n’en a pas parlé plus tôt ».
En fait ce fichier est celui qui va afficher un récapitulatif du panier du client (ou de sa future commande) ainsi que les moyens de paiement. Vous pouvez le nommer comme vous voulez ça n’a pas d’importance.
Pour le récapitulatif je ne peux pas vous aider c’est à vous de récupérer le contenu du panier et les informations de facturation saisies par le client. Vous devez également obtenir un montant total à facturer ainsi qu’un numéro de commande unique.
Une fois que vous avez tout cela vous allez pouvoir inclure (avec la commande include() ) dans recap.php le fichier call_request.php, c’est lui qui saura s’il est possible ou pas d’afficher les moyens de paiement.
Le fichier call_request.php
Le fichier call_request.php va récupérer tous les paramètres nécessaires à la transaction et générer une requête. Cette requête sera ensuite envoyée au fichier request puis il analysera la réponse obtenue.
Voila à quoi ressemble le fichier call_request.php
//Affectation des parametres obligatoires
$parm="merchant_id=014295303911111"; //merchant_id de test
$parm="$parm merchant_country=fr";//pays
$parm="$parm amount=".$totalCommande;
// Initialisation du chemin du fichier pathfile
$parm="$parm pathfile=/homez.316/monsite/www/cbatos/pathfile";
//l'email de l'acheteur
$parm .= " customer_email=" . $emailCommande;
$parm.=" order_id=".$idCommande;//numero unique de la commande
//url en cas d'annulation
$parm .= " cancel_return_url=http://www.monsite.fr/annulation.php";
// url réponse automatique
$parm .= " automatic_response_url=http://www.monsite.fr/cbatos/call_autoresponse.php";
//url de retour du client après le paiement
$parm .= " normal_return_url=http://www.monsite.fr/merci.php";
$path_bin = "/homez.316/monsite/cgi-bin/request";//ici j'avais choisi de placer mon fichier request dans le dossier cgi-bin
// Appel du binaire request
$result=exec("$path_bin $parm");
// sortie de la fonction : $result=!code!error!buffer!
// - code=0 : la fonction genere une page html contenue dans la variable buffer
// - code=-1 : La fonction retourne un message d'erreur dans la variable error
//On separe les differents champs et on les met dans une variable tableau
$tableau = explode ("!", "$result");
// recuperation des parametres
$code = $tableau[1];
$error = $tableau[2];
$message = $tableau[3];
// analyse du code retour
if (( $code == "" ) && ( $error == "" ) ) {
$txtReponse="executable request non trouve ".$path_bin;
}
// Erreur, affiche le message d'erreur
else if ($code != 0){
$txtReponse="<center><b><h2>Erreur appel API de paiement.</h2></center></b><br><br><br> message erreur : ".$error." <br>";
}
// OK, affiche le formulaire HTML
else {
$txtReponse=($error!="")?"<br><br>".$error."<br />":"";
$txtReponse.=$message;
}
Merchant_id correspond au numero qui se trouve derrière le fichier certif.fr.xxxxx (celui de test pour commencer on remplacera par le numéro du certificat officiel une fois tout configuré)
$parm amount cette variable prend le montant total de votre commande mais sans virgule. C’est à dire que pour 27.90 € vous devez indiquer 2790.
$parm pathfil le chemin vers le fichier pathfile
$order_id je vous ai précisé plus haut qu’il fallait prévoir un numéro de commande unique. Ce n’est en fait pas obligatoire mais conseillé. En effet, afin de retrouver dans votre base de données la commande qui vient d’être payée il est utile d’avoir un identifiant unique pour la repérer. C’est pourquoi nous renseignons $order_id avec cet identifiant. Vous pouvez aussi utiliser le même identifiant pour transaction_id ce qui vous permettra de faire le rapprochement entre une commande dans votre base de données et une transaction dans les logs de la banque.
cancel_return_url il faut indiquer ici l’url de la page qui sera appelée lorsque l’utilisateur cliquera sur le bouton annulé (une fois sur le serveur de la banque)
automatic_response_url c’est l’url du script qui sera appelé lorsque l’utilisateur effectuera son paiement (réussi ou non). Cette page ne peut afficher quoi que ce soit. Elle ne peut servir qu’à mettre à jour votre base de données.
normal_return_url c’est l’url de la page qui sera appelé lorsque le client aura payé et reviendra sur le site. Cette page reçoit les même informations que automatic_response_url la seule différence c’est qu’elle est appelé par le navigateur du visiteur et peut donc afficher du texte.
$path_bin le chemin vers le fichier exécutable request
Tel quel le fichier n’affichera rien, car le résultat est enregistré dans la variable $txtReponse. C’est votre fichier recap.php qui devra faire un echo sur cette variable pour afficher le résultat.
Rien ne vous oblige à inclure le fichier call_request.php dans le fichier recap.php, vous pourriez l’appeler directement. Mais en pratiquant ainsi vous séparez le code qui traite avec le serveur de la banque du code propre à votre site. C’est plus clair et plus réutilisable.
Vous n’avez plus qu’à envoyer votre fichier recap.php et call_request.php sur votre serveur.
Cette première partie est terminée et je pense qu’elle vous aura occupé déjà quelques minutes (heures). La prochaine étape sera plus simple et consistera à récupérer les informations renvoyées par la banque, mettre à jour la base de données en conséquence et enfin passer en pré-production puis en production.
N’hésitez pas à utiliser les commentaires pour poser des questions j’essaierai de vous répondre du mieux possible.
Installation d’un paiement ATOS SIPS – deuxième partie
Vous pouvez également lire « les erreurs fréquentes lors de l’installation d’un paiement Atos »
Tags : atos, paiement sécurisé, sips
- Permalien
- maniT4c
- 18 déc 2009 7:31
- Commentaires (25)

le 2 mai 2010 à 13:44
Juste une petite info au cas où certains se prendraient la tête comme moi sur ce problème :
Si jamais vous avez un problème d’exécution des fichiers binaires (request, response, autoresponse), sachez que parfois ils sont fournis en 32 bits.
Maintenant, de plus en plus de serveurs sont en 64 bits, il est donc nécessaire d’avoir les librairies pour lire des binaires en 32 bits sur un serveur 64 bits.
Sans quoi, comme moi, vous vous demanderez pendant des heures (jours) pourquoi ce fichier ne veut pas s’exécuter
Bon courage à tous ! Et bravo pour ce tutoriel très propre…
le 3 mai 2010 à 8:04
Merci pour ton commentaire qui en effet devrait aider quelques personne. Je crois avoir vu cette info quelque part dans la doc fournis avec atos.
le 4 décembre 2010 à 21:12
Bonjour,
Je me prends la tête depuis plusieurs heures/jours avec la fonction exec de php de call_request.php. Si les serveurs de mon hébergeur est en 64 bits, que dois-je faire concrètement ? Où récupérer les librairies et quoi en faire ? Cdlt, Mega
le 10 janvier 2011 à 11:34
Bonjour
Existe t’il un système similaire à la solution proposée par le Credit Mutuel mais pour la banque LCL où l’utilisateur est directement redirigé vers le module de paiement du credit mutuel tout beau est bien sécurisé ?
merci
le 9 mars 2011 à 19:59
Merci pour ce tutoriel.
La documentation de la banque est indigeste.
Avec ton aide ca a été vraiment pratique !
Je suis en mutualisé OVH.
J’ai repris les même nom de dossier et arborescence que toi.
Juste un peu galéré pour adapter :
/homez.316/monsite/cgi-bin/request
à mon cas :
316 = chiffre spécifique à l’abonnement OVH
monsite = login du site (et non pas le nom du site)
au pire demandez à OVH
Seul « bug », j’ai du modifier les droits 755 sur les fichiers :
– request
– response
Ca à l’air de réagir… je vois la page avec les Logos…
C’est encourageant après qqs heures à creuser dans le vide.
Encore merci
le 18 mai 2011 à 9:08
@DNS normalement le CHMODE 100 devrait suffire pour tes fichier request et response.
le 23 septembre 2011 à 12:19
J’essaye de transmettre des données dans le champ data de la chaine « parm » du genre :
$parm.= ‘ data=1EUROCOM_DATA=test#test2′;
message erreur : Invalid Keyword in parameter (1EUROCOM_DATA=test)
La syntaxe n’est pas correcte, j’ai essayé comme selon la doc :
$parm.= ‘ data= »1EUROCOM_DATA=test#test2#; »‘;
Même erreur.
Quelqu’un pourrait-il m’aider à ce sujet ?
Merci
Par ailleurs, pour ma part j’ai transféré par FTP les fichiers du plugin Linux. Les fichiers request et response n’étaient pas reconnus car il faut forcer leur transfert FTP en mode binaire (et pas en mode ASCII par défaut).
le 23 septembre 2011 à 16:45
@dev77 Déjà concernant le transfert des request et response oui en effet il faut les transférer en mode binaire.
Ensuite concernant ton problème, essai déjà de voir si tu as une erreur sans ajouter le paramètre data à ta requête.
Si tu as encore une erreur, je te conseille de supprimer tous les paramètres facultatifs (regarde le dictionnaire des données pour connaître les paramètres obligatoires).
Ensuite rajoute tes paramètres un par un.
Si ton problème apparaît uniquement avec le paramètre data essai de mettre autre chose que « 1EUROCOM_DATA ». Peut être que request n’aime pas le 1 au début, et la réutilisation du mot clef « data » peut porter à confusion.
Vérifie également les espaces et les guillemets (il ne doit pas y en avoir après le =).
Tiens nous au courant !
le 23 septembre 2011 à 17:29
C’est un problème de syntaxe.
Si je ne mets pas ce champ data, cela fonctionne.
Si je mets dans ce champ data un truc du genre :
$parm.= ‘ data=1EUROCOM_DATA=test’;
cela fonctionne.
Dès que je rajoute d’autres paramètres (avec la syntaxe de la doc) du genre :
$parm.= ‘ data=1EUROCOM_DATA=test#test2′;
ça ne fonctionne pas : Invalid Keyword in parameter (test2)
J’ai essayé en mettant des guillemets, en échappant les caractères spéciaux, rien n’y fait…
le 26 septembre 2011 à 9:55
Bonjour merci pour cet article (ces articles) bien complet(s) !! Qui laisse entrevoir des solutions abordables pour un problèmes qui me semblait inaccessible !!
J’avais une petite question : est-il envisageable d’après vous de greffer ce système sur un plugin Wordpress (type e-shop ou jigoshop) ? Je sais pas si des personnes on des retours d’expériences sur ce type de dev’ ? Merci d’avance.
le 26 septembre 2011 à 16:22
@dev77 J’ai cherché un peu dans la doc et je n’ai pas trouvé où il donnait la syntaxe pour le champ data. Peux-tu me dire dans quel documents et à quelle page tu as vu ça ?
Sinon, il parle du champ « data » dans le « dictionnaires des données » et dans le « guide de personnalisation des pages ».
Dans le premier, page 9 il précise que ce champ peut-être utilisé pour personnalisé l’affichage, paramétrer le paiement en plusieurs fois ou récupérer le numéro de carte.
Dans le second document page 17 il donne les différents mots clefs que tu peux utiliser.
Mais j’avoue que c’est pas super clair leur explication.
Je dirait que soit le champ data ne sert pas à transmettre des infos perso (c’est pourtant ce que je croyais) soit il y a une syntaxe bien précise.
Essai peut être comme ça:
$parm.= ‘ data=1EUROCOM_DATA=test#MA_VAR=test2′;
Tu récupérera peut être un truc du genre: $_POST['1EUROCOM_DATA']=test et $_POST['MA_VAR']=test2.
le 26 septembre 2011 à 16:25
@Erasmussen, j’ai jamais testé ni l’un ni l’autre des plugin wordpress dont tu parle. Mais je pense pas qu’il y ai de problème pour intégrer ce type de paiement. Si le plugin est bien codé ça doit pas être trop compliqué de le modifier pour qu’il permette d’utiliser atos.
le 26 septembre 2011 à 19:33
J’ai résolu mon problème (en grande partie).
Pour ton info, le champ data doit être renseigné pour une intégration de la solution 1euro.com, c’est un champ où tu peux mettre un peu tout ce que tu veux.
1euro.com fournit un document supplémentaire pour paramétrer ce champ data à leur sauce.
Au final, la syntaxe
$parm.= ‘ data=1EUROCOM_DATA=test#test2′;
fonctionne, mais uniquement sous Linux.
Le bug sous Windows est dû, selon le support technique, à une mauvaise interprétation de la commande exec sur cet OS.
Au final, tout fonctionne correctement puisque mon serveur de prod est sous Linux. J’essaierais plus tard de corriger le pb sous Windows.
Merci pour ton aide et ton tuto.
le 27 septembre 2011 à 9:16
@dev77 ok tant mieux si tu as fini par trouver la solution, et merci d’être venu la partager ici. Ca aidera surement d’autres personnes qui tomberont sur ce cas particulier.
le 27 septembre 2011 à 9:36
Réponse plus précise du support :
Le problème vient donc du comportement de la commande escapeshellcmd sur un poste Windows.
Cette commande n’agit pas de la même manière que sur Linux en fonction du Windows utilisé. La sécurisation de la commande exec() est a faire sous une autre méthode qui en-dehors de notre périmètre.
Merci et bonne continuation !
le 27 septembre 2011 à 9:42
Ok donc pour résumé soit tu est sous linux soit tu utilise pas 1eurocom_data.
C’est bon à savoir merci !
le 16 novembre 2011 à 1:26
bonjour
je dois installer sherlock’s dans un site dans lequel il n’ y a pas de montant fixe mais un montant fixé par le client
comment pourrais je faire
merci par avance
mehdi
le 16 novembre 2011 à 12:45
La démarche est exactement la même. La seule chose c’est que le montant de ta commande doit être déterminé par l’utilisateur.
A toi de générer la commande avec le montant que t’aura donné le visiteur puis de le réintégré dans l variable $totalCommande
le 19 novembre 2011 à 12:40
Auriez vous svp un exemple de formulaire avec la variable a intégrer ?
Merci
le 21 novembre 2011 à 8:58
Bonjour Mehdi, il te faut un formulaire classique. Mais si tu bloque sur cette partie j’ai peur que l’installation du paiement sécurisé de donne beaucoup de fil à retordre.
le 24 novembre 2011 à 0:37
bonsoir je l’ai installé sans pb
c’est juste de la faineantise et surtout je voulais voir l’implantation de la variable du montant pour l’envoyer dans mon call request
si quelqu ‘un a créé un formulaire avec les noms prenoms adresse je suis preneur
le 27 novembre 2011 à 17:12
Bonjour, j’ai un problème.
Le Call Url (quand je clique sur un type de carte bancaire) me redirige vers https://sherlocks.creditlyonnais.fr/cgis-payment-sherlocks/demo/callpayment. Mais cette adresse ne marche pas. Je pense que ce serais plutot https://sherlocks.lcl.fr/cgis-payment-sherlocks/demo/callpayment.
Comment faire pour la changer svp ?
Merci
le 28 novembre 2011 à 8:50
Tu ne peux pas changer l’url appelée par les carte bleues, le mieux serait d’appeler l’assistance sherlock.
Soit leur service est momentanément « planté » soit ils ont modifier l’url du serveur de démo et dans ce cas ton kit d’intégration n’est plus valable.
N’hésite pas à nous tenir au courant si tu trouve une solution.
le 2 décembre 2011 à 12:31
D’abord merci pour ce tuto,
J’ai galeré pendant 1 jour complet avant de tomber dessus pour trouver la solution a mon probleme.
impossible d’executer request et response
Sur un serveur 64 bits, il faut installer la librairie ia32-libs
un petit sudo apt-get install ia32-libs
le 2 décembre 2011 à 13:02
Content de t’avoir aider Fabien et merci pour l’astuce de la librairie, ça pourra servir
.