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 »
Sylvain
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…
maniT4c
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.
Megadeth
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 ;)
niko
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
dns
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
maniT4c
@DNS normalement le CHMODE 100 devrait suffire pour tes fichier request et response.
dev77
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).
maniT4c
@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 !
dev77
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…
Erasmussen
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.
maniT4c
@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.
maniT4c
@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.
dev77
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.
maniT4c
@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.
dev77
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 !
maniT4c
Ok donc pour résumé soit tu est sous linux soit tu utilise pas 1eurocom_data.
C’est bon à savoir merci !
mehdi
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
maniT4c
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
Mehdi
Auriez vous svp un exemple de formulaire avec la variable a intégrer ?
Merci
maniT4c
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.
mehdi
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
Maca
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
maniT4c
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.
Fabien
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
maniT4c
Content de t’avoir aider Fabien et merci pour l’astuce de la librairie, ça pourra servir :).
alexandra
bonjour les mecs,
j’ai suivi le tuto mais j’ai ce problème :
Chemin que vous avez configuré pour l’éxecutable: /home/eq72711/cgi-bin/
Fichier executable appelé: Le fichier n’existe pas
Accès de 0
le serveur d’hébergement est en 32 bit !
j’ai essayé plusieurs méthodes mais rien !
qq1 peut m’aider SVP :(
maniT4c
@Alexandra plusieurs choses à vérifier:
1. le chemin vers l’executable
2. les droits d’accès aux fichiers ET aux dossiers
3. vérifie que ton fichier n’est pas corrompu (si besoin change le mode de transfert de ton logiciel ftp)
olivier
Concernant le soucis de Maca sur l’URL demo/callpayment,
L’adresse cible du formulaire (vignette type CB) est défini par le certificat utilisé.
Le kit Sherlocks contient :
- un certificat obsolète
https://sherlocks.creditlyonnais.fr/…/callpayment
- un certificat récent :
https://sherlocks.lcl.fr/…/callpayment
maniT4c
Merci @Olivier pour les précisions.
Fresneau Tony
J’ai le même problème que alexandra :
Mes chemins sont bon mais j’ai toujours l’erreur suivante :
executable request non trouve
Une idée ?
J’ai installé des dizaines de module bancaires différents mais celui-la est vraiment TRÈS mauvais et mal conçut.
maniT4c
@Tony as-tu pensé à regarder si ton dossier avait les droits d’accès ? Ou si tes fichiers executable n’était pas corrompu suite au transfert FTP ?
Tu trouvera peut-être une piste sur cette page:
http://www.blog.manit4c.com/2011/04/28/erreurs-frequentes-lors-de-linstallation-dun-paiement-atos-sips/
Fresneau Tony
Je vient de vérifier et mon mutualiser OVH est en 64 bits que faire ?
maniT4c
Tony regarde le premier commentaire de cet article (de sylvain) il a rencontre le même problème que toi
Léo
Merci pour ce tutoriel.
Par contre je n’ai pas réussi à arriver jusqu’au bout:
dans le fichier call_request.php je ne parviens pas à récupérer les paramètres :
// recuperation des parametres
$code = $tableau[1];
$error = $tableau[2];
$message = $tableau[3];
A PHP Error was encountered
Severity: Notice
Message: Undefined offset: 1
Filename: cbatos/call_request.php
Line Number: 42
A PHP Error was encountered
Severity: Notice
Message: Undefined offset: 2
Filename: cbatos/call_request.php
Line Number: 43
A PHP Error was encountered
Severity: Notice
Message: Undefined offset: 3
Filename: cbatos/call_request.php
Line Number: 44
maniT4c
Il faut que tu commence par vérifier que ton chemin path_bin est exact. Essai avec file exist.
Verifie ensuite ta variable $parm en faisant un echo. Regarde bien qu’il n’y ai pas de caractères étranges et que les espaces sont bien respectés.
Enfin fait un echo de $result pour voir ce qui est affiché dedans.
grena
Merci pour cet excellent tuto.
Pour les personnes qui ont un problème avec « executable request non trouve », vérifiez bien les droits de lecture du fichier, mais surtout d’exécution ! (c’est un binaire…)
un chmod 511 devrait suffire.
maniT4c
@Grena merci pour ton commentaire, pour ma part je met chmod100 mais ça dépend peut être de l’hébergeur !
zezette
Bonjour et merci pour ce tuto tres utile.
Tout fonctionne parfaitement sauf pour les achats inferieur à 1€, j’ai alors ce message :
Erreur lors de l’appel de l’éxecutable ‘request’.
Message d’erreur:
API ERROR
Error in call parameters structure (invalid amount length (99))
As tu une idée d’ou cela peut venir? ou parametrer la longueur du champ amount?
maniT4c
Bonjour,
as-tu pensé à multiplier le montant par 100 ?
zezette
Je pense que oui.
Dans mon fichier checkout.sips_cc_form.php, j’ai bien :
$amount = $db->f(« order_total »)*100;
D’ailleurs en mode debug, mon parametre vaut bien 99 pour un achat à 0,99 €, ce qui signifie qu’il a bien été multiplié par 100…?
En revanche j’ai le message :
API ERROR
Error in call parameters structure (invalid amount length (99))
maniT4c
Il n’est pas exclue que ATOS refuse les transaction en dessous d’une certaine valeur.
Tu devrais dans un premier temps testé avec 10 puis 9, 8, 7 et ainsi de suite pour voir à partir de qu’elle valeur les paiement ne passe plus.
Ensuite regarde dans la documentation (pas forcément la documentation technique d’ailleurs) s’ils font mention d’une valeur minimum.
zezette
Ca ne fonctionne plus dès qu’on passe en dessous de 1€.
J’ai contacté plusieurs personnes du support technique de la banque qui m’affirment qu’ils acceptaient les paiements jusqu’à 0,3 €…
maniT4c
Attention, j’ai déjà eu à faire à des services techniques de banques qui n’était pas très calé en paiement sécurisé il est parfois préférable de joindre directement atos.
Sinon as-tu essayé de faire un echo sur ta variable $parm pour vérifier l’ensemble des paramètres que tu envois. Il y a peut être une erreur qui se produit uniquement pour les paiements inférieur à 1 € (un espace qui saute par exemple)
zezette
Je viens d’avoir Atos qui me dit que Amount doit etre sur 3 caracteres.
$parm => exactement identique qu’avec un achat superieur à 1€
maniT4c
Ca confirme donc qu’il n’accepte pas les paiement en dessous de 1 €.
A moins qu’ils acceptent les 099 mais de mémoire je ne crois pas, peut être faut-il se tourner vers une solution de micropaiement (rentabiliweb me viens en tête).
Pour info, je penses que le service technique de la banque qui t’as répondu qu’ils acceptait des paiements jusqu’à 0.3 € t’as donné l’info pour un TPE normal et non pas un TPE virtuel.
C’est à dire un paiement via CB mais en boutique physique. (la commission sur une CB étant je crois de 0.25).
Comme quoi j’avais raison il vaut mieux toujours appeler atos car les banques revendent un produit qu’elles ne connaissent pas.
zezette
Au final, j’ai forcé l’affichage des 0 pour des montants inférieurs à 1€ et ça a fonctionné ! (amount=’099′ pour un achat à 0,99€)
Un grand merci pour ce tuto et pour ton aide !
maniT4c
Merci pour ton retour ça aidera surement pas mal de monde :)
Je vais mettre à jour la FAQ d’ailleurs :)