I. Présentation générale du processus

Ogone est une société d'origine belge, mais qui possède des succursales dans les principaux pays d'Europe. Son rôle est de servir d'intermédiaire entre le site marchand et les différentes institutions financières (banques et organismes de crédit) propres à chaque pays. Pour le programmeur, l'avantage est énorme : plutôt que de devoir développer une interface pour chaque moyen de paiement qu'il souhaite offrir à sa clientèle, une intégration unique suffit.

Image non disponible

Une fois la commande effectuée sur le site marchand (le plus souvent via un panier virtuel), le client est redirigé de manière transparente (par le biais d'un simple formulaire HTML) sur le site d'Ogone où il pourra choisir un moyen de paiement et effectuer la transaction. Ogone le renvoie ensuite automatiquement sur le site marchand qui pourra lui afficher le statut de sa commande (paiement réussi, échoué ou annulé) et entreprendre les actions appropriées (enregistrement dans une base de données, envoi d'un e-mail de confirmation, etc.).

Voici le schéma des étapes du processus de paiement et les configurations à effectuer de la part du commerçant dans la colonne de droite :

Image non disponible

Pour bien comprendre le mécanisme, il faut savoir que le basculement vers Ogone s'effectue via le bouton submit d'un formulaire GET ou POST du site marchand, dont l'action est une page du serveur d'Ogone. Concrètement, une fois le panier complété sur le site de vente en ligne, celui-ci présente au client une page confirmant les détails de sa commande au bas de laquelle se trouve un formulaire avec des champs cachés (<input type="hidden">) et un bouton submit qui pointe sur Ogone. Les champs cachés contiennent en fait les paramètres du paiement tels que la somme totale, la devise (l'euro), le code d'identification du marchand, etc. Quand l'acheteur clique sur le bouton submit, le client se retrouve sur une page d'Ogone où il peut effectuer son paiement. Le serveur d'Ogone va alors communiquer avec le site marchand via une requête HTTP POST (référencée sous le terme « requête postsale » dans la documentation officielle) pour valider la transaction et fournir le résultat du paiement (réussite, échec ou annulation). Cette opération est transparente pour le client. La page d'Ogone affiche ensuite le statut du paiement et propose une redirection automatique vers une page HTML spécifique du site marchand.

Comme vous pouvez le remarquer sur le schéma, certaines étapes sont facultatives : il s'agit soit de tâches de contrôle, soit de personnalisation de l'affichage. Cet article se base sur une expérience réelle de site d'e-commerce, où j'ai mis la priorité sur la sécurité. J'aborderai donc, outre les étapes de base, les trois étapes supplémentaires suivantes :

  • phase de contrôle de la transaction en illustrant les deux méthodes possibles (signature SHA-1 et envoi d'une page de pseudoxml) ;
  • page "postsale" pour stocker dans la base de données du vendeur le résultat de la transaction renvoyé par Ogone ;
  • redirection automatique vers le site marchand avec affichage du statut pour le client final.

II. Ouverture et configuration d'un compte Ogone

Pour développer et tester un site d'e-commerce avec Ogone, la société propose de s'inscrire pour un compte de test entièrement gratuit, permettant d'effectuer des paiements fictifs (voir www.ogone.fr). Une fois le compte créé, il faut paramétrer le comportement général du compte (menu « informations techniques », expliqué plus en détail au point II.A), puis ajouter et configurer les moyens de paiement.

Image non disponible

La société propose différents types de solutions suivant les cas d'utilisation : ici nous prendrons le module Ogone e-commerce. Les paramètres généraux à renseigner sont assez explicites sur le site d'Ogone et concernent les coordonnées de la société essentiellement. Dans la configuration de l'abonnement, il n'y a rien de spécial, sauf un module supplémentaire intéressant à activer : le Fraud Detection Module qui permet d'activer les protocoles de sécurité 3D-Secure de VISA et SecureCode de MasterCard pour limiter les risques de fraude par carte de crédit, ainsi que configurer certaines règles comme des listes blanches ou noires suivant les pays (basé sur numéro de carte ou adresse IP), montant maximum accepté, etc.

Image non disponible
Image non disponible

II-A. Paramètres techniques

Il faut ensuite introduire les paramètres techniques qui vont permettre au serveur d'Ogone de dialoguer avec le site marchand, via le menu « Configuration --> Informations techniques ». Je joins les impressions d'écran auxquelles vous pouvez vous référer : la configuration est divisée en neuf points.

Image non disponible

Voyez les écrans de configuration en détail : écran 1 - écran 2 - écran 3 - écran 4.

  1. Choix de la méthode GET ou POST pour le dialogue entre Ogone et le serveur du commerçant (donc, nous) : j'ai choisi POST. Il faut aussi définir les différentes adresses e-mail pour les communications de type administratif et technique.
  2. Contrôle de l'origine des demandes de paiement : pour éviter le piratage, Ogone vérifiera que l'adresse IP appelante correspond à une de celles que vous avez indiquées (IP fixe(s) du serveur marchand), et que la page web est bien celle correspondant à l'URL que vous indiquez. Ceci évite que des petits malins téléchargent le formulaire HTML en local et le modifient pour mettre le montant à payer à zéro par exemple…
  3. Contrôle des données avant paiement : vous indiquez soit une page web qui contiendra des éléments de contrôle en pseudoXML (format défini par Ogone), soit une chaîne de caractères qui servira à confectionner la signature SHA-1 du formulaire de paiement. Ces points sont expliqués en détail plus bas dans cet article.
  4. Ce point définit comment le serveur Ogone retourne le résultat de la transaction financière au marchand : il faudra définir l'URL de la page web « postsale » sur le site marchand, qui sera appelée automatiquement par le serveur d'Ogone (en GET ou POST suivant la config. du point 1), et aussi une adresse e-mail qui servira à recevoir un rapport détaillé sur chaque transaction. Les deux sont vivement conseillés. La création de la page « postsale » est abordée en détail plus loin dans cet article. Ogone demande également à quel moment la page « postsale » doit être appelée : nous choisissons de l'exécuter immédiatement après le paiement du client, afin de prendre en compte le résultat immédiatement pour pouvoir afficher le statut de la vente sur notre site.
  5. On paramètre ici les messages affichés au client sur le serveur d'Ogone.
  6. Le système demande si on autorise un traitement « offline » de la transaction si le serveur de paiement de la banque n'est pas disponible, je choisis de ne pas le faire.
  7. Configuration des requêtes offline, c'est-à-dire survenant après le paiement par le client. C'est une étape importante, car ces informations envoyées par le serveur Ogone contiennent des mises à jour de statut, il faut donc les traiter en utilisant à la fois une requête HTTP vers une page spécifique à créer sur le site marchand, et l'e-mail de confirmation. La page HTML est semblable à la postsale, c'est pourquoi dans notre cas nous emploierons la même page dynamique en PHP.
  8. Traitement des paiements par carte de crédit : deux choix possibles, immédiat ou différé. Nous choisissons un traitement « online », pour obtenir le résultat immédiatement.
  9. Procédure de paiement : ce point est très important, mais ne concerne que les paiements par carte de crédit. Je vais détailler les trois choix proposés. La « vente directe » revient à valider le paiement immédiatement. Inconvénient : si le client se rétracte par la suite, ou en cas de fraude, il n'est plus possible d'annuler la commande ni surtout d'annuler les frais de commission prélevés par Ogone… C'est pourquoi il est nettement plus intéressant de choisir une des deux autres formules : paiement à la demande ou paiement automatique après un nombre de jours à définir. Dans le premier cas, chaque paiement reste en attente indéfiniment, et doit être validé à la main au cas par cas par le commerçant ; c'est une solution certes très sûre, mais qui demande une intervention manuelle pour chaque transaction. La dernière option consiste à laisser un délai de X jours (au choix, en général on choisit 3, 5 ou 7 jours) et Ogone valide ensuite automatiquement le paiement. Ceci permet, pendant ce délai d'attente, d'intervenir manuellement en forçant une validation immédiate, ou au contraire en annulant la transaction, sans aucuns frais de commission. C'est donc la configuration idéale à mes yeux, que nous avons choisie pour notre site.

II-B. Configuration des moyens de paiement

Cela se fait via le menu « Configurations --> Moyens de paiement ». La liste des moyens de paiement disponibles apparaît en dessous, il faut les activer puis les configurer un à un. La configuration est généralement assez simple, il suffit la plupart du temps de rentrer un numéro de compte bancaire sur lequel verser l'argent des ventes, ou un numéro de client auprès de l'institution financière. Pour un compte de production réel, Ogone vous met automatiquement en relation par e-mail avec les personnes adéquates dans chaque institution, et vous explique les démarches administratives à effectuer. Il faut en général signer un contrat pour chaque moyen de paiement…

III. Intégration HML/PHP

III-A. Initialisation : le formulaire d'achat

Une fois que l'acheteur a sélectionné et mis dans son panier tous les articles qu'il souhaite et que les frais de port sont connus et calculés (tout cela se fait en général sur une page récapitulative, dernière étape avant paiement effectif chez Ogone), on peut coder le formulaire HTML avec le lien vers Ogone de la manière suivante :

 
Sélectionnez
<? // ces constantes sont traditionnellement définies dans un fichier annexe

define("URL", "http://mon.magasin.com/");

define("URLOGONE", "https://secure.ogone.com/ncol/test/orderstandard.asp");

define("PSPID", "masociete");     // identifiant du marchand = login du compte Ogone

define("SHASIG", "masignature");    // chaine de car. pour construire la sig. SHA-1

?>



<form method="post" action="<?=URLOGONE?>">

        <!-- mandatory fields -->            

        <input type="hidden" name="orderID" value="<?=$id_vente?>">

        <input type="hidden" name="pspid" value="<?=PSPID?>">

        <input type="hidden" name="RL" value="ncol_2.0">

        <input type="hidden" name="currency" value="EUR">

        <input type="hidden" name="language" value="fr_FR">

        <? /* il FAUT arrondir à 2 décimales car ogone veut un chiffre rond */ ?>

        <input type="hidden" name="amount" value="<? echo round($prixtot, 2)*100 ?>">



        <!-- optional fields -->

        <? /* page de statut à afficher en cas de réussite ou d'échec : ici tout sur la même page */ ?>

        <input type="hidden" name="accepturl" value="<?=URL?>statut.php">

        <input type="hidden" name="declineurl" value="<?=URL?>statut.php">

        <input type="hidden" name="exceptionurl" value="<?=URL?>statut.php">

        <input type="hidden" name="cancelurl" value="<?=URL?>statut.php">

        



        <? $shastring = $id_vente.(round($prixtot, 2)*100)."EUR".PSPID.SHASIG; ?>

        <input type="hidden" name="SHASign" value="<?=sha1($shastring)?>">

        

        <? /* paramètres supplémentaires facultatifs pour fonctionnement interne */ ?>

        <input type="hidden" name="paramplus" value="toto=blabla&titi=blublu">

        

        <!-- param. de mise en page Ogone -->

        <input type="hidden" name="title" value="Mon magasin virtuel, mon joli titre">

        

        <input type="submit" value="Payer">

</form>

Quelques explications sur les variables PHP présentes dans le code :

  • $id_vente est un numéro unique (clé primaire) représentant la commande. Ogone ne peut jamais voir deux commandes différentes avec le même numéro, sinon il refuse en affichant un message d'erreur tout sauf clair… Même une commande annulée par l'acheteur doit donc être enregistrée dans votre base de données, pour ne pas réutiliser le même numéro pour une prochaine commande. Faites également très attention au problème de concurrence, en termes de base de données : si vous générez le numéro vous-mêmes, prenez garde à ce qu'aucun client ne puisse obtenir le même numéro en faisant une transaction avec quelques secondes de décalage sur votre site… La meilleure solution consiste à laisser faire votre SGBD : insérez directement une ligne concernant votre commande dans votre DB avant même de lancer la procédure Ogone ; votre identifiant sera ainsi fixé et ne pourra pas être « volé ». Ensuite quand Ogone vous communique le résultat, faites un update SQL de cette ligne avec le statut du paiement.
  • $prixtot : montant total de la vente. S'il y a des frais de transport, pensez à les inclure, idem pour toutes les taxes dues par le client (TVA principalement). Ogone veut voir le prix multiplié par 100 pour supprimer les décimales. Exemple : montant = 125,47 EUR, le nombre à indiquer à Ogone sera 12547. Pour éviter toute surprise lors de la multiplication par 100 (montant affiché par Ogone légèrement différent de celui que vous avez affiché à votre client, dû à un problème d'arrondi), il est primordial de penser à arrondir d'abord le montant à deux décimales avant d'effectuer la multiplication. C'est la raison d'être de la fonction round() dans le code ci-dessus.

L'URL de la page action n'est pas la même en test et en production ! Il suffit de remplacer le mot « test » par « prod ». La page de statut sera abordée en détail plus loin, de même que la signature de contrôle SHA-1. Vous constatez également la présence de deux paramètres supplémentaires : paramplus et title. Paramplus permet de renseigner des champs pour l'usage interne du site marchand. Ces champs ne seront pas touchés par Ogone, qui se contentera de les retransmettre tels quels à la page postsale (appelée automatiquement par Ogone après la transaction), qui pourra donc les traiter comme bon lui semble. L'intérêt pour le marchand est de pouvoir communiquer n'importe quel type d'informations qui lui seraient utiles à sa page postsale (attention : ne pas oublier d'encoder les valeurs de ces champs avec la fonction PHP urlencode()). Enfin le paramètre « title » permet de personnaliser le titre affiché sur les pages du serveur Ogone vues par le client. Il y a bien d'autres paramètres facultatifs disponibles, qui permettent de personnaliser encore plus le traitement, tout est détaillé dans la documentation d'Ogone.

Les champs accepturl, declineurl, etc. sont les pages du site marchand qui vont afficher le statut de la transaction, c'est le point de retour depuis Ogone. À ne pas confondre avec la page postsale qui n'est qu'un traitement batch, sans aucun affichage, destiné uniquement à mettre à jour la base de données du marchand en fonction des résultats envoyés par le serveur de paiement.

III-B. Sécurité : contrôle de la transaction

Par sécurité, Ogone veut s'assurer que les données transmises par le formulaire vu ci-dessus n'ont pas été trafiquées (ce qui est possible par exemple en copiant la page sur son ordinateur local et en modifiant les champs). Pour cela, il propose deux types de vérification que nous allons aborder. Mais en préambule je vais vous montrer une fonction de contrôle personnalisée, à implémenter sur le serveur du vendeur, et qui sera utilisée plusieurs fois.

III-B-1. Fonction de contrôle de l'IP d'Ogone

Ogone vérifie notre IP pour éviter toute falsification, mais il est prudent d'effectuer la vérification inverse lorsque nous recevons une requête de type postsale ! Sinon quelqu'un disposant de la documentation Ogone (ou du présent article ;-)) pourrait aisément corrompre notre base de données en validant des commandes.

Ogone dispose bien sûr de plusieurs serveurs redondants, l'IP source peut donc varier, ce qui rend la tâche moins facile… Ils donnent dans leur documentation trois réseaux IP, j'ai donc créé une fonction PHP générique qui contrôle que l'IP passée en paramètre est bel et bien dans un de ces trois réseaux. La compréhension de ce code requiert des notions de protocole IP et de masque de sous-réseau que je ne détaille pas ici pour ne pas trop allonger l'article.

 
Sélectionnez
// ensemble d'IP possibles des serveurs Ogone (normalement dans config.inc.php)

$ipogone = array("212.23.45.96/28", "213.254.248.96/28", "212.35.124.160/28");



function checkIPOgone($ip) {

        global $ipogone;

        

        $result = false;        

        // boucle sur tous les réseaux à vérifier:

        for ($i=0; $i < sizeof($ipogone); $i++) {

                // découpe l'adresse IP source ($ip) et l'adresse du réseau à vérifier ($ipogone[$i])

                // dans leurs 4 composantes :

                if (ereg("^([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)$", $ip, $ipregs) && 

                        ereg("^([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)\/([0-9]+)$", $ipogone[$i], $ogoneRegs)

                        ) {

                        

                        $mask = $ogoneRegs[5];

                        $num = pow(2,32-$mask)-1;   // nombre d'IP possibles

                        if ($ipregs[4] >= $ogoneRegs[4] && $ipregs[4] <= $ogoneRegs[4]+$num &&

                                $ipregs[1] == $ogoneRegs[1] && $ipregs[2] == $ogoneRegs[2] &&

                                $ipregs[3] == $ogoneRegs[3]

                                ) { $result = true; break; }

                }

        }

        return $result;

}

                                        

III-B-2. Signature SHA-1

Cette méthode est identique à la signature des e-mails ou des fichiers que vous téléchargez sur internet (images iso de Linux par exemple). Elle consiste à réaliser un « hash » numérique (= somme de contrôle, ou « empreinte » digitale) d'informations données au moyen d'un algorithme tel que SHA-1 ou MD5, qui sera envoyée à Ogone. Celui-ci recalculera cette signature sur base des données de la vente pour vérifier que la signature obtenue est bien identique à celle qu'il a reçue. Si ce n'est pas le cas, c'est que les données ont été altérées d'une manière ou d'une autre…

Cette signature s'effectue au niveau du formulaire de vente, vu au paragraphe précédent ; je reprends ici les lignes concernées :

 
Sélectionnez
<? $shastring = $id_vente.(round($prixtot, 2)*100)."EUR".PSPID.SHASIG; ?>
<input type="hidden" name="SHASign" value="<?=sha1($shastring)?>">

La signature se calcule sur base des caractéristiques de la vente, sous la forme de plusieurs chaînes de caractères qui doivent être concaténées (= collées) l'une à l'autre dans l'ordre suivant :

  • la référence de la vente : $id_vente ;
  • le montant, arrondi à la façon Ogone (montant réel multiplié par 100) : round($prixtot, 2)*100 ;
  • le code de la monnaie utilisée (currency), ici donc l'euro : EUR ;
  • le PSPID (login) du marchand ;
  • la chaîne de caractères propre au marchand, définie dans les paramètres de son compte (point 3.2 de l'écran de configuration) : SHASIG (on appelle la constante définie plus haut).

Toutes ces données sont concaténées au moyen de l'opérateur PHP . (point) pour former une chaîne unique, $shastring. De cette chaîne on calculera la signature en utilisant l'algorithme SHA-1 au moyen de la fonction intégrée à PHP : sha1($shastring) et on l'envoie à Ogone dans le champ caché « SHASign » du formulaire.

C'est la méthode de contrôle la plus simple à mettre en place et qui est très sûre, je la conseille donc.

III-B-3. Page de pseudoXML

Ici Ogone va demander au serveur du marchand de lui confirmer les données de la commande qui vient d'être passée. Il transmet le numéro de la commande en question via le paramètre orderID à la page du site marchand dont l'URL est renseignée dans la configuration du compte, et attend le résultat sous une forme de pseudoXML telle que définie dans la documentation Ogone.

Si la commande existe réellement sur le serveur marchand, le résultat doit être du type :

 
Sélectionnez
<orderID="12345"
amount="12547"
currency="EUR">

Sinon il s'attend à un message d'erreur du genre :

 
Sélectionnez
<uncorrect orderid 12345>

Voici donc le code de la page de contrôle :

 
Sélectionnez

<?php

// Vérifie provenance IP = serveur OGONE
if (!checkIPOgone($_SERVER["REMOTE_ADDR"])) die("Remote server not recognized. Access denied.");

// ici : récupération des données de la vente// $montant correspondra au montant total

if (!$montant) {
?>

<uncorrect orderid : "<?=$_REQUEST["orderID"]?>">

<?
}
else {
?>

<orderID="<?=$_REQUEST["orderID"]?>" 
amount="<?=round($montant, 2)*100?>" 
currency="EUR">

<?
}
?>

Pour augmenter encore la sécurité (mode paranoïaque), je commence par m'assurer que le serveur appelant est bien celui d'Ogone en contrôlant son adresse IP, au moyen d'une fonction de mon cru, que j'ai montrée au chapitre III.B.1. Ensuite je récupère les données de la vente, cette partie n'étant pas reproduite ici, libre à vous de faire selon vos habitudes ;-) Les données sont ensuite formatées de la manière requise par Ogone.

III-C. Page « postsale » : retour d'information par Ogone

Si les contrôles vus au point précédent se sont bien déroulés, le client peut poursuivre son paiement sur le site d'Ogone. Une fois l'opération terminée, Ogone renvoie le résultat ainsi qu'une série d'informations au site marchand sur sa page postsale, telle que définie dans la configuration du compte (point 4). Classiquement la page postsale se contente de stocker toutes ces variables dans sa base de données, comme le montre l'exemple suivant :

 
Sélectionnez

<?php

// Vérifie provenance IP = serveur OGONE
if (!checkIPOgone($_SERVER["REMOTE_ADDR"])) die("Remote server not recognized. Access denied.");

require("");   // fichier d'inclusion nécessaire
$vente = new Vente();
$zevente = $vente->getVente($_POST["orderID"]);

if ($zevente["statut"] > 0 && ereg("^[0-9]+$", $_POST["STATUS"])) {
        // mise à jour du statut en différé (paiement auto après 3 jours cf config Ogone ou chang. statut manuel sur extranet ogone)
        $oldstatut = $zevente["statut"];
        $vente->changeStatut($_POST["orderID"], $_POST["STATUS"]);
        sendmailStatut($_POST["orderID"], $_POST["STATUS"], $oldstatut);
}
else {
        // mise à jour du statut ogone dans le cas normal (en direct)
        if (eregi("CreditCard", $_POST["PM"])) $pm = $_POST["BRAND"]; else $pm = $_POST["PM"];
        $vente->valideVente($_POST["orderID"], $_POST["amount"], $_POST["STATUS"], $_POST["PAYID"], $pm,
        $_POST["toto"], $_POST["titi"]);
        
        // envoie un mail au client si paiement OK
        if ($vente->statutOK($_POST["STATUS"])) {
                //$zevente = $vente->getVente($_POST["orderID"]);
                $idclient = $zevente["id_client"];
                sendmailok($idclient, $_POST["orderID"]);
        }
}

À noter que les variables envoyées par Ogone le sont en POST, comme on l'a défini dans le premier paramètre de configuration du compte. Ici j'ai illustré le stockage en base de données via un simple appel de classe, qui se charge d'envoyer les requêtes nécessaires au SGBD. À nouveau, je vérifie si l'adresse IP appelante correspond bien au serveur Ogone avant de faire quoi que ce soit. L'appel de cette page est totalement invisible pour le client, qui est pour l'instant toujours sur le site d'Ogone.

Voici la signification des différents paramètres envoyés par Ogone :

  • orderID : référence de la commande ;
  • amount : montant de la commande, au format décimal normal, non multiplié par 100 ;
  • STATUS : valeur numérique qui correspond à l'état du paiement. Voici les principaux codes et leur signification  :
    • 0 ou 1 signifie que l'encodage du paiement n'est pas arrivé à son terme, soit parce qu'il est toujours en cours, soit parce que l'encodeur a abandonné, soit parce qu'une erreur de validation du format des données a empêché de confirmer celui-ci. S'il s'agit d'une erreur de validation, un code d'erreur complémentaire (*) (NCERROR) donne le type d'erreur de validation,
    • 2 : l'acquéreur a refusé l'autorisation,
    • 5 : le paiement est autorisé (uniquement pour les cartes de crédit, dans le cas où on a configuré un mode de paiement avec délai de X jours avant validation),
    • 9 : le paiement est exécuté et validé.

    La liste complète de tous les statuts est donnée sur le site d'Ogone ;
  • PAYID : référence interne du paiement Ogone. Valeur importante, car elle se retrouvera sur les relevés de compte bancaire du marchand ;
  • PM : pour « payment method », c'est une valeur alphanumérique indiquant la méthode de paiement utilisée par le client : « CreditCard » pour tout type de carte de crédit, « DEXIA » pour un paiement par netbanking de la banque Dexia, etc. Dans le cas du paiement par carte de crédit, le champ BRAND contient le nom de l'organisme de crédit (VISA, MasterCard, etc.)
  • toto et titi : ce sont les champs supplémentaires du « paramplus », à l'usage exclusif du vendeur. Ils peuvent contenir n'importe quelle information, cela reste toujours la liberté du vendeur.

Rappelons qu'Ogone communique avec le serveur du vendeur dans deux cas :

  • directement après paiement du client : c'est le fameux « postsale » donc à ce moment on inscrit le statut dans la base de données ;
  • lors d'une validation différée (cas des cartes de crédit si on a configuré un paiement automatique après X jours, ou qu'on valide ou annule le paiement manuellement) : j'ai spécifié que c'est la même page qui devait être appelée, puisque le code est très semblable et les paramètres envoyés par Ogone identiques. Ici le statut existe déjà en base de données, et sera donc mis à jour (ceci permet de différencier le traitement de notre côté). Un paiement par carte de crédit passera donc d'un statut 5 en postsale à un statut 9 après X jours.

Note : il est important d'utiliser les majuscules pour les noms des champs tels qu'envoyés par Ogone, car PHP fait la différence, comme pour les noms de variables.

III-D. Redirection sur site marchand et affichage du statut

Nous en arrivons à la fin du processus : le paiement est effectué et le serveur du marchand a été informé du résultat. La dernière étape pour Ogone consiste donc à rediriger le client sur le site du marchand. Il sélectionne une des URL renseignées dans le formulaire de paiement initial (accepturl, declinenurl… ) selon le résultat de la transaction. Dans mon cas toutes ces URL sont identiques, car la page sera toujours grosso modo la même, le code PHP étant à même de différencier l'affichage selon le statut du paiement Ogone qu'il va récupérer dans la base de données (mise à jour précédemment par l'appel à la page postsale). Cette page n'a donc plus aucun lien « technique » avec Ogone, aucun paramètre n'est échangé (puisque tout a déjà été fait), il s'agit juste d'afficher au client la page finale de la vente en rappelant les références qui lui seront utiles. À ce stade, il est aussi classique de lui envoyer un e-mail de confirmation ou lui permettre de sauvegarder et/ou imprimer son bon de commande ou sa facture. Je n'illustre cet aspect d'aucun code étant donné qu'il n'y a rien de particulier à Ogone ici ;-) Je donnerai cependant deux liens qui peuvent être utiles : la classe phpmailer pour l'envoi d'e-mail en PHP, bien plus souple et puissante que la fonction mail() intégrée ; et la classe FPDF pour la conception de documents PDF plus aisée qu'avec les fonctions de bas niveau.

IV. Conclusion

Nous avons fait le tour des principales fonctionnalités du module Ogone e-commerce, qui permettent de mettre en place relativement aisément un ensemble de possibilités de paiement sur votre site de vente en ligne. Malgré la documentation fournie par Ogone, j'ai estimé utile de rédiger cet article basé sur mon expérience personnelle pour un site réel d'e-commerce, qui d'une part synthétise l'information utile, et d'autre part met en garde sur certains éléments auxquels il vaut mieux prêter attention. J'espère que cela vous aidera si vous envisagez de réaliser un site d'e-commerce utilisant Ogone comme opérateur de paiement.