Installer l’API PHP 615 ATOS (sogenactif)

Un beau matin, vous vous dites – ou on vous dit – que vous aller devoir installer un kit de paiement ATOS. Et là vous pensez : gaaalèère… Mais non, suivez moi, j’ai déjà galéré pour vous et je vais vous guider. Ça passera comme une bonne bière après le boulo !

Préparatifs

Télécharger l’API

Avant toute chose, il faut télécharger l’API qui va bien. Vous avez normalement dû recevoir un mail de votre banque qui vous donne un identifiant de connexion à l’interface de téléchargement, et un papier par la poste qui vous donne le mot de passe.

Premier constat, lorsqu’on se logue sur l’interface de téléchargement de l’API : Wahou ! ça sent bon l’austérité ici…

page de telechargement de l'api

Il faut donc télécharger l’API PHP sogenactif_615_PLUGIN_linux-2.6.9.tar. Il y en a aussi une en 64 bits, vous pouvez alternativement prendre celle-ci si vous avez un système 64 bits (quoique le 32 devrait aussi marcher sur un système 64 bits).

Détarrer l’archive

Détarrez l’archive, vous devriez obtenir cette arborescence :

schéma de l'arborescence de l'api ATOS 615

Attention : vous voyez que dans les sous-dossiers de bin, glibc-2.3.4 et static, vous avez les mêmes exécutables request et response. Eh bien que neni m’sieur ! Oui ça paraît logique qu’ils soient différents mais attention de bien choisir le votre. Si vous avez glibc sur votre serveur, ce sont les exécutables du dossier glibc qu’il faudra utiliser. Donc dans mon cas, pour un mutualisé OVH, c’est glibc. Ça vous évitera des incompréhensions face à cette page d’erreur laconique qui ne vous dit rien de plus que « erreur appel request » et « exécutable request non trouvé ».

Quelques fichiers de test

Je vous conseille de vous créer un fichier php qui vérifie les chemins, comme ça, si vous avez une erreur du genre, vous êtes fixé rapidement.

<?php
echo file_exists('chemin a verifier');
?>

Profitez-en pour créer deux autres fichiers php. Un que l’on appelera info.php et qui contient la fonction phpinfo :

<?php
phpinfo()
?>

L’autre peut être facultatif, il permettra de trouver les chemins absolus de votre serveur mais vous pourrez aussi les obtenir par ssh, c’est à vous de voir ce qui est le plus pratique, ou alors, si votre hébergeur ne vous fournis pas d’accès ssh, la question est réglée. Nous appellerons ce fichier chemin.php.

<?php
echo realpath(‘chemin.php’) ;
?>

Placer les fichiers sur le serveur

Placez le fichier info.php sur votre hébergement et appelez-le via votre navigateur. Si le safe mode est à ON, vous devrez copier les fichiers exécutables request et response dans le répertoire défini à la ligne safe_mode_exec_dir, sinon, vous pouvez mettre les exécutables où vous voulez sur l’hébergement.

phpinfo safe mode

Dernière étape avant que nous entrions dans le vif du sujet, copiez les dossiers et fichiers sur votre hébergement. Créons un dossier payment, et dans lequel nous plaçons le dossier logo, les fichiers certif.fr.014213245611111.php et parmcom.014213245611111, parmcom.sogenactif ainsi que pathfile et les exécutables request et response. Rappelez-vous que si votre hébergement a la directive safe mode à ON, il faudra placer les exécutables dans le répertoire indiqué. Réglez le CHMOD de request et response à 755.

Note : le fichier certif.fr.014213245611112.php (fini par un 2) est utilisé pour simuler un paiement 3D secure, le reste de la procédure est identique.

Note 2 : les contrats nouvellement souscrits sont automatiquement 3D secure (en tout cas à la Société Génerale). Faites donc vos tests avec le certificat 3D secure.

Configuration des fichiers

Nous avons trois fichiers de configuration à renseigner. Il s’agit de :

  • pathfile
  • parmcom.sogenactif
  • parmcom.014213245611111

Leur configuration est relativement aisée et rapide, il suffit de faire attention à renseigner les champs correctement sans se tromper, sinon, l’API retournera des erreurs assez évasives, et ce sera parti pour la chasse à l’épingle dans le foin…
Note : l’API n’apprécie pas du tout les espaces dans les chemins, donc gare !

Le fichier pathfile

Le fichier pathfile renseigne l’API sur les chemins de différents fichiers et dossiers dont il a besoin pour fonctionner. Il prend 6 paramètres :

  • Activation ou désactivation du mode Débug, mettez le à YES tant que vous n’êtes pas en production,
  • chemin relatif vers le répertoire des logos,
  • chemin absolu vers le certificat (certif.fr.014213245611111.php),
  • type de certificat, dans notre cas « php » (normalement ce champ est déjà renseigné),
  • chemin du parmcom commerçant (parmcom.014213245611111),
  • chemin du parmcom sogenactif.
#########################################################################
#
#	Pathfile 
#
#	Liste fichiers parametres utilises par le module de paiement
#
#########################################################################
#
#
#-------------------------------------------------------------------------
# Activation (YES) / DÈsactivation (NO) du mode DEBUG
#-------------------------------------------------------------------------
#
DEBUG!NO!
#
# ------------------------------------------------------------------------
# Chemin vers le rÈpertoire des logos depuis le web alias  
# Exemple pour le rÈpertoire www.merchant.com/sogenactif/payment/logo/
# indiquer:
# ------------------------------------------------------------------------
#
D_LOGO!/payment/logo/!
#
# --------------------------------------------------------------------------
#  Fichiers paramËtres liÈs a l'api sogenactif paiement	
# --------------------------------------------------------------------------
#
# certificat du commercant
#
F_CERTIFICATE!/homez.374/monsite/www/payment/certif!
#
# type du certificat
#
F_CTYPE!php!
#
# fichier paramËtre commercant
#
F_PARAM!/homez.374/monsite/www/payment/parmcom!
#
# fichier des paramËtres sogenactif
#
F_DEFAULT!/homez.374/monsite/www/payment/parmcom.sogenactif!
#
#########################################################################
# End of file
#########################################################################

Note : Les chemins sont ici des chemins physiques absolus. Pour les trouver, deux méthodes :

  • soit vous utilisez votre terminal et lorsque vous vous retrouvez dans le dossier contenant vos fichiers de configuration, la commande pwd vous donnera ce dont vous avez besoin,
  • soit vous placez le fichier chemin.php — dont nous avons parlé précédemment — dans le même dossier que les fichiers dont vous voulez connaitre le chemin. Appelez ensuite chemin.php avec votre navigateur, et là, magie, vous n’avez plus qu’a faire un copier coller (sans oublier de remplacer chemin.php par le nom du fichier correspondant).

Le fichier parmcom.sogenactif

Ce fichier prend de nombreux paramètres, rassurez-vous, la plupart sont pré-renseignés et vous n’aurez pas besoin d’y toucher. Pour plus de renseignements, tournez-vous vers le dictionnaire des données. Le seul paramètre qu’il nous faut réellement configurer concerne la liste des moyens de paiement acceptés (PAYMENT_MEANS). Elle proposera les différent moyens de paiements à vos internautes. Configurez bien cette liste en adéquation avec votre contrat. Si vous avez souscrit un contrat pour CB et VISA seulement, ne mettez pas Mastercard, vous aurez sinon une erreur par la suite.

Ce code vaut pour CB et VISA seulement :

PAYMENT_MEANS!CB,2,VISA,2!

Et celui-ci ajoute les cartes Mastercard et American Express :

PAYMENT_MEANS!CB,2,VISA,2,MASTERCARD,2,AMEX,2!

Les blocs 1 à 8 (CB,2 désigne un bloc) permettent d’afficher différents messages et d’ordonner l’affichage des cartes. Un exemple avec le code suivant :

PAYMENT_MEANS!CB,2,VISA,2,MASTERCARD,1,AMEX,1!
page de payement sélection des cartes

Vous constatez aussi que le paramètre block_order ordonne les blocs. Mastercard et Amex, qui sont dans le bloc 1 sont affichés au-dessus de CB et VISA, respectivement dans le bloc 2.

Ce fichier parmcom.sogenactif permet la personnalisation de votre page de paiement :

  • # couleur du fond d’ecran (BGCOLOR) vous permet de régler la couleur de fond (blanc par défaut).
  • # Couleur du text (TEXTCOLOR) vous permet de choisir la couleur du texte (noir par défaut).
  • advert et logo_id2 vous permettent d’afficher des logos positionnés comme sur le schéma ci-dessous :
personnalisation de la page de payement
###############################################################################
#
#	Fichier des parametres Sogenactif paiement
#
#	Remarque :	Ce fichier paramËtre est sous la responsabilitÈ de la
#				Societe Generale
#
###############################################################################


# Logo de la Societe Generale

ADVERT!sg.gif!

# couleur du fond d'ecran (blanc)

BGCOLOR!ffffff!

# Mode d'affichage des blocs de paiment

BLOCK_ALIGN!center!

# Ordre d'affichage des blocs de paiement

BLOCK_ORDER!1,2,3,4,5,6,7,8!

# Mode de securite 

CONDITION!SSL!

# Code devise  ( 978=EURO )

CURRENCY!978!

# flag d'edition des libelles des blocs de paiement

HEADER_FLAG!yes!

# Code langage de l'acheteur (fr=francais)

LANGUAGE!fr!

# Logo Interactis paiement

LOGO2!sogenactif.gif!

# Code pays du commercant

MERCHANT_COUNTRY!fr!

# Code langage du commercant

MERCHANT_LANGUAGE!fr!

# Liste des moyens de paiement acceptes

PAYMENT_MEANS!CB,2,VISA,2!

# Passage en une seule frame securisee au moment du paiement

TARGET!_top!

# Couleur du text (noir)

TEXTCOLOR!000000!


# END OF FILE

Note : Les logos prennent en paramètre uniquement leurs noms plus leurs extensions car ils seront mis sur le serveur de paiement de la banque. Avant de passer en production, vous enverrez un mail au support technique avec les logos à intégrer sur la page de paiement. logo_id1 se renseigne dans le parmcom commerçant.

Attention : Le fichier parmcom.sogenactif permet de renseigner certaines options que l’on peut aussi renseigner dans le script call_request.php (langue du commerçant, devise…), si les renseignements ne coïncident pas, les paramètres de call_request seront pris en compte.

Le fichier parmcom commerçant

Le fichier parmcom.014213245611111 demande 4 paramètres :

  • Votre logo (250px X 100px recommandé en format GIF).
  • L’url de retour automatique du serveur de paiement sera le fichier call_autoresponse.php dont nous parlerons plus loin.
  • L’url de retour suite à paiement refusé ou annulation. Vous pouvez vous contenter d’afficher une page avec un message de remerciement et un moyen de vous joindre pour finaliser la transaction. Nous n’en parlerons pas.
  • L’url de retour suite à un paiement accepté, c’est le fichier call_response.php que nous verrons par la suite.
###############################################################################
#
#	Fichier des parametres du commercant
#
#	Remarque :	Ce fichier paramËtre est sous la responsabilitÈ du
#				commercant
#
###############################################################################

# Logo du commercant (il apparait en haut a gauche des pages de paiement)

LOGO!logo.gif!

# URL de retour automatique de la reponse du paiement

AUTO_RESPONSE_URL!http://www.votre-site.com/call_autoresponse.php!

# URL de retour suite a paiement refuse

CANCEL_URL!http://www.votre-site.com/cancel.php!

# URL de retour suite a paiement accepte

RETURN_URL!http://www.votre-site.com/call_response.php!


# END OF FILE

Note : les chemins sont ici des chemins internet absolus.

Nos scripts php

Vous trouverez les scripts php dans le dossier sample de votre API. Contrairement aux autres fichiers et dossiers, nous placerons ces fichiers à la racine de notre site. On pourra donc appeler le call_request via un navigateur internet, comme cela : http://www.mon-site.fr/call_request.php

Vous pouvez les placer dans un autre répertoire de votre choix, cependant, la démarche est plus simple comme cela. C’est pourquoi nous procéderons ainsi.

Attention : ATOS ne mettant pas (régulièrement) à jour sa documentation, vous veillerez à remplacer $HTTP_POST_VARS par $_POST dans vos codes. En effet, cette variable permettant de récupérer les valeurs passées en POST est obsolète depuis la version 4.1.0 de PHP et a été totalement supprimée dans la 5.6.

Si vous l’utilisez avec une version de php > 5.5, vous obtiendrez une erreur « Error get DATA response parameter » sur les pages call_response.php et call_autoresponse.php.

call_request.php

Dans le dossier sample, vous trouverez un fichier php nommé call_request.php. C’est lui qui va initier la phase de paiement en appelant l’exécutable request et qui affichera la page de sélection des cartes.

construction du formulaire call request

Le fichier call_request.php prend de nombreux paramètres. Parmi ceux-ci, beaucoup sont facultatifs, nous n’en parlerons donc pas. Vous pouvez pour cela vous référer au dictionnaire des données.

//Affectation des paramètres obligatoires
$parm="merchant_id=014213245611111"; 
$parm="$parm merchant_country=fr"; 
$parm="$parm amount=100"; 
$parm="$parm currency_code=978";

Nous avons d’abord les paramètre obligatoires qui seront transmis à l’exécutable request :

  • le merchant_id est ici celui de test. Laissez le tel quel, vous le remplacerez par votre propre marchant id pour passer en pré-production.
  • le merchant_country concerne la langue de l’interface, laissez fr si votre interface est en français, pour les autres langues, je vous conseille de jetez un coup d’œil au dictionnaire des données.
  • amount, est la variable qui – vous l’aurez deviné – contiendra le montant total de votre caddie.
  • currency_code se réfère à la devise, 978 est le code pour désigner l’euro. À nouveau, si vous voulez préciser une autre devise → dictionnaire des données.

Attention : petite particularité, le montant doit être transmis en centimes. Par exemple, pour un montant total de 100€, vous transmettrez le chiffre 10000 à votre variable. Vous pouvez utiliser number_format pour mettre votre total au bon format.

$amount = number_format($amount, 2, '', ' ');

Vous devez ensuite renseigner le chemin absolu (attention chemin physique, pas internet) des fichiers pathfile et reqest. Utilisez chemin.php comme nous l’avons vu précédemment.

Le transaction_id est un numéro de transaction qui doit être unique sur la journée. Comme le commentaire le précise, il n’est pas obligatoire de fournir ce numéro de transaction. Si vous n’en fournissez pas, le système se chargera d’en générer un pour vous à partir de l’heure. Cependant, si deux visiteurs cliquent en même temps, nous risquons d’avoir deux transaction_id identiques. Pour évitez cela, nous allons générer le notre :

//ID unique de transaction
//Nous allons nous baser sur le temps UNIX pour générer notre numéro, 
//cependant, ce timestamp a le même problème que celui généré par le systeme. 
//Pour y remédier, nous allons le multiplier par un nombre aléatoire 
//(j’ai choisi entre 0 et 10, c’est tout à fait arbitraire)
$transactionID = time() * rand (1,99);

//ID unique de transaction est nombre compris entre 0 et 999 999. 
//Nous allons donc tronquer notre nombre pour qu’il soit toujours inférieur à 1 million.
$transactionID = substr($transactionID, -6); 

Nous utiliserons également le champ order_id, qui est facultatif, car il peut contenir jusqu’à 32 caractères. C’est bien plus pratique que le transaction_id pour identifier de manière unique une transaction. Ce champ est retourné tel quel dans la réponse lorsque le serveur de la banque appelle autoresponse. Pour générer de manière unique un identifiant, on peut utiliser la fonction uniqid() de php, laquelle fournit une chaine de 23 caractères basée sur l’heure courante en microseconde.

Vous trouverez ci-dessous l’intégralité de la partie métier du call_request. Pensez bien que pour des raisons de brièveté, je n’inclue ici pas l’intégralité du html. Cependant, n’oubliez pas de servir une page html valide à vos clients !

if ($_POST['amount']) {
  // on arrive dans cet exemple sur le call_request
  // par un formulaire qui transmet le montant
  // on le récupère donc
  $amount = (int)$_POST['amount'];

  $parm="merchant_id=014213245611111";
  $parm="$parm merchant_country=fr";
      
  // montant total formaté en centimes --> 100€ = 10000
  $parm="$parm amount=".$amount;
  $parm="$parm currency_code=978";
        
  // Initialisation du chemin du fichier pathfile (à modifier)
  $parm="$parm pathfile=/homez.374/monsite/www/payment/pathfile";
      
  // Si aucun transaction_id n'est affecté, request en génère
  // un automatiquement à partir de heure/minutes/secondes
  // Référez vous au Guide du Programmeur pour
  // les réserves émises sur cette fonctionnalité
  $transactionID = time() * rand (1,99);
  $transactionID = substr($transactionID, -6);
  $parm="$parm transaction_id=".$transactionID;

  // comme expliqué plus haut il est plus facile d'identifier
  // la commande avec un order_id
  $order_id = uniqid();
  $parm="$parm order_id=".$order_id;
      
  $path_bin ="/homez.374/monsite/www/payment/request";
      
  // Appel du binaire request
  $parm = escapeshellcmd($parm);	
  $result=exec("$path_bin $parm");
      
  // sortie de la fonction : $result=!code!error!buffer!
  // - code=0 : la fonction génère 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");
							
  // récupération des paramètres
  $code = $tableau[1];
  $error = $tableau[2];
  $message = $tableau[3];
			
  //  analyse du code retour
  if (($code == "") && ($error == "")) {
    print ("<BR><CENTER>erreur appel request</CENTER><BR>");
    print ("executable request non trouve $path_bin");
  }
			
  // Erreur, affiche le message d'erreur
  else if ($code != 0) {
    print ("<center><b><h2>Erreur appel API de paiement.</h2></center></b>");
    print ("<br><br><br>");
    print (" message erreur : $error <br>");
  }
			
  // OK, affiche le formulaire HTML
  else {
    print ("<br><br>");
						
    # OK, affichage du mode DEBUG si activÈ
    print (" $error <br>");
    print ("  $message <br>");
  }

// on peut faire ici ses enregistrements en base de données
// bien enregistrer order_id car c'est lui qui lie le paiement 
// aux autres informations de la commande et du client
}

Avertissement : Prenez soin de mettre en base de données toutes les informations concernant votre client avant de l’envoyer sur la page de paiement. En effet, il se peut que celui-ci ne revienne pas sur votre site après que le serveur de la banque lui ait donné confirmation du paiement. Le serveur de la banque appellera automatiquement votre script autoresponse.php pour vous notifier du succès ou de l’échec du paiement. Cependant, votre seul moyen d’identifier le client sera le transaction_id ou l’order_id. C’est pourquoi il est impératif d’enregistrer en base de données avant que le client ne soit envoyé sur le serveur de paiement, sans quoi, vous ne saurez pas qui a payé, et qui n’a pas payé…

Dans cet exemple, nous enregistrons les informations dans le call_request. On pourrait également générer le order_id et enregistrer les informations en amont. Ce dernier serait alors transmis en $_POST avec le montant de la commande. Vous pouvez aussi gérer ça avec des sessions, bref, tout est possible tant que vous enregistrez les infos en base avant que le client ne parte sur le serveur de la banque.

MAJ

*********************

Comme vous pouvez le constater dans les commentaires, un lecteur m’a fait part d’une procédure un peu différente chez lui (pourtant aussi sur un mutu OVH…) Donc ceux qui n’arrivent pas à passer l’étape de l’erreur avec le message « erreur appel request« , vous pouvez tenter cette procédure alternative.

En plus des exécutables request et response, Thierry a dû mettre les droits du pathfile à 755 aussi. En outre, concernant les chemins du call_request, au lieu de renseigner les chemins physiques absolus, ils sont comme ceci :

$parm="$parm pathfile=./pathfile";
$path_bin = "./request";

*********************

call_response.php

Le fichier call_response.php est la page web sur laquelle le visiteur est redirigé après son paiement s’il clique sur « retourner sur le site du commerçant ». Cette page retourne certaines variables utiles, comme le succès ou l’échec du paiement. Cependant, comme précisé plus haut, le visiteur peut ne pas revenir sur notre site et cette page ne sera jamais appelée. Aussi, il préférable d’effectuer les traitements de base de données avec le script autoresponse.php, qui retourne les mêmes informations, mais qui sera systématiquement appelé par le serveur de la banque.

Nous nous contenterons ici de renseigner les variables indispensables. À savoir : le pathfile et l’exécutable response. Ces chemins se renseignent de la même manière que dans le script call_request.php.

// Initialisation du chemin du fichier pathfile (à modifier)
//   ex :
//    -> Windows : $pathfile="pathfile=c:/repertoire/pathfile";
//  -> Unix    : $pathfile="pathfile=/home/repertoire/pathfile";
   
$pathfile="pathfile=/homez.374/monsite/www/payment/pathfile";

// Initialisation du chemin de l'executable response (à modifier)
// ex :
// -> Windows : $path_bin = "c:/repertoire/bin/response";
// -> Unix    : $path_bin = "/home/repertoire/bin/response";

$path_bin = "/homez.374/monsite/www/payment/response";

Nous afficherons tout de même un message à notre client selon que le paiement s’est déroulé correctement ou non. La variable $bank_response_code nous informe de l’état du paiement. Vous allez le constater, nous ne gardons ici pas grand chose du fichier d’exemple d’origine. Peu de variables servent finalement puisque nous n’effectuons pas de traitement sur cette page. Elles peuvent en revanche trouver leur utilité lors de la phase de test.

// Récupération de la variable cryptée DATA
//$message="message=$HTTP_POST_VARS[DATA]";

// Attention, la variable $HTTP_POST_VARS n'existe plus dans les versions récentes de php
$message="message=$_POST[DATA]";
    
// Initialisation du chemin du fichier pathfile (à modifier)
$pathfile="pathfile=/homez.374/monsite/www/payment/pathfile";
  
// Initialisation du chemin de l'executable response (à modifier)
$path_bin = "/homez.374/monsite/www/payment/response";
  
// Appel du binaire response
$message = escapeshellcmd($message);
$result=exec("$path_bin $pathfile $message");

// on separe les differents champs et on les met dans une variable tableau
$tableau = explode ("!", $result);

// Récupération des données de la réponse
$code = $tableau[1];
$error = $tableau[2];
$bank_response_code = $tableau[18];

// analyse du code retour
if (($code == "") && ($error == "")) {
  print ("<BR><CENTER>erreur appel response</CENTER><BR>");
  print ("executable response non trouve $path_bin");
}

// Erreur, affiche le message d'erreur
else if ($code != 0) {
  print("<center><b><h2>Erreur appel API de paiement.</h2></center></b>");
  print("<br><br><br>");
  print(" message erreur : $error <br>");
}

// OK, affichage des champs de la réponse
else { 
  if ($bank_response_code == 00)
  {?>
    <h1>La transaction s'est effectuée avec succès !</h1>
    <h2>
      Nous vous remercions de la confiance que vous 
      nous accordez. Vous recevrez un e-mail de confirmation 
      pour vous avertir du traitement de votre commande.
    </h2>
    <?php 
  }
        
  else
  {
    echo'<h1>Une erreur s\'est produite durant la phase de paiement.</h1>
    <h2>Vous pouvez nous contacter par téléphone pour remédier au problème : 00 00 00 00 00.</h2>';
  }
}

autoresponse.php

De la même manière que dans le script call_response, verifiez si la variable $bank_response_code contient le code 00, et si oui, mettez à jour votre base de données pour confirmer que le paiement du client a bien été accepté.

Le call_autoresponse.php complet :

<!--
-------------------------------------------------------------
 Topic	 : Exemple PHP traitement de l'autoréponse de paiement
 Version : P615

 		Dans cet exemple, les données de la transaction	sont
		décryptées et sauvegardées dans un fichier log.

-------------------------------------------------------------
-->

<?php

// Récupération de la variable cryptée DATA
// $message="message=$HTTP_POST_VARS[DATA]";

// Attention, la variable $HTTP_POST_VARS n'existe plus dans les versions récentes de php
$message="message=$_POST[DATA]";

// Initialisation du chemin du fichier pathfile (à modifier)
//   ex :
//    -> Windows : $pathfile="pathfile=c:/repertoire/pathfile"
//    -> Unix    : $pathfile="pathfile=/home/repertoire/pathfile"
	    
$pathfile="pathfile=/homez.374/monsite/www/payment/pathfile";

// Initialisation du chemin de l'executable response (à modifier)
//ex :
//-> Windows : $path_bin = "c:/repertoire/bin/response"
//-> Unix    : $path_bin = "/home/repertoire/bin/response"

$path_bin = "/homez.374/monsite/www/payment/response";

// Appel du binaire response
$message = escapeshellcmd($message);
$result=exec("$path_bin $pathfile $message");

// Sortie de la fonction : !code!error!v1!v2!v3!...!v29
//- code=0	: la fonction retourne les données de la transaction dans les variables v1…
//		: Ces variables sont décrites dans le GUIDE DU PROGRAMMEUR
//- 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);

$code = $tableau[1];
$error = $tableau[2];
$merchant_id = $tableau[3];
$merchant_country = $tableau[4];
$amount = $tableau[5];
$transaction_id = $tableau[6];
$payment_means = $tableau[7];
$transmission_date= $tableau[8];
$payment_time = $tableau[9];
$payment_date = $tableau[10];
$response_code = $tableau[11];
$payment_certificate = $tableau[12];
$authorisation_id = $tableau[13];
$currency_code = $tableau[14];
$card_number = $tableau[15];
$cvv_flag = $tableau[16];
$cvv_response_code = $tableau[17];
$bank_response_code = $tableau[18];
$complementary_code = $tableau[19];
$complementary_info= $tableau[20];
$return_context = $tableau[21];
$caddie = $tableau[22];
$receipt_complement = $tableau[23];
$merchant_language = $tableau[24];
$language = $tableau[25];
$customer_id = $tableau[26];
$order_id = $tableau[27];
$customer_email = $tableau[28];
$customer_ip_address = $tableau[29];
$capture_day = $tableau[30];
$capture_mode = $tableau[31];
$data = $tableau[32];
$order_validity = $tableau[33];
$transaction_condition = $tableau[34];
$statement_reference = $tableau[35];
$card_validity = $tableau[36];
$score_value = $tableau[37];
$score_color = $tableau[38];
$score_info = $tableau[39];
$score_threshold = $tableau[40];
$score_profile = $tableau[41];


// Initialisation du chemin du fichier de log (à modifier)
//   ex :
//    -> Windows : $logfile="c:\repertoire\log\logfile.txt";
//    -> Unix    : $logfile="/home/repertoire/log/logfile.txt";

$logfile="/homez.374/monsite/www/payment/logfile.txt";

// Ouverture du fichier de log en append

$fp=fopen($logfile, "a");

// analyse du code retour

if (( $code == "" ) && ( $error == "" ) ) {
  fwrite($fp, "erreur appel response\n");
  print ("executable response non trouve $path_bin\n");
}

// Erreur, sauvegarde le message d'erreur

else if ( $code != 0 ) {
  fwrite($fp, " API call error.\n");
  fwrite($fp, "Error message :  $error\n");
}

else {
  // OK, Sauvegarde des champs de la réponse

  fwrite( $fp, "merchant_id : $merchant_id\n");
  fwrite( $fp, "merchant_country : $merchant_country\n");
  fwrite( $fp, "amount : $amount\n");
  fwrite( $fp, "transaction_id : $transaction_id\n");
  fwrite( $fp, "transmission_date: $transmission_date\n");
  fwrite( $fp, "payment_means: $payment_means\n");
  fwrite( $fp, "payment_time : $payment_time\n");
  fwrite( $fp, "payment_date : $payment_date\n");
  fwrite( $fp, "response_code : $response_code\n");
  fwrite( $fp, "payment_certificate : $payment_certificate\n");
  fwrite( $fp, "authorisation_id : $authorisation_id\n");
  fwrite( $fp, "currency_code : $currency_code\n");
  fwrite( $fp, "card_number : $card_number\n");
  fwrite( $fp, "cvv_flag: $cvv_flag\n");
  fwrite( $fp, "cvv_response_code: $cvv_response_code\n");
  fwrite( $fp, "bank_response_code: $bank_response_code\n");
  fwrite( $fp, "complementary_code: $complementary_code\n");
  fwrite( $fp, "complementary_info: $complementary_info\n");
  fwrite( $fp, "return_context: $return_context\n");
  fwrite( $fp, "caddie : $caddie\n");
  fwrite( $fp, "receipt_complement: $receipt_complement\n");
  fwrite( $fp, "merchant_language: $merchant_language\n");
  fwrite( $fp, "language: $language\n");
  fwrite( $fp, "customer_id: $customer_id\n");
  fwrite( $fp, "order_id: $order_id\n");
  fwrite( $fp, "customer_email: $customer_email\n");
  fwrite( $fp, "customer_ip_address: $customer_ip_address\n");
  fwrite( $fp, "capture_day: $capture_day\n");
  fwrite( $fp, "capture_mode: $capture_mode\n");
  fwrite( $fp, "data: $data\n");
  fwrite( $fp, "order_validity: $order_validity\n");
  fwrite( $fp, "transaction_condition: $transaction_condition\n");
  fwrite( $fp, "statement_reference: $statement_reference\n");
  fwrite( $fp, "card_validity: $card_validity\n");
  fwrite( $fp, "card_validity: $score_value\n");
  fwrite( $fp, "card_validity: $score_color\n");
  fwrite( $fp, "card_validity: $score_info\n");
  fwrite( $fp, "card_validity: $score_threshold\n");
  fwrite( $fp, "card_validity: $score_profile\n");
  fwrite( $fp, "-------------------------------------------n");
}

fclose ($fp);
	
if (!empty($bank_response_code) && $bank_response_code == 00) {		
  // Tout s'est bien passé, 
  // on valide donc le paiement et on effectue nos traitements en base de données	
}

Tester l’interface

Maintenant que nous avons fini de paramétrer l’interface, il faudrait la tester pour vérifier que tout fonctionne… Simulez donc un achat, cliquez sur une catrte bancaire, vous vous trouvez alors sur le serveur de test de la banque. Voici les codes de cartes pour opérer vos tests :

Numéro de CarteCode de réponse
497493412549780000 (paiement accepté)
497218761520505 (paiement refusé)
Cryptogrammeccv_response_code
6004D
6404D
65050
65353
64555

Si/quand tous vos tests sont couronnés de succès, vous pouvez passez à l’ultime étape avant la mise en production, direction la pré-production !

Passer en pré-production et en production

Note : comme le fait remarquer Nico dans les commentaires, à ce stade, pensez à désactiver le mode DEBUG.

Lorsque vous en arrivez là, le plus dur est fait. Pour pouvoir passer en production, il faut que vous ayez réussi au moins une transaction en pré-production. Les cartes utilisées seront cette fois-ci des cartes réelles, mais vous ne serez pas débité.

Pour passer en pré-production, vous devrez remplacer le certificat de test par votre certificat de commerçant délivré par la banque. Il vous faudra remplacer votre merchant_id dans le fichier call_request.php, télécharger le certificat de commerçant que la banque vous a délivrée, et changer le nom du fichier parmcom.014213245611111 par parmcom.xxxxxxxxxxxxxxx où xxxxxxxxxxxxxxx désigne votre merchant_id. Lorsque le test avec la vrai carte bancaire aura été concluant, il vous faudra imprimer le PV de recette et envoyer un Fax à votre banque pour qu’il passe votre API en production à la date et à l’heure que vous leur indiquerez.

Rappel : N’oubliez pas de transmettre vos logos par email au support technique pour qu’il les intègre sur le serveur de paiement. Ceci peut prendre un certain temps (un ou deux jours).

Puisque vous en êtes à installer une solution de paiement, avez-vous pensé à Paypal ? Même en complément d’une solution bancaire, Paypal est devenu incontournable. Comparé à la solution ATOS et quelque soit l’API choisie, Paypal est un jeux d’enfant à mettre en place. Voyez mon article sur l’intégration de Paypal IPN.

Dans un souci d’amélioration, je serai reconnaissant envers quiconque me signalera une erreur ou me fera part de suggestions.

Déjà 74 réponses, rejoignez la discussion !

  • Antoine

    dit  :

    Merci pour ce tuto !
    J’étais coincé depuis trois jours sur une page d’erreur, je ne voyais pas d’où ça pouvait venir. La lecture de ton tuto m’en a donné la réponse.
    C’est les joies de la programmation, un édifice s’effondre pour une virgule mal placée.

    A bientôt

  • Thierry A

    dit  :

    Bonjour,

    Super tuto sans lequel j’y serais encore !!!
    Pour info toutefois, si d’autres butent comme moi sur le message « erreur appel request », la méthode des chemins absolus comme:
    /homez.374/monsite/www/payment/certif
    n’a pas fonctionné pour moi (serveur mutu chez OVH pourtant)

    Ce qui a marché:
    http://forum.ovh.com/showpost.php?p=58623&postcount=7
    mais A CONDITION de ne pas utiliser cgi-bin comme nom de dossier !!!!
    on peut mettre n’importe quoi sauf ça !

    Il reste que les gens de chez ATOS doivent compter plein d’ingénieurs mais pas un ergonome ni un formateur pour pondre une doc aussi illisible (et fausse en plus)…

  • Buzut

    dit  :

    Copie du mail de Thierry
    *************************
    j’ai appliqué la solution du forum, sauf pour le chemin qui doit être à la racine du www et ne peut être nommé CGI-BIN. Je l’ai nommé payment et ça marche.
    L’api est en version 615.
    J’ai du mettre en 755 les fichiers request response ET pathfile.
    Enfin tous mes chemins absolus sont spécifiés avec la méthode: $path_bin = « ./request »;
    Je n’ai pas réussi avec les chemins du type $path_bin = ‘/homez.nnn/monsite/www/paiement/bin/glibc/request’;
    Depuis plus de soucis.

  • Buzut

    dit  :

    Bon en ce qui concerne la doc ATOS, il est vrai que c’est un modèle de lisibilité…

    En tout cas, je m’étonne de voir qu’une solution fonctionne chez l’un et pas chez l’autre et vice versa. D’autant plus chez le même hébergeur avec le même type d’hébergement ! Le tuto a été mis à jour dans la partie call_request.php, les deux procédures sont donc expliquées, si l’une ne marche pas, testez l’autre ;)

  • The_Legacy

    dit  :

    Bonjour,

    Merci pour ce tuto qui m’a permis de dépanner une copine qui bosse sur OSCommerce et tente de faire fonctionner le paiement carte bleue de sogenactif en utilisant ATOS.
    J’ai bien réussi à faire fonctionner votre script call_request.php (j’ai bien la page débug avec les informations et les logos des cartes à la fin pour accéder à la page de paiement) cependant, une fois dans oscommerce, impossible d’obtenir le résultat attendu.
    Le résultat est toujours une erreur de chiffrement (cryptage) de la requête.
    Est-ce que vous auriez une idée ?

    Merci d’avance.

  • Buzut

    dit  :

    Ne connaissant OScommerce que de nom, je n’ai pas spécialement d’idée sur l’origine du problème.

    Vous avez donc un message d’erreur ? Quel est-il exactement ? Avez-vous un code d’erreur aussi ? Enfin, avec oscommerce, ATOS s’intègre par un plugin ou est-ce que le processus de paiement est programmé manuellement ?

    • The_Legacy

      dit  :

      Re bonjour,

      merci de votre réponse rapide.
      Voici le début du message que j’obtiens :

      (Lors du paiement l’erreur suivante s’est produite dans le chiffrement (cryptage) de la requete Erreur = API ERRORError reading merchant parameters definition (/homez.490/agrilois/www/Boutique_2.3/catalog/atos/parmcom.php) Verifier les chemins dans le module ATOS, les fichiers et les autorisations dans le dossier ATOS, les fichiers request et response doivent etre des executables et avoir les permissions d’executionL’erreur s’est produite dans cette page (checkout_confirmation.php)SERVER …

      Le reste du message liste surtout les variables globales du $_SERVER.

      Il n’y a pas d’erreur spécifique désignée.

      Cordialement

    • The_Legacy

      dit  :

      Et pour compléter ma réponse, ATOS s’intègre par un module sur la page d’administration avec un paramétrage permettant d’indiquer l’emplacement des binaires et les informations pour identifier les fichiers commerçants.
      Le tout est identique au fichier pathfile utilisé avec votre call_request.
      Le module semble fonctionnel, mais à l’arrivée à la dernière étape, il y a un message qui dit que le paiement carte bleue n’est pas disponible et du coup il n’y a pas d’affichage des logos des cartes.
      Ca reste assez abstrait surtout que les différents services se rejettent la balle (OVH, ATOS, …) et la doc d’ATOS n’est pas ce qu’il y a de plus explicite …

  • Buzut

    dit  :

    Assez évasif comme message d’erreur, et en ce qui concerne la doc d’ATOS, tout le monde est du même avis sur ce point, elle n’est pas d’une grande aide.

    Concernant votre erreur, je ne peux que vous conseiller de tester tous vos chemins avec la fonction file_exists(), comme ça vous éliminerez toute erreur potentielle de ce côté là.

    D’autre part, j’ai constaté sur les serveurs d’OVH que certains CHMOD trop permissifs ne passent pas. Essayez donc le 705, il me semble que même le 755 me provoquait une erreur qui m’a laissé bloqué un bout de temps avant que je n’en trouve l’origine.

  • Manbar

    dit  :

    Salut,
    j’ai tout fait comme il faut je pense (ça marche sur un serveur web que j’héberge chez moi), par contre quand je mets tout chez ovh, l’url de reponse automatique (call_autoresponse.php) n’est jamais appelé… aprés contact avec la banque/atos, atos dit que l’url ne répond pas, qu’elle n’est pas accessible…. pourtant quand je tape directement l’url dans le navigateur, ça marche nickel…. Ca viendrait donc du fait que le serveur http d’atos n’arrive pas à joindre l’url sur le serveur mutualisé d’OVH… je sais plus koi faire
    Merci

      • Buzut

        dit  :

        désolé, j’avais complètement zappé ta question !

        Le pare feu d’OVH, qui bloquait donc pas les appels directement via ton navigateur mais qui bloquait les appels du serveur d’ATOS ? Alors ça c’est bizarre !!

        Une chance que tu ais trouvé l’origine du problème…

  • Jean-Louis

    dit  :

    Bonsoir,

    J’ai moi même un gros souci sous joomla 2.5.8 / Virtuemart 2.018a avec le plugin SIPS ATOS pour merc@net chez BNP, sur un serveur mutu de OVH (le parefeu applicatif est off)

    Impossible pour le plugin de lire le fichier pathfile (j’ai essayer en le mettant le dossier param à la racine ou à l’intérieur du dossier www/, et avec les droits 755 ou 705) mais rien n’y fait le fichier pathfile ne veut pas être lu…

    Quelqu’un à une piste ? une idée ? un commentaire ?

    Merci d’avance.

  • Loic

    dit  :

    Bonjour,

    merci pour votre temps et pour ce tutoriel bien ficelé et d’une grande utilité.
    C’est quand même affolant de devoir compter sur la bonne volonté de certains internaute alors qu’il s’agit d’un outil développé par ATOS, pas par le petit artisan du coin… bref :)
    Au passage, une petite précision, il faut forcer le type de transfert de son client FTP en mode binaire (pour filezilla : menus Transfert/Type de transfert)

  • Loic

    dit  :

    Un autre petit commentaire afin d’apporter aussi mon retour sur expérience. Pour la génération de l’identifiant de transaction dans le fichier call_resquest.
    Attention, la multiplication par 0 n’est absolument pas apprécié par le script.
    transactionID = time() * rand (0,10);

    Pour cette variable, quand on se référe au dictionnaire des données, il est noté qu’elle doit être de 6 chiffres maximum. Voici comment j’ai procédé afin de garantir d’avantage que l’id de transaction soit unique :
    $transactionID = time() * rand (1,99);
    $transactionID = substr($transactionID , -6);

    On multiplie donc time entre 1 et 99 et on garde les 6 derniers chiffres.

    • Buzut

      dit  :

      Bonjour et merci de ces retours !

      C’est tout à fait exact en ce qui concerne transactionID = time() * rand (0,10);
      Multiplier par 0 n’est pas une très bonne chose. Car même si il ne me semble pas que le 0 pose problème au niveau du script en tant que tel (le transactionID est compris entre 0 et 999999), cependant, n’importe quel timestamp * 0 étant égal à 0, ce n’est pas la meilleur manière d’obtenir un transactionID unique…

      Je mets donc l’article à jour !

  • JSGA

    dit  :

    Bonjour,
    Une petit remarque par rapport à votre exemple de traitement du retour : à lire la doc il faut vérifier « response_code » et non « bank_response_code » car (doc Socgen « dictionnaire de données ») – page 72) :

    « Le champ response_code est le résultat de la combinaison du bank_response_code et du cvv_response_code. C’est donc ce code qu’il faut analyser pour vérifier que le paiement est accepté ou pas. »

    Bonne continuation.

  • Leroi

    dit  :

    Bonjour,

    Et bravo pour le tuto, il est super bien fait…

    J’avais déjà installé des kits Atos che OVH pour d’autres banques avec + ou – de facilité mais là je tombe sur un hic !!!

    Le call_request de Sogenactif ne trouve pas le request et pourtant le fichier y est je vérifié et Rererere-vérifier y compris avec file exists et realpath… J’ai essayé à peu près toutes les combinaisons de chmod et de mettre ./pathfile et ./request comme expliqué plus haut rien n’y fait…

    J’ai un ticket (c le cas de le dire) en cours che OVH et j’ai envoyé les fichiers à Sogenacif Atos…

    Si quelqu’un a plus d’info je suis preneur…

    Encore merci pour cette page

    Cordialement,

    JF Leroi

    • Philippe B

      dit  :

      Bonjour,
      Je suis webmaster d’une association avec un paiement Sogenactif.
      Je suis en train d’améliorer le formulaire de don.
      J’ai donc fait des modif sur le serveur paisec.ovh.net.
      J’ai remis les anciens fichiers mais ça ne marche plus.
      J’ai une erreur Erreur dans l’appel de l’API sans autre explication.
      Le sips_request retourne une chaine vide.
      Que dois-je vérifier ?

      Merci d’avance.

      • Buzut

        dit  :

        Tu passes par le serveur paisec.ovh.net ? Donc tous les fichiers ne sont pas sur ton serveur à toi ?
        je ne sais pas trop comment fonctionne ce serveur intermédiaire, cependant, je te conseille de d’abord vérifier tous les droits et les propriétaires (et groupes) des fichiers. Si tu as remis les mêmes sans rien modifier d’autre et que ça ne marche plus, ça vient probablement de là !

          • Loic

            dit  :

            La solution à ton problème était déjà dans les commentaires :)
            « Au passage, une petite précision, il faut forcer le type de transfert de son client FTP en mode binaire (pour filezilla : menus Transfert/Type de transfert) »

    • Buzut

      dit  :

      Bonjour,

      je ne sais pas si tu as résolu ton problème entre temps… Cela pourrait venir des exécutables qui ne sont pas les bons glibc vs static, regarde ça de plus près !

  • MZVTC

    dit  :

    Bonjour,

    J’ai suivi le doc sogenactif pour installer le service de paiement mais j’ai a la fin « erreur appel request » – « executable request non trouvé… »!!!
    alors que tous mes fichiers existent.
    j’ai suivi aussi votre tuto et j’ai la même erreur a la fin.

    Si vous pouvez m’aider :)

    Merci

  • MZVTC

    dit  :

    Merci j’ai trouvé d’ou viens le souci.
    j’ai utilisé les fichiers bin request et reponse de dossier static.

    j’ai la version 2.11.3 de glibc sur le serveur OVH
    alors que l’api téléchargé contient les fichiers compatible avec l

  • MZVTC

    dit  :

    Merci j’ai trouvé d’ou viens le souci.
    j’ai utilisé les fichiers bin request et reponse de dossier static.

    j’ai la version 2.11.3 de glibc sur le serveur OVH
    alors que l’api téléchargé contient des fichiers compatible avec la version 2.5 de glibc!!

    je ne comprends pourquoi ça ne marche pas avec la version 2.11.3!!

  • Yodex

    dit  :

    Bonjour à tous,
    Merci beaucoup pour cette explication, elle est vraiment d’une grande aide.

    J’ai juste une petite question par rapport à cette phrase :
    « Néanmoins, c’est cet identifiant qui servira à savoir quel est le client dont vous venez de recevoir le paiement : pensez donc que si cet identifiant figure en double dans votre base, c’est forcement du plus récent qu’il s’agit. Vous pouvez sélectionner celui qui a l’ID (primary index) le plus grand. »

    Si j’ai bien compris le reste, on doit pouvoir envoyé des données persos lors de l’envoi de la requête de paiement, par exemple order_id.
    Ces données persos peuvent être récupérées par le tableau de retour dans l’auto_response.
    Du coup au lieu d’utiliser le transaction_id, on doit pouvoir utilisé cet order_id, généré chez moi par la base de données en AUTOINCREMENT, pour identifier quelle commande vient d’être payée, non ?

    • Buzut

      dit  :

      Oui tout à fait ! En revanche, cette variable ne peut pas prendre n’importe quels paramètres (je crois que c’est un int jusqu’à 6 caractères)… Mais dans la mesure où tu respectes cela, c’est tout bon !

  • Yodex

    dit  :

    Je me permet une autre question.

    Je n’ai pas le dossier test_template, il n’est pas disponible en téléchargement sur le site sogénactif (là où on télécharge l’API).

    Je pourrais refaire le fichier template, mais il y a normalement 2 autres fichiers fournis : cryptogramme.fr.html et test_template.exe

    Savez-vous où je pourrais trouver ce dossier ou ces 2 fichiers ?

    Merci !

    • Buzut

      dit  :

      Salut Yodex,

      réponse un peu tardive…
      Je ne parle nulle part de dossier test_template, ni d’ailleurs de cryptogramme.fr.html

      Peut-être sont-ce des spécificités à windiws serveur, en tout cas, ce n’est pas sur mon tuto que tu as vu ça !

  • DEVontheWAVE

    dit  :

    Bonjour,

    Merci beaucoup pour votre travail sur cette API.

    Vous m’avez fait économiser des nuits de sommeil!!

    Conseils à ceux qui s’y colle ( la ou moi j’ai buté ):

    – Bien mettre les fichiers de type call_xxxx à la racine comme c’est précisé dans le tuto. moi j’avais oubié.
    – Prendre la bonne version de l’API sinon le « erreur request » ne s’en va pas. Moi j’avais pris la 32b ou lieu de la 64b
    – Bien changer les CHMOD ( droit d’écriture des fichiers )
    Quand j’ai téléchargé la nouvelle version 64b, j’avais oublié de les changer…

    Ps: il me reste des cheveux.

    Bon courage !

  • Lomic

    dit  :

    Bonsoir,

    je suis en train de mettre en place cette API et tout roule bien à l’exception de la connexion à la base de données, dès que j’essaye d’initier une connexion, l’autoresponse par en sucette et je n’ai rien dans le log. Quelle que soit la façon d’établir la connexion. Je ne sais plus par quel bout le prendre.

    Si je ne mets rien pour me connecter et requêter la base, autoresponse tourne bien, et j’ai toutes les infos sur la transaction dans le log.

    Lomic

    • Buzut

      dit  :

      Salut Lomic,

      Ça me parait vraiment très bizarre que le fait de requêter la BDD fasse bugger l’autoresponse. Tu as tenté les forums de développez.com (ou stackoverflow si tu parles anglais) à tout hasard en y postant ton code ?

  • webbud

    dit  :

    Bonjour,
    J’espère que tout cela est encore d’actualité.
    En tout cas merci pour ce tutoriel.
    Mon souci concerne la structure de la table à créer en base de données.
    D’après la requête sql ci-dessus (en fichier call_autoresponse.php) je dois créer une table « paiements » avec les champs ID, transactionID, paiement_status.
    Mais qu’en est-il du champ achats.ID ? La syntaxe n’est-elle pas incorrecte, ne s’agit-il pas plutôt de « achatsID », sans le point ? De même d’ailleurs pour le libellé « achats_u.ID ».
    Merci de votre retour.
    Cordialement

    • Buzut

      dit  :

      Bonsoir,

      Oui ce tuto est encore d’actualité.

      Il y avait un petit problème dans la requête SQL, je m’étais emmêlé les pinceaux en la copiant. Elle est maintenant corrigée et fonctionnelle.

      Quoi qu’il en soit, l’organisation et le nommage de votre table est à votre entière discrétion ;)

  • Cousino

    dit  :

    merci Buzut… me suis bien bien fait suer pour installer ce machin, dans mon cas, serveur mutu 1and1, il fallait mettre les fichiers request et response contenu dans le dossier bin, les fichiers sont aussi en chmod 705 ainsi que le pathfile… mais je n’ai pas verifié si ça marchait en 755 ou en 604 le chmod d’origine… ouf ouf dit le chameau, en même temps, on devrait les appeler directement ça les encouragerait à changer leur doc pourri…. bonne continuation….

  • Cedric

    dit  :

    Bonjour,

    Déjà un grand merci pour ce tuto, car moi qui suit autodidacte, je peut vous dire que c’est parfaitement ce qu’il me fallait !

    Donc en suivant le tuto, tout c’est bien passé.
    Les test avec les cartes factices sont impeccables !

    Seulement dés que je clic que le bouton de retour à la boutique, il me renvoi sur le call_response.php avec une belle erreur …
    =======================================================
    Erreur appel API de paiement.
    message erreur : Invalid Keyword in parameter (./payment/pathfile)
    =======================================================

    J’ai beau tout relire, je vois pas le problème …

    Idem pour le fichier log, j’ai ceci qui ce passe dés que je clic sur le bouton de la validation du paiement apres avoir écris le numéro de carte bleu :
    =======================================================
    Error message : API ERROR Error get DATA response parameter (wrong length)
    =======================================================

    Me manque t’il quelque chose ?

    Merci !!!! :D

  • Buzut

    dit  :

    N’y a-t-il rien d’anormal dans ton pathfile ? L’api n’affectionne pas particulièrement les espaces blancs ou les caractères accentués.
    C’est la première chose que je vérifierai. Tiens nous au courant de tes avancées !

    • Buzut

      dit  :

      Merci pour cet éclaircissement et mise en garde Taha. Cependant, le but est de garder ces informations confidentielles, or le robot.txt est public et il suffit donc de le parcourir pour connaître l’emplacement du fichier log.txt.
      Je prendrai plutôt le parti d’une approche où les fichiers call_request, call_response et call_autoresponse sont à la racine. Cela permet de les appeler avec des urls du type : http://www.monsite.fr/call_request.php. En parallèle, placer les exécutables, le pathfile et le fichier de log dans un sous-dossier non public (on peut aussi nommer son fichier de log autrement que log.txt).

  • Cedric

    dit  :

    Hello,

    Rien à faire …
    J’ai toujours le meme message d’erreur.
    J’ai également appelé la hotline qui m’a dit de vérifier les chemins de pathfile et response dans mon call_response.php
    Tout est ok …

    Par ailleurs je n’ai pas compris comment on log pour savoir qui a payé ou pas :/

  • Cedric

    dit  :

    Ok trouvé !
    J’avais deux erreur :
    1) Dans call_response.php la ligne
    « $pathfile= »pathfile=./payment/pathfile »; »
    était avant correction $pathfile= »./payment/pathfile »;

    2) Une autre erreur est survenu ensuite : « error get data response parameter (wrong length) »
    J’ai donc remplacé
    « $message= »message=$HTTP_POST_VARS[DATA] »; »
    par « $message= »message=$_POST[DATA] »; »

    A priori ça dépend des configurations du serveur pour récupérer les variables post.

    Enfin j’ai modifié tout ca et dans le fichier call_autoresponse et call_response

    • Buzut

      dit  :

      Bonsoir Cédric,

      Content que tu aies pu trouver la source de ton problème !

      Par ailleurs, pour répondre à ta question « comment on log pour savoir qui a payé ou pas ».

      J’ai modifié un peu l’article pour rendre ça plus clair dans la partie sur le call_request. Dis moi si tu comprends mieux !

      • Cedric

        dit  :

        Bonjour et merci beaucoup pour ton aide ! :)

        Alors pour le suivi, je vois bien des infos dans les logs. (merchand id, transactions id, etc …)
        Mais rien sur l’identité de la personne.

        Je crois qu’ou je pèche c’est ici : « Vous trouverez ci-dessous l’intégralité de la partie métier du call_request. Pensez bien que pour des raisons de brièveté, je n’inclue ici pas l’intégralité du html. Cependant, n’oubliez pas de servir une page html valide à vos clients ! »

        Il doit me manquer du code pour que le client rentre ces valeurs.

        Je m’explique, il s’agit d’un site pour organiser une conférence payante.
        Il y a deux tarifs suivant le public.
        L’idée est d’avoir les coordonnées de la personnes, et le choix du montant, ainsi que la validation du paiement ou non.

        J’ai quelques infos dans les logs, mais pas l’identité …
        Il doit bien me manquer une page html pour saisir ces infos …

        Moi qui n’ai jamais fait de formulaire, me voila servie xD

        • Buzut

          dit  :

          Mon article ne concerne vraiment que la partie paiement. Je pars en fait du postulat que tout ce qui gravite autour du paiement est acquis.

          Le fichier de log ne doit normalement te servir que pour conserver une trace des transactions et pour la recherche de bug.

          Voici comment tu dois procéder :
          – avant même d’arriver sur la page call_request, tu dois avoir un formulaire qui récupère les informations nécessaires (tu décides des infos, typiquement nom, prénom, adresse, email, email, tel).
          – à la validation du formulaire, celui-ci doit transmettre les infos à call_request avec le prix,
          – au niveau du call_request, tu dois enregistrer toutes ces infos dans une base de donnée et bien l’associer avec le order_id que tu génères sur cette page (c’est le seul moyen de lier la transaction à ton client)
          – lorsque le call_autoresponse est appelé par le serveur de la banque, il te retourne pleins d’infos, dont le order_id, là, si le paiement est bien passé, tu mets à jour ta base de données (tu peux utiliser une colonne payment_status qui vaut 0 ou false par défaut) et tu le passes donc à 1 ou true si le paiement s’est bien déroulé.

          La banque ne retourne pas d’informations sur l’identité du client. C’est à toi de les récolter, de les enregistrer et de faire le lien via le order_id (ou le transaction_id mais c’est moins flexible).

          • Cedric

            dit  :

            Merci Buzut !

            Tout fonctionne nickel maintenant !
            A part forcement une chose … (sinon ça serait pas intéressant) ;)

            Si je me met à la place du client, et que je ferme le navigateur plutôt que de cliquer sur retour boutique (qui ramène à call_response.php).
            La BDD est bien alimentée automatiquement par la commande SQL dans l’autoresponse, mais je n’ai pas de validation sur le site de ma conférence.

            Je m’explique, dans le fichier response, j’ai mis un SELECT des infos nécessaires pour le site de la conf, puis je l’envois par form/post automatiquement. (le submit est en auto via javascript)
            Via cette page de response, je suis donc redirigé vers le site de la conf avec l’envois des données qu’ils attendent.

            Mais dans l’autoresponse, cette méthode d’envois ne fonctionne pas …

            Aurais je oublié quelque chose ?

            Si cette question n’est pas dans le thème de l’article, il n’y a pas de soucis ;)
            Je continuerais à chercher, je trouverais bien :)

  • Gilles

    dit  :

    Super tuto qui marche parfaitement.

    J’ai juste un soucis pour l’enregistrement du code reponse de la banque.

    J’ai mis mon code a la fin du fichier call_autoresponse mais cela n’enregistre pas je ne sais pas s’il ne faut pas enlever l’inscription dans le log.txt qui lui marche.

    En tout cas merci !

  • achem

    dit  :

    bonjour, et déjà bravo pour ce tuto clair et agréable à lire.

    pour ma part je voudrais installer cette solution sur un site que je développe (php/apache) mais pour lequel je n’ai pas encore de client qui pourrait me fournir un dossier qui lui aurait été donné par sa banque.

    Existe t-il un moyen d’installer un package standard et qu’il suffirait de paramètrer avec les bonnes informations client une fois qu’un client me les aura fourni ?

    merci

    • Buzut

      dit  :

      Bonjour achem,

      Je ne sais pas trop s’il est possible d’installer de package standard. D’autant plus que quelques détails changeront selon la banque du client (sogenactif, mercanet…). Le mieux est encore de vous adresser directement à ATOS je pense.

  • RT

    dit  :

    Un des tutoriels les plus clairs que j’aie pu lire sur le sujet. Chapeau !

    Une petite remarque, par contre : se limiter à la seule condition du $bank_response_code manque un peu de précision et peut s’avérer limitant.
    La documentation d’Atos sur les codes de réponse (renvoyés par la banque d’une part, et par Atos d’autre part) est plutôt fournie (et claire, contrairement au reste de leur documentation) et, en fonction du client pour qui la solution Atos SIPS est implémentée, on appréciera une validation un peu plus « poussée ». Par exemple, gérer le cas d’une commande annulée, d’un forçage, d’une fraude supposée (qui peut être considérée comme paiement accepté dans certains cas), ou encore d’un refus. Ce sont des cas qui méritent aussi d’être prévus et enregistrés en DB, tout cela par simple validation des $response_code et $bank_response_code.

    Si les commerçants disposent d’une UI chez Atos pour les opérations de caisse et autres, gérer autant de cas que possible dans le back-end des boutiques reste une nécessité pour assurer un bon suivi des commandes. Après tout, nos chers clients commerçants se réfèrent surtout à l’admin de leur boutique.

  • Myriam

    dit  :

    Bonjour,
    Merci pour ce tuto, il m’a beaucoup aidé.
    Cependant, moi j’ai un souci bizarre. Je n’ai pas de message d’erreur, juste les cartes bleues ne s’affichent pas.
    J’ai installé atos 615 sur linux. Lorsque je mets des tests sur mes variables et mes chemins, ils sont corrects. Lorsque je mets un message quelconque au dessus de la $message après avec faire exec sur request. Il apparaît mais pas le lien vers les cartes bleues!! Je m’arrache les cheveux. Avez-vous déjà rencontré ce type de problème ?

  • Tibo

    dit  :

    Juste un témoignage pour vous dire comment j’y suis arrivé.

    Je suis sur un OVH mutualisé ( Linux 64bits) . Après m’être rendu chèvre pendant un long moment avec l’erreur « erreur appel request » alors que mes urls étaient bonnes. J’ai fini par envoyer tout le contenu ATOS en binaire avec FileZilla (Transfert -> Type de transfert) puis mis les permissions des 2 exe à 755 et là miracle !

    • Buzut

      dit  :

      Merci pour ton témoignage Tibo.

      Il arrive souvent que les fichiers soit altérés quand ils ne sont pas transférés en mode binaire, c’est une des principales causes de problèmes avec les droits des fichiers!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *