Installation de l’API PHP 615 ATOS (sogenactif)

installer 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 !

Plan du tutoriel

  1. Les préparatifs
  2. Configuration des fichiers
  3. Les scripts PHP
  4. Tests de l’interface
  5. Passer en pré-production puis en production

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

Mon premier coup de fil au support technique n’aura pas plus tardé. En effet, dans la colonne « Action » devraient se trouver des petits logos, l’un permettant de télécharger l’API, l’autre la doc correspondante. Chez moi, ça ne s’affiche qu’au survol de la souris, fallait le savoir ! Bon, je télécharge donc l’API PHP sogenactif_p615_PLUGIN_linux-2.6.9.tar, il y en a deux pareil, ne me demandez pas pourquoi…

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 ». Et 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 donc 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’) ;
?>

Tant que vous y êtes, 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 elle a besoin pour fonctionner. Elle 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 champs 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 après
  • 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 php call_response.php que nous aborderons ensuite.
###############################################################################
#
#	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 néanmoins les placer dans un autre répertoire de votre choix, cependant, la démarche est plus simple comme cela. C’est donc ainsi que nous procéderons.

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. A 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, '', ' ');

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

Vous n’avez ici qu’a renseigner le chemin absolu (attention chemin physique pas internet) de votre fichier pathfile. Utilisez chemin.php comme nous l’avons vu précédemment.

//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é
$parm="$parm transaction_id=123456";

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); 

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, la seule donnée permettant d’identifier votre client que le serveur vous retournera, sera le transaction_id. C’est pourquoi il faut tout 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é…
La bonne méthode consiste donc à enregistrer toutes les informations utiles concernant votre client, et de mettre à jour la table ensuite pour confirmer le paiement. Le transaction_id n’est pas obligatoirement unique puisqu’il n’existe que 999 999 possibilités. 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.

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 donc cette page ne sera jamais appelé, il est donc 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 donc ici de renseigner les variables indispensables. A 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, donc aucune difficulté.

// 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 :

<?php
// 00 confirme le succès du paiement
//Nous vérifions donc que la variable existe 
//et qu'elle contient 00
if (!empty($bank_response_code) && $bank_response_code == 00)
   {
//si c'est le cas, nous affichons un message de remerciement
?>
	<div id="breadcrumb">
	<h1>Confirmation payement</h1>
	</div>
	<p><img src="img/progress-bar5.gif" /></p>
	<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 
		
   }
//Si la variable n'existe pas ou contient un autre code
//il y a eu un problème et on invite le client à appeler
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>';
   }
?>

Pour en savoir plus sur les codes d’erreur, vous savez où chercher. Notez qu’il est bien entendu possible d’afficher différents messages en fonction de l’erreur rencontrée. Je n’en vois pas tellement l’utilitée, mais libre à vous…

Autoresponse.php

Ce script php nous sera très utile car il sera automatiquement appelé par le serveur de la banque à chaque fois qu’un paiement est initié, qu’il soit réussi ou non. C’est donc ici que nous effectuerons nos traitements de base de données.

Les chemins à renseigner sont exactement les mêmes que dans call_response, reportez vous à l’exemple ci-dessus si vous ne vous souvenez plus comment renseigner les champs pathfile et response. Cependant, le script call_autoresponse enregistre automatiquement toutes les informations de la transaction dans un fichier de log. Il faut donc lui dire où se trouve ce fichier.

Créez donc un fichier texte sur votre serveur et donnez lui les droits en écriture. Indiquez son chemin dans la variable $logfile et le script se chargera d’y consigner les informations de transaction. Pratique si, comme moi, vous n’enregistrez pas les erreurs dans la base de données, ou ci cette dernière venait à être momentanément indisponible.

//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/socgen.txt";

Enfin, comme 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é.

Exemple d’un 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]";

// 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 responsen");
  print ("executable response non trouve $path_binn");
 }

//	Erreur, sauvegarde le message d'erreur

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

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

  fwrite( $fp, "merchant_id : $merchant_idn");
  fwrite( $fp, "merchant_country : $merchant_countryn");
  fwrite( $fp, "amount : $amountn");
  fwrite( $fp, "transaction_id : $transaction_idn");
  fwrite( $fp, "transmission_date: $transmission_daten");
  fwrite( $fp, "payment_means: $payment_meansn");
  fwrite( $fp, "payment_time : $payment_timen");
  fwrite( $fp, "payment_date : $payment_daten");
  fwrite( $fp, "response_code : $response_coden");
  fwrite( $fp, "payment_certificate : $payment_certificaten");
  fwrite( $fp, "authorisation_id : $authorisation_idn");
  fwrite( $fp, "currency_code : $currency_coden");
  fwrite( $fp, "card_number : $card_numbern");
  fwrite( $fp, "cvv_flag: $cvv_flagn");
  fwrite( $fp, "cvv_response_code: $cvv_response_coden");
  fwrite( $fp, "bank_response_code: $bank_response_coden");
  fwrite( $fp, "complementary_code: $complementary_coden");
  fwrite( $fp, "complementary_info: $complementary_infon");
  fwrite( $fp, "return_context: $return_contextn");
  fwrite( $fp, "caddie : $caddien");
  fwrite( $fp, "receipt_complement: $receipt_complementn");
  fwrite( $fp, "merchant_language: $merchant_languagen");
  fwrite( $fp, "language: $languagen");
  fwrite( $fp, "customer_id: $customer_idn");
  fwrite( $fp, "order_id: $order_idn");
  fwrite( $fp, "customer_email: $customer_emailn");
  fwrite( $fp, "customer_ip_address: $customer_ip_addressn");
  fwrite( $fp, "capture_day: $capture_dayn");
  fwrite( $fp, "capture_mode: $capture_moden");
  fwrite( $fp, "data: $datan");
  fwrite( $fp, "order_validity: $order_validityn");
  fwrite( $fp, "transaction_condition: $transaction_conditionn");
  fwrite( $fp, "statement_reference: $statement_referencen");
  fwrite( $fp, "card_validity: $card_validityn");
  fwrite( $fp, "card_validity: $score_valuen");
  fwrite( $fp, "card_validity: $score_colorn");
  fwrite( $fp, "card_validity: $score_infon");
  fwrite( $fp, "card_validity: $score_thresholdn");
  fwrite( $fp, "card_validity: $score_profilen");
  fwrite( $fp, "-------------------------------------------n");
 }

fclose ($fp);
	
if (!empty($bank_response_code) && $bank_response_code == 00)
 {
			
  //c'est ici qu'on sélectionne notre client pour confirmer son paiement			
  try
   {
    $pdo_options[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION;
    $bdd = new PDO('mysql:host=host;dbname=basename', 'login', 'pass', $pdo_options);
			
			
    //on s'assure que $transaction_id est un int
    $transaction_id = (int)$transaction_id;
 
    //On sélectionne les lignes correspondantes à notre transaction_id 
   //s'il y en a plusieurs celui ayant le plus grand ID est le bon		
    $req=$bdd->exec('UPDATE paiements, 
    (SELECT MAX(ID) AS ID FROM paiements GROUP BY transactionID) paiements_u
    SET paiement_status = 'paiement ok'
    WHERE achats.ID = achats_u.ID
    AND transactionID = ''.$transaction_id. ''');
   }
		
  // si une erreur se produit lors des opération de base de données, 
  //on stop le script et on affiche les erreurs
   catch (Exception $e)
   {
    die('erreur:' .$e->getMessage());	
   }
			
		
  }
		



?>

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 Carte Code de réponse
4974934125497800 00 (paiement accepté)
4972187615205 05 (paiement refusé)
Cryptogramme ccv_response_code
600 4D
640 4D
650 50
653 53
645 55

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).

Bonne chance dans le e-commerce !

Je tiens à remercier Thierry Godin, que je ne connais pas, mais qui a publié un tutoriel sur l’API Atos 600. Bien que portant sur une API différente, son travail m’a fourni un bon support d’aide.

L’illustration des pièces a été prise sur flickR CCkiki99.

Dans un souci d’amélioration, je serai reconnaissant envers quiconque me signalera une erreur ou me fera part de suggestions. Je répondrai bien entendu aux questions.

46 réponses à “Installation de l’API PHP 615 ATOS (sogenactif)”

  1. 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

  2. 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)…

  3. 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.

  4. 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 ;)

  5. DAIRE F dit :

    savez vous s il existe une version compatible windows 64 bits?

  6. 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.

  7. 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 …

  8. 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.

  9. Toufik dit :

    Très bon travail chef.
    Vous m’avez aidé

  10. Nico dit :

    Bonjour,
    Avant tout MERCI :)
    Et un petit detail pour le passage en-pré prod ne pas oublié de désactiver le debug !

  11. 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

    • Manbar dit :

      bon c’est résolu, c’était le par-feu applicatif d’ovh sur le site qui bloquait…..

      • 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…

  12. 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.

  13. 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)

  14. 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 !

  15. Claire dit :

    Bravo pour ce tuto, mais au bout de quelques lignes, j’ai déjà perdu le fil, entre les infos de Atos et l’hébergeur de mon site….au secours!

  16. 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.

  17. 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à !

        • Philippe B dit :

          Bonjour,
          En fait, j’ai trouvé la solution.
          Il faut transférer les fichiers sips en mode binaire avec le client FTP.
          Merci de ton aide.

          • 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 !

  18. 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

  19. 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

  20. 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!!

  21. 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 !

  22. 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 !

  23. 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 !

  24. 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 ?

Laisser un commentaire