Introduction

WL Sips est une solution de paiement de commerce électronique multicanale sécurisée conforme à la norme PCI DSS. Elle vous permet d’accepter et de gérer des transactions de paiement en prenant en compte les règles métiers liées à votre activité (paiement à la livraison, paiement différé, paiement récurrent, paiement en plusieurs fois , …).

L’objectif du présent document est d’expliquer la migration de WL Sips Payment 1.0 vers Sips Paypage 2.0.

Sujets non couverts dans le présent document :

  • Ce document ne présente que la migration vers Sips Paypage 2.0 POST, connecteur recommandé sur Sips Paypage 2.0, si vous souhaitez utiliser la version JSON, merci de vous référer au document .

A qui s’adresse ce document

Ce document est à destination des commerçants disposant de l’offre WL Sips 1.0. Il a pour but de faciliter la migration vers WL Sips 2.0.

Pour connaître tous les détails de l’utilisation des pages de paiement Sips Paypage 2.0, merci de vous référer au document Sips Paypage POST.

Les atouts de Sips Paypage 2.0

Sips Paypage 2.0 permet de ne plus stocker sur le serveur commerçant de fichiers spécifiques à l’appel des pages de paiement.

Aussi, le choix du moyen de paiement peut être réalisé sur votre serveur commerçant (en spécifiant lors de l’appel le moyen de paiement utilisé) ou côté serveur de paiement Sips Paypage 2.0.

Enfin, avec Sips Paypage 2.0 POST, seul un formulaire en mode POST sera envoyé vers les serveurs Sips Paypage 2.0 pour réaliser la cinématique de paiement. La redirection est automatiquement réalisée par le serveur de paiement vers la page de saisie des informations des moyens de paiement.

Principe

Ce qui change en WL Sips 2.0

Pour la partie paiement :

  • Possibilité d’utiliser une nouvelle référence de transaction (35 car, AN) unique (ne peut être utilisé que pour une seule transaction) à gérer en toute autonomie.
  • Nouvelle URL pour la partie pages de paiement.
  • La gestion du choix du moyen de paiement est déportée chez WL Sips .
  • Le certificat WL Sips est remplacé pour une clé secrète.

Le commerçant n’installe plus aucun fichier chez lui, quelle que soit l’interface WL Sips 2.0 qu'il choisit.

Ce que doit faire le commerçant

  • Décider du connecteur Sips Paypage 2.0 à utiliser (POST, JSON).
  • Décider de rester avec la gestion du transactionID ou passer au transactionReference .
  • Mettre en place sa requête de paiement en sécurisant sa nouvelle clé secrète.
  • Utiliser l’environnement de recette client pour tester les applications Sips Paypage 2.0 avec un identifiant de connexion mis à disposition.
  • Faire une demande d’accès en production.
  • Supprimer les références à Payment 1.0 sur son site (certificat, fichiers paramètres, fichiers exécutables).

Choix du connecteur Sips Paypage 2.0

Ce document ne présente que le connecteur POST (formulaire envoyé au serveur WL Sips en mode POST).

Si vous souhaitez que le premier appel au serveur de paiement soit réalisé en mode « machine à machine » avec la technologie JSON, merci de vous référer au document pour la mise en place des requêtes de paiement dans ce mode.

Choix du mode transactionID ou transactionReference

Par défaut, Sips Paypage 2.0 utilise un transactionReference pour identifier une transaction vers le serveur de paiement. Cet identifiant est unique pour toute la durée de l’inscription du commerçant sur WL Sips , il n’est pas réutilisable pour une autre transaction.

Si vous souhaitez rester en mode transactionID / transactionDate , vous devez en faire la demande à WL Sips lors de l’inscription de votre identifiant marchand à l’offre WL Sips 2.0 afin que la configuration de votre identifiant marchand soit conforme à l’attendu.

Les champs à utiliser dans la requête de paiement seront donc :

TransactionReference AN35 Identifiant unique de la transaction

ou

s10TransactionReference. s10TransactionId N6 TransactionReference est le moyen par défaut d’identifier une transaction. s10TransactionReference.s10TransactionId est une alternative pour identifier une transaction, en restant compatible avec WL Sips 1.0.
s10TransactionReference. s10TransactionIdDate N8 (YYYYMMDD) Le couple s10TransactionReference.s10TransactionId / s10TransactionReference.s10TransactionIdDate assure l’unicité de la transaction. Il faut utiliser au minimum une version d’interface (champ interfaceVersion) égal à IR_HP_2.7.

Comment passer de l’API au connecteur WL Sips 2.0

Cette personnalisation se base sur l’utilisation de l API Payment 1.0 Plugin et sur les fichiers donnés en exemple dans le répertoire sample de cette API.

Le fichier contenu dans le répertoire sample de Payment 1.0 et nommé callrequest.php contient un certain nombre d’information à reporter dans votre nouveau fichier PHP à préparer pour réaliser le formulaire en mode POST de la requête de paiement.

Note: Tous les exemples de code sont présentés en langage PHP et sont à personnaliser pour une utilisation réelle en production. Ils ne sont pas à reproduire tels que et ne sont là que pour présenter rapidement comment se connecter à Sips Paypage 2.0.

Les fichiers du répertoire param

Avec Payment 1.0, le répertoire par défaut param contient les fichiers parcom et pathfile de paramètres par défaut de la boutique. Ces fichiers ne sont maintenant plus utilisés.

Le nouveau formulaire utilisé sur Sips Paypage 2.0 doit embarquer la récupération des informations concernant les paramètres par défaut du commerçant et permettant de se connecter à Sips Paypage 2.0 pour effectuer la requête de paiement.

Le fichier pathfile , contenant les chemins de l’installation de Payment sur le serveur du commerçant n’est plus utilisé, aucune de ces informations n’étant utile à Sips Paypage 2.0. Ce fichier sera donc à supprimer lorsque la migration sera terminée.

La plupart des données du fichier parcom sont enregistrées dans la configuration du commerçant lors de son inscription à WL Sips 2.0. Cependant, certaines données peuvent être forcées dans la requête de paiement si elles restent compatibles avec les données connues lors de l’inscription du commerçant. Aussi, certaines autres données (par exemple, la devise du montant) restent obligatoires dans la requête.

Donnée parcom Champ de la requête Sips Paypage 2.0 Obligatoire/Facultatif
AUTO_RESPONSE_URL automaticResponseURL Facultatif
RETURN_URL normalReturnURL Obligatoire
PAYMENT_MEANS paymentMeanBrandList Facultatif
CURRENCY currencyCode Obligatoire
LANGUAGE customerLanguage Facultatif
TEMPLATE templateName Facultatif

Données de base du formulaire

Le nouveau formulaire doit embarquer la récupération des informations concernant le commerçant et permettant de fabriquer la requête de paiement, par exemple :

      //Initialisation des données commerçant
$merchantid=<valeur du merchantID Sips>;
$secretkey=<clé secrète du commerçant>;
$keyversion=<version de la clé secrète du commerçant>;


$tref=’test_tref01’;
    

Contrairement à Payment 1.0 où les données étaient envoyées à l’exécutable request.exe contenu dans le répertoire bin , il faudra maintenant calculer un champ nommé Data contenant les données de la requête et un champ Seal contenant l’empreinte du message à envoyer.

Calcul du champ Data

Puis calcul du champ Data avec les données de la requête (ici avec un montant de 1 euro) :

      $Data='amount=100|currencyCode=978|merchantid='.$merchantid.'|automaticResponseUrl=http://www.mon
_url_marchand.com/call_autoresponse.php|normalReturnUrl=http://www.mon_url_marchand.com/call_response.php
|transactionReference='.$tref.'|keyVersion='.$keyversion.'|customerLanguage=fr;
    

Calcul du champ SEAL

Les paramètres de la transaction (requête de paiement) sont envoyés au travers du navigateur de l’internaute. Théoriquement, il est possible à un hacker de modifier les paramètres durant la transmission des données vers le serveur de paiement.

Il est par conséquent nécessaire d’ajouter de la sécurité pour assurer l’intégrité des paramètres transmis de la transaction. La solution WL Sips répond à ce besoin par l’échange de signatures, nommées empreintes du message.

Un contrôle réussi des signatures implique deux choses :

  • L’intégrité des messages requête et réponse, pas d’altération durant l’échange,
  • L’authentification de l’émetteur et du receveur car ils partagent la même clé secrète.

Le calcul de l’empreinte du message grâce au hash du champ Data par la clé secrète du commerçant :

      $Seal=hash('sha256', $Data.$secretkey);
    

Formulaire en mode POST

Et enfin, envoi du formulaire en mode POST avec les données (exemple avec l’URL de l’environnement de recette) :

      echo '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
  <meta http-equiv="content-type" content="text/html; charset=windows-1250">
  <title>REDIRECTION VERS PAGE DE PAIEMENT</title>
  </head>
  <body>
<form method="post" action="https://payment-webinit.test.sips-atos.com/paymentInit">';
echo '<input type="text" name="Data" size="300" value="'.$Data.'"><br>';
echo '<input type="text" name="InterfaceVersion" size="300" value="HP_2.7"><br>';
echo '<input type="text" name="Seal" size="300" value="'.$Seal.'"><br>';
echo '<br><input type="submit" value="Connexion a Sips 2.0">';   
echo '</form></body></html>';
    

Formulaire en mode JSON

Merci de vous référer au document Sips Paypage JSON afin d’obtenir de l’aide sur la mise en place d’un appel cURL avec JSON.

Personnalisation de la récupération en réponse du paiement

Les réponses automatiques et manuelles seront à adapter par rapport aux versions présentées sur Payment 1.0.

Les fichiers de traitement des réponses donnés en exemple dans le répertoire sample se nomment call_response.php et call_autoresponse.php.

Contrairement à Payment 1.0 où les données étaient envoyées à l’exécutable response.exe contenu dans le répertoire bin , il faudra maintenant récupérer le champ nommé Data contenant les données de la réponse et vérifier le champ Seal contenant l’empreinte du message reçu.

Récupération des données de base de la réponse

Le nouveau formulaire doit embarquer la récupération des informations concernant le commerçant et permettant de fabriquer la requête de paiement, par exemple :

      //Recupération des donnees de la reponse
$Data=htmlspecialchars($_POST[“Data”]);
$Seal=htmlspecialchars($_POST[“Seal”]);

//Separation de tous les champs
$tableau = explode ("|", $Data);
    

Calcul du champ SEAL

Ensuite calcul de l’empreinte du message grâce au hash du champ Data par la clé secrète du commerçant :

      $SealCalc=hash('sha256', $Data.$secretkey);
    

Il faudra ensuite vérifier que le Seal correspond au Seal reçu dans la requête.

Test sur l’environnement de recette

Au préalable, il faut faire la demande de création d’une boutique de test puis d’installation des livrables permettant la personnalisation des pages de paiement afin qu'ils soient installés sur l’environnement de recette Sips Paypage 2.0.

Merci de vous référer au document Custompages d’aide à la migration de la personnalisation des pages de paiement.

Le mode DEBUG

Le mode DEBUG n’existe plus, mais lors du test en environnement de recette, chaque erreur est affichée clairement et permet donc de mieux préparer ses requêtes de paiement.

Suppression des références à WL Sips Payment 1.0

Lors de l’installation de Payment 1.0, l’arborescence suivante est créée sur le serveur :

Les fichiers de Sips Paypage 2.0 n’ayant plus rien à voir avec cette arborescence, vous pouvez complètement supprimer les fichiers présents.