Connecteur POST

From Documentation Mercanet
Jump to: navigation, search

Contents

Introduction

Mercanet est une solution de paiement e-commerce multicanale sécurisée conforme à la norme PCI DSS. Elle permet à tout commerçant d’accepter et de gérer des transactions de paiement en prenant en compte les règles métiers liées à son activité (paiement à la livraison, paiement différé, paiement récurrent, paiement fractionné, …). L’objectif du présent document est d’expliquer la mise en œuvre de la solution Mercanet Paypage JSON jusqu’au démarrage en production.

A qui s’adresse ce document

Ce document est destiné aux commerçants qui souhaitent souscrire à l’offre Mercanet et utiliser un connecteur fondé sur les échanges HTTPS en mode POST entre leur site Web et les serveurs de paiement Mercanet Paypage POST.

C’est un guide d’implémentation qui s’adresse à votre l’équipe technique.

Pour avoir une vue d’ensemble de la solution Mercanet, nous vous conseillons de consulter les documents suivants:

Prérequis

Une connaissance élémentaire des standards relatifs aux langages de programmation Web pratiqués aujourd’hui, tels que Java, PHP ou .Net, est nécessaire pour développer la connexion à Mercanet Paypage POST.

Remarque

Tous les exemples de code de ce document sont fournis à titre d’exemple, il convient de les adapter à votre site Web afin qu’ils soient pleinement exploitables.

Gestion de la clé secrète

Lors de votre inscription, BNP Paribas met à disposition sur l’extranet Mercanet Téléchargement, une clé secrète qui permet de sécuriser les échanges entre votre site et le serveur Mercanet. Vous êtes responsable de sa conservation et devez prendre toutes les mesures pour:

  • en restreindre l’accès,
  • la sauvegarder de manière chiffrée,
  • ne jamais la copier sur un disque non sécurisé,
  • ne jamais l’envoyer (e-mail, courrier) de manière non sécurisée.

La compromission de la clé secrète et son utilisation par un tiers malveillant perturberait le fonctionnement normal de votre boutique, et pourrait notamment générer des transactions et des opérations de caisse injustifiées (des remboursements par exemple). En cas de compromission d’une clé secrète, vous êtes tenu d’en demander au plus vite la révocation puis le renouvellement via l’extranet Mercanet Téléchargement.

Remarque

C’est la même clé secrète qui est utilisée sur les différents connecteurs Paypage, Office et Walletpage.

Contacter l’assistance technique

[Pour toute question technique ou demande d'assistance, cliquer ici pour plus d'informations.]

Comprendre le paiement avec Mercanet Paypage POST

Le principe général d’un processus de paiement est le suivant:

Schema connecteur post.png

  1. Lorsque le client procède au paiement, une requête de paiement doit être envoyée au connecteur Mercanet POST. BNP Paribas vous fournit l’URL de ce connecteur. La requête est alors vérifiée, et chiffrée si elle est valable (elle est nommée RedirectionData dans le système). La requête est envoyée au moyen d’un formulaire en mode POST via HTTPS. Toute autre solution capable d’envoyer une requête de cette nature fonctionne également.
  2. Le site du commerçant redirige l’application appelante vers les pages de paiement Mercanet. Le client doit saisir les informations du moyen de paiement pour que le serveur de paiement Mercanet prenne en charge la transaction. Il convient de noter que les détails du paiement peuvent être saisis directement sur le serveur qui propose le moyen de paiement (par exemple dans le cas de PayPal). À la fin du processus de paiement, qu’il soit réussi ou non, deux réponses sont créées et envoyées à l’adresse URL précisée lors du 1er flux.

    Il y a deux notifications de réponses indépendantes:
  3. Les réponses manuelles sont envoyées sous format HTTP(S) POST par le serveur de paiement à l’URL de réponse manuelle. Cette URL est précisée dans la requête de paiement et est utilisée lorsque le client clique le bouton «Continuer» de la page de paiement. Elle est la page de destination vers laquelle le client est redirigé à la fin du paiement. Comme il n’y a aucune garantie que le client clique sur ce bouton, vous n’avez aucune garantie de recevoir la réponse manuelle.
  4. Les réponses automatiques sont envoyées indépendamment des réponses manuelles. Elles utilisent également les requêtes HTTP(S) POST envoyées par les serveurs de paiement Mercanet mais cette fois-ci moyennant l’URL de réponse automatique précisée dans la requête de paiement. Cela signifie que vous recevez la réponse dès que le paiement est effectué dans les pages de paiement Mercanet.

Remarque

Si le paiement a échoué, et dès que le client est redirigé vers votre site Web, il n’est plus possible de revenir aux pages de paiement Mercanet pour tenter de payer à nouveau ou pour corriger les données de carte. Le rôle de votre site Web est d’initialiser une nouvelle requête de paiement, en commençant par l’appel au connecteur Mercanet Paypage.

Démarrer avec Mercanet Paypage en 5 étapes

Etape 1: Inscrire la boutique en production

Afin d’inscrire votre boutique en production, vous devez remplir le formulaire d’inscription envoyé par BNP Paribas et le retourner à ce dernier.

Lors de la saisie du formulaire, vous désignez un contact administratif et un contact technique afin que BNP Paribas puisse vous communiquer les informations nécessaires pour démarrer votre boutique.

BNP Paribas procède alors à l’enregistrement de la boutique et vous retourne votre identifiant commerçant (MerchantId) ainsi que vos identifiants et mots de passe Mercanet Download (récupération de la clé secrète) et Mercanet Extranet (gestion de caisse) par mail.

Remarque

Pour le Back Office Mercanet, l’identifiant et le mot de passe sont envoyés au contact administratif. Pour Mercanet Téléchargement, l’identifiant est envoyé au contact administratif et le mot de passe au contact technique.
L’inscription de la boutique n’est pas nécessaire pour commencer à intégrer le connecteur et à tester la connexion sur l’environnement de simulation. Vous pouvez ne demander l’inscription de votre boutique qu’au moment de faire les tests en production.

Etape 2: Effectuer un paiement

La requête de paiement est une requête HTTPS POST adressée au connecteur Mercanet Paypage POST.
La requête est envoyée via un formulaire HTML au moyen de la méthode POST.

Générer la requête de paiement

Trois données obligatoires sont renseignées dans la requête de paiement.

Nom de la donnée

Description

Data

Contient toutes les informations relatives à la transaction.

InterfaceVersion

Définit la version de la requête et de la réponse échangée avec le serveur Mercanet.

Seal

Utilisé pour valider l’intégrité des données échangées. La donnée Seal est calculée à l’aide de la donnée Data et de la clé secrète.

La donnée InterfaceVersion doit être fixée à HP_2.20.

Des données optionnelles supplémentaires sont disponibles:

Nom de la donnée

Description

Encode

Précise la méthode utilisée pour encoder la donnée Data

SealAlgorithm

Précise l’algorithme utilisé pour calculer la donnée Seal

Syntaxe de la donnée Data

La donnée Data est construite conformément au format suivant:

<nomChamp1>=<valeurChamp1>|<nomChamp2>=<valeurChamp2>|..|<nomChampN>=<valeurChampN>


Tous les champs nécessaires pour la transaction (voir les détails dans le dictionnaire de données) doivent être inclus dans la chaîne de caractères. L’ordre des champs n’a pas d’importance.

Exemple d’une requête de paiementde 55 euros :

amount=5500|currencyCode=978|merchantId=211000021310001|normalReturnUrl=http://www.normalreturnurl.com|transactionReference=534654|keyVersion=1


Il est possible d’avoir une liste de valeurs pour un même champ :

..|nomChamp=valeur1,valeur2, .. ,valeurX|..


Exemple avec le champ paymentMeanBrandList valorisé avec VISA et MASTERCARD:

…|amount=5500|currencyCode=978|merchantId=211000021310001|normalReturnUrl=http://www.normalreturnurl.com|transactionReference=534654[paymentMeanBrandList=VISA,MASTERCARD|keyVersion=1|..


Si le champ est un container, vous devez utiliser un point entre le nom du container et le nom du champ:

..|Container.nomChamp1=valeurChamp1|container.nomChamp2=valeurChamp2|..


Exemple pour le champ customerContact contenant l’email et le nom et prénom Jean Dupont du client :

..|customerContact.email=moi@email.com|customerContact.firstname=Jean|customerContact.lastname=Dupont|..


Si un champ contient une liste d’objets complexes, sa représentation est construite conformément au format suivant :

..|<champ1>=<valeur1>|
<nomObjet>.<nomItem=
{<nomChampA1>=<valeurChampA1>,<nomChampA2>=<valeurChampA2>},
{<nomChampB1>=<valeurChampB1>,<nomChampB2>=<valeurChampB2>},
{<nomChampC1>=<valeurChampC1>,<nomChampC2>=<valeurChampC2>}|
<nomChamp2>=<valeurChamp2>|..


Exemple d’une requête de paiement avec une liste d’objets complexes pour le champ shoppingCartDetail contenant trois produits nommés apple, mango et pear:

amount=5500|currencyCode=978|merchantId=211000021310001|normalReturnUrl=http://www.normalreturnurl.com|transactionReference=534654|shoppingCartDetail.shoppingCartItemList={productName=apple,productDescription=red},{productName=pear,productDescription=green},{productName=mango,productDescription=yellow}|keyVersion=1
Encodage de la donnée Data

Si la donnée Data comporte des caractères spéciaux (comme par exemple des caractères accentués) alors elle doit être encodée en base64 ou base64Url
Remarque

Puisque le calcul de la signature se fait avec la donnée Data, il convient de noter que c’est la valeur Data encodée qui est utilisée pour la signature de la requête

Présence des champs de la requête

Certains champs de la requête de paiement ne sont obligatoires que :

  • Lors de l'utilisation de certains moyens de paiement, veuillez consulter le guide du moyen de paiement concerné pour savoir quels champs sont obligatoires
  • En fonction de la configuration de votre boutique, veuillez consulter le guide de configuration des fonctionnalités pour savoir quels champs sont obligatoires
  • Dans certains cas d'usages (ex: paiement récurrent), veuillez consulter le guide de configuration des fonctionnalités pour savoir quels champs sont obligatoires

Ces champs sont désignés avec la mention "conditionnel".

Sécurisation de la requête

La requête de paiement contient les paramètres de la transaction et est envoyée par le navigateur Web du client. Théoriquement, il est possible pour un pirate d’intercepter la requête et de modifier son contenu avant que les données n’atteignent le serveur de paiement. De ce fait, il est nécessaire de renforcer la sécurité pour assurer l’intégrité des paramètres de la transaction envoyée. La solution Mercanet répond à ce besoin par échange de signatures. Un contrôle effectif de la signature comporte deux éléments:

  • l’intégrité des messages de requête et de réponse; l’absence de modifications lors de l’échange,
  • l’authentification de l’émetteur et du destinataire, car ils se partagent la même clé secrète.

Remarque

Si votre clé secrète est compromise, ou si vous supposez que c’est le cas, vous devez impérativement demander son renouvellement en vous connectant à Mercanet Téléchargement.

Comment sécuriser la requête

La sécurisation de la requête est effectuée en calculant la valeur «hashée» conformément aux paramètres de la transaction (donnée Data). Ensuite, la clé secrète y est ajoutée. Toutes les chaînes de caractères sont converties en UTF-8 avant le «hashage».

L’algorithme de «hashage» génère un résultat irréversible. Lorsqu’un tel message est reçu, le destinataire doit recalculer la valeur «hashée» pour la comparer à celle reçue. Toute différence indique que les données échangées ont été falsifiées ou que le destinataire et l’émetteur ne partage pas la même clé secrète.

Le résultat doit être envoyé sous forme hexadécimale la donnée nommée Seal.

Calcul de la donnée Seal

La valeur de la donnée Seal est calculée comme suit:

Pour l’algorithme HMAC-SHA :

  • Utilisation de la clé secrète partagée pour générer la variante HMAC du message
  • Utilisation de la donnée Data uniquement (encodée si l’option correspondante est choisie)
  • Codage UTF-8 des données constituant le résultat de l’opération précédente
  • «Hashage» HMAC-SHA des octets obtenus

Cette procédure peut être résumée comme suit :

HMAC-SHA256( UTF-8(Data), UTF-8(secretKey))

Pour l’algorithme SHA-256 (bien que celui-ci soit la valeur par défaut, cet algorithme n’est plus recommandé à ce jour) :

  • Concaténation de la donnée Data et de la clé secrète (encodée si l’option correspondante est choisie)
  • Codage UTF-8 des données constituant le résultat de l’opération précédente
  • «Hashage» SHA256 des octets obtenus

Cette procédure peut être résumée comme suit:

SHA256( UTF-8(Data+secretKey ) )
Exemples de code pour encoder
Exemple d’encodage Hmac Sha256
  • Exemple d’encodage Hmac Sha256 en Php 5
<?php
…
echo hash_mac('sha256', $data, $secretKey);
…
?>

Le jeu de caractères UTF-8 doit être utilisé pour les données Data et secretKey. Pour effectuer une conversion de ISO-8859-1 à UTF-8, faites appel à la fonction utf8_encode.

  • Exemple d’encodage Hmac Sha256 en Java
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException

import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;

public class ExampleHMACSHA256 {

	/**
	 * table to convert a nibble to a hex char.
	 */
	static final char[] hexChar = {
	   '0' , '1' , '2' , '3' ,
	   '4' , '5' , '6' , '7' ,
	   '8' , '9' , 'a' , 'b' ,
	   'c' , 'd' , 'e' , 'f'};

	/**
	 * Fast convert a byte array to a hex string
	 * with possible leading zero.
	 * @param b array of bytes to convert to string
	 * @return hex representation, two chars per byte.
	 */
	public static String encodeHexString ( byte[] b )
	   {
	   StringBuffer sb = new StringBuffer( b.length * 2 );
	   for ( int i=0; i<b.length; i++ )
	      {
	      // look up high nibble char
	      sb.append( hexChar [( b[i] & 0xf0 ) >>> 4] );

	      // look up low nibble char
	      sb.append( hexChar [b[i] & 0x0f] );
	      }
	   return sb.toString();
	   }

	/**
	 * Computes the seal
	 * @param Data the parameters to cipher
	 * @param secretKey the secret key to append to the parameters 
	 * @return hex representation of the seal, two chars per byte.
	 */
	public static String computeSeal(String data, String secretKey) throws Exception
	{
  Mac hmacSHA256 = Mac.getInstance("HmacSHA256");
  SecretKeySpec keySpec = new SecretKeySpec(secretKey, "HmacSHA256");
  hmacSHA256.init(keySpec);

  return encodeHexString(hmacSHA256.doFinal(data));
	}
	
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		try {
			System.out.println (computeSeal("parameters", "key"));
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

}
  • Exemple d’encodage Hmac Sha256 en.net

Complété à l’aide d’un simple formulaire appelé «Form 1» contenant deux champs de texte à renseigner: txtSips, txtSecretKey et un autre à afficher: lblHEX.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Security.Cryptography;

namespace ExampleDotNET
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void cmdGO_Click(object sender, EventArgs e)
        {
            String sChaine = txtSips.Text;
            UTF8Encoding utf8 = new UTF8Encoding();
            Byte[] encodedBytes = utf8.GetBytes(sChaine);
        
            byte[] shaResult;
            
            HMAC hmac = new HMAC.Create("HMACSHA256");
            var key = "YourSecretKey";
            hmac.Key = utf8.GetBytes(key); 
            hmac.Initialize();

            shaResult = hmac.ComputeHash( encodedBytes);

            lblHEX.Text = ByteArrayToHEX(shaResult);
        }

        private string ByteArrayToHEX(byte[] ba)
        {
            StringBuilder hex = new StringBuilder(ba.Length * 2);
            foreach (byte b in ba)
                hex.AppendFormat("{0:x2}", b);
            return hex.ToString();
        }

    }
}
Exemple d’encodage Sha256
  • Exemple d’encodage Sha256 en Php 5
<?php
   echo hash('sha256',$data.$secretKey);
?>

Le jeu de caractères UTF-8 doit être utilisé pour les données Data et secretKey. Pour effectuer une conversion de ISO-8859-1 à UTF-8, faites appel à la fonction utf8_encode.

  • Exemple d’encodage Sha256 en Java
import java.security.MessageDigest;

public class ExampleSHA256 {

	/**
	 * table to convert a nibble to a hex char.
	 */
	static final char[] hexChar = {
	   '0' , '1' , '2' , '3' ,
	   '4' , '5' , '6' , '7' ,
	   '8' , '9' , 'a' , 'b' ,
	   'c' , 'd' , 'e' , 'f'};

	/**
	 * Fast convert a byte array to a hex string
	 * with possible leading zero.
	 * @param b array of bytes to convert to string
	 * @return hex representation, two chars per byte.
	 */
	public static String encodeHexString ( byte[] b )
	   {
	   StringBuffer sb = new StringBuffer( b.length * 2 );
	   for ( int i=0; i<b.length; i++ )
	      {
	      // look up high nibble char
	      sb.append( hexChar [( b[i] & 0xf0 ) >>> 4] );

	      // look up low nibble char
	      sb.append( hexChar [b[i] & 0x0f] );
	      }
	   return sb.toString();
	   }

	/**
	 * Computes the seal
	 * @param Data the parameters to cipher
	 * @param secretKey the secret key to append to the parameters 
	 * @return hex representation of the seal, two chars per byte.
	 */
	public static String computeSeal(String Data, String secretKey) throws Exception
	{
	  MessageDigest md = MessageDigest.getInstance("SHA-256");
	  md.update((Data+secretKey).getBytes("UTF-8"));

	  return encodeHexString(md.digest());
	}
	
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		try {
			System.out.println (computeSeal("parameters", "key"));
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}
  • Exemple d’encodage Sha256 en .NET

Complété à l’aide d’un simple formulaire appelé «Form 1» contenant deux champs de texte à renseigner: txtSips, txtSecretKey et un autre à afficher: lblHEX.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Security.Cryptography;

namespace ExampleDotNET
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void cmdGO_Click(object sender, EventArgs e)
        {
            String sChaine = txtSips.Text + txtSecretKey.Text;
            UTF8Encoding utf8 = new UTF8Encoding();
            Byte[] encodedBytes = utf8.GetBytes(sChaine);
        
            byte[] shaResult;
            SHA256 shaM = new SHA256Managed();
            shaResult = shaM.ComputeHash(encodedBytes);

            lblHEX.Text = ByteArrayToHEX(shaResult);
        }

        private string ByteArrayToHEX(byte[] ba)
        {
            StringBuilder hex = new StringBuilder(ba.Length * 2);
            foreach (byte b in ba)
                hex.AppendFormat("{0:x2}", b);
            return hex.ToString();
        }

    }
}
Outil de calcul de la signature

[Cliquer ici pour simuler un calcul de la signature]

Exemple de requête de paiement
Exemple simple d'appel de Mercanet

L'exemple simple ci-dessous, écrit en PHP, vous permet de comprendre comment envoyer une requête de paiement à Mercanet :

<?php
  // Génère un numéro de transaction aléatoire
  $transactionReference = "simu" . rand(100000,999999);
  // Construit l'URL de retour pour récupérer le résultat du paiement sur le site e-commerce du marchand
  $normalReturnUrl = "https://www.marchand.com/normal_return.php";
  // Contruit la requête des données à envoyer à Mercanet
  $data = "amount=100|currencyCode=978|merchantId=211000021310001|normalReturnUrl=".$normalReturnUrl."|transactionReference=".$transactionReference."|keyVersion=1";
  // Encode en UTF-8 des données à envoyer à Mercanet
  $dataToSend= utf8_encode($data);
  // Clé secrète correspondant au merchandId de simulation
  $secretKey = "S9i8qClCnb2CZU3y3Vn0toIOgz3z_aBi79akR30vM9o";
  // Calcul du certificat par un cryptage SHA256 des données envoyées suffixé par la clé secrète
  $seal=hash('sha256', $dataToSend.$secretKey);
  // Envoi des données à Mercanet par un formulaire POST
?>
<form method="post" action="https://payment-webinit-mercanet.test.sips-atos.com/paymentInit">
  <input type="hidden" name="Data" value="<?php echo $data; ?>">
  <input type="hidden" name="InterfaceVersion" value="HP_2.20">
  <input type="hidden" name="Seal" value="<?php echo $seal; ?>">
  <input type="submit" value="Payer"><br>
</form>

[Démonstration d'un paiement simple]

Exemple d'un paiement N fois

[Démonstration d'un paiement en n fois]

Exemple simple de traitement de la réponse de Mercanet

L'exemple simple ci-dessous, écrit en PHP, vous permet de comprendre comment réceptionner la réponse de Mercanet :

<?php
  $chaine = "";
  foreach($_POST as $k => $v)
  {
    if (strlen($v) > 0)
    {
      $chaine .= $k . '=' . $v ."<br>"; 
    }
  }
  echo "Retour = " . $chaine;
?>

Dans le programme de retour, il faut :

  • vérifier le seal retourné par Mercanet pour s'assurer que c'est bien Mercanet qui a fait la réponse au site e-commerce du marchand,
  • vérifier le résultat du paiement avec le champ responseCode contenu dans le champ POST Data
  • mettre à jour la commande du client avec le résultat du paiement
Kit de démarrage

Veuillez trouver ci-après des exemples de programmes plus complet écrit en PHP vous permettant de mettre en oeuvre l'appel à la page de paiement de Mercanet :

  • Kit pour le connecteur POST
    Vous pourrez tester les différents moyens de paiement:
    • Paiement differé
    • paiement N fois
    • Paiement One click
    • Paiement simple
    • Paiement avec choix du moyen de paiement
    • Retour url


  • Kit pour l'iFrame
    Vous pourrez tester l'affichage de la page de paiement en mode iFrame et voir le résultat du paiement :
    • sur Mercanet
    • sur le site marchand


  • Kit pour l'encodage
    Vous pourrez tester avec cet exemple :
    • l'appel de la page de paiement avec un encodage en base64 des données (utile par exemple pour transmettre des paramètres avec des accents),
    • le retour des paramétres envoyés par Mercanet avec un encodage en base64.


Il vous suffit pour cela de télécharger l'un des fichier zip ci-dessus, de décompresser le contenu du fichier zip et de mettre le contenu sur votre serveur Web.

Traiter les erreurs lors de l’initialisation du paiement

Tous les champs reçus par Mercanet Paypage POST à travers le connecteur font l’objet d’une vérification individuelle.

Le tableau ci-dessous présente la liste des messages d’erreur pouvant s’afficher lors de cette étape ainsi que les solutions à mettre en œuvre.

Remarque

Les messages sont affichés sur la plate-forme de simulation pour vous aider à valider l’intégration de votre site Web. Pour des raisons de sécurité, des messages d’erreur beaucoup plus simples sont affichés sur la plate-forme de production. Ex «Erreur lors du traitement de la requête de paiement. Contactez votre commerçant».


Message

Cause

Solution

Unknown version interface: <version>

La valeur <version> dans le champ InterfaceVersion est inconnue

Vérifier la version d’interface dans ce guide d’utilisation (la version actuelle est la version HP_2.20)

Invalid keyword: <nomChamp>= <valeur Champ>

Le champ <nomChamp> n’est pas prévu dans la requête de paiement

Vérifier le nom des champs dans le chapitre ci-dessous et dans le dictionnaire de données

Invalid field size: <nomChamp>= <valeur Champ>

Le champ <nomChamp> a une longueur incorrecte

Vérifier la longueur du champ dans le dictionnaire de données

Invalid field value: <nomChamp >= <valeur Champ>

La valeur du champ <nomChamp> est incorrecte

Vérifier les valeurs possibles du champ dans le dictionnaire de données

Mandatory field missing: <nomChamp >

Le champ <nomChamp> est manquant dans la requête de paiement

Vérifier les champs obligatoires de la requête de paiement dans le chapitre ci-dessous

Unknown security version: <version>

La valeur <version> du champ keyVersion est inconnue

Vérifier les versions des clés disponibles dans Mercanet

Invalid signature

La vérification du Seal de la requête de paiement a échoué. Cela peut être causé par un calcul incorrect de la donnée Seal ou peut indiquer la falsification de certains champs après le calcul de la signature.

Vérifier que le calcul du Seal est effectué comme indiqué dans le chapitre précédent. Si c’est le cas, demander un changement de clé secrète via Mercanet Téléchargement car la requête a été falsifiée

Transaction already processed: <référence de la transaction>

Une requête de paiement avec le même transactionReference a déjà été reçue et prise en charge par les serveurs Mercanet

Vérifier sila valeur du champ transactionReference est unique pour la transaction concernée

<Autres messages>

Dans le cas d’erreurs techniques, d’autres messages différents peuvent s’afficher

Contacter le service d’assistance technique

Traiter la réponse aux erreurs d’initialisation du paiement

Il est possible d’activer l’envoi d’une réponse manuelle et/ou automatique en cas d’erreur lors de l’initialisation de paiement grâce au paramétrage Paypages sur le contrat marchand. Deux types de réponse sont prévus. Bien que les protocoles, formats et contenus des deux réponses soient exactement les mêmes, elles doivent être gérées de manière différente car elles répondent à deux besoins différents. Les réponses aux erreurs d’initialisation de paiement sont des réponses HTTP(S) POST envoyées aux l’URL manualErrorResponseInitPOST (optionnel) et automaticErrorResponseInitPOST (optionnel) précisées dans la requête. Si vous souhaitez utiliser ces réponses, vous devez mettre en place le système permettant de les décoder, afin de connaitre la raison de l’erreur rencontrée. Les deux données suivantes sont définies dans les réponses:

Données

Notes/règles

Data

Concaténation des champs en réponse

Seal

Signature du message réponse

La chaîne concaténée est structurée comme suit:

redirectionStatusCode=valeur1|redirectionStatusMessage=valeur2

Cette chaîne concaténée est convertie en UTF-8 avant le «hashage».
Le sceau (donnée Seal) des 2 réponses est « hashé » avec le même algorithme utilisé en entrée et fourni dans le champ sealAlgorithm. Si aucune valeur n’a été définie, la valeur SHA-256 est utilisée par défaut.

Renseigner l’URL de la réponse manuelle aux erreurs d’initialisation du paiement

L’objectif principal de la réponse manuelle aux erreurs d’initialisation de paiement est de rediriger le client vers votre site Web avec la raison de l’erreur pour que vous puissiez prendre la bonne décision le concernant. Par exemple, en cas d’erreur sur une donnée renseignée par le client, vous pouvez lui suggérer de retenter le paiement avec un format correct. Dans le cas d’une erreur sur une donnée indépendante du client, vous pouvez l’inviter à vous contacter pour résoudre la situation. À la première étape, un bouton «Retour» est affiché sur la page d’erreur chez Mercanet avec un lien de redirection vers votre site. Lorsque le client clique sur ce bouton, le serveur Mercanet le redirige vers l’adresse URL contenue dans le champ manualErrorResponseInitPOST fourni dans la requête. La redirection est une requête HTTP(S) POST qui contient les données de la réponse, tels que décrits ci-dessus. Il est de votre responsabilité de récupérer ces paramètres et de vérifier la signature pour ainsi assurer l’intégrité des données de la réponse. De plus, vous êtes responsable d’afficher les messages pertinents (relatifs aux détails de la réponse) à votre client. Il est important de noter qu’il est impossible de garantir la réception de la réponse, celle-ci étant envoyée par le navigateur Web du client. Tout d’abord, le client a la possibilité de ne pas cliquer sur le lien. Ensuite, la connexion qu’il utilise peut tout simplement avoir un problème et bloquer l’envoi de cette réponse. Par conséquent, celle-ci ne peut pas constituer la base unique pour vos processus métier.

Renseigner l’URL de la réponse automatique aux erreurs d’initialisation du paiement

La réponse automatique est envoyée seulement si le champ automaticErrorResponseInitPOST a été envoyé dans la requête de paiement. Si tel est le cas, le serveur Mercanet envoie une réponse HTTP(S) POST à l’adresse URL reçue. Les champs de la réponse automatique sont identiques à ceux de la réponse manuelle. La seule différence entre les deux procédures est que la réponse automatique est envoyée directement par le serveur Mercanet sans passer par le navigateur Web du client. Par conséquent, elle est bien plus fiable car elle est toujours envoyée. Le serveur Mercanet n’attend aucune réponse après l’envoi de la réponse automatique. Il vous appartient de récupérer les différentes données de la réponse, vérifier la signature pour vous assurer de l’intégrité des champs de la réponse et, par conséquent, mettre à jour votre back office.

Résoudre les problèmes de réception des réponses aux erreurs d’initialisation

Comme pour les réponses manuelle et automatique de paiement, ces réponses peuvent être bloquées. Les mêmes conseils s’appliquent pour résoudre ces problèmes (voir chapitre [Résoudre les problèmes de réception des réponses]).

Récupérer les champs des réponses aux erreurs d’initialisation

Le contenu des réponses automatique et manuelle aux erreurs d’initialisation de Mercanet Paypage est invariable. Quel que soit l’erreur rencontrée lors de l’initialisation de paiement, la réponse contiendra les champs suivant:

Champ

Commentaires

redirectionStatusCode

redirectionStatusMessage

merchantId

transactionReference

transactionId

transactionDate

transactionDateTime

amount

customerId

orderId

customerIpAddress

Renseigner les champs de la requête

Champs génériques

Nom du champ

Présence

version

Commentaires

amount

Obligatoire

HP_1.0

currencyCode

Obligatoire

HP_1.0

keyVersion

Obligatoire

HP_1.0

merchantId

Obligatoire

HP_1.0

normalReturnUrl

Obligatoire

HP_1.0

transactionReference

Obligatoire

HP_1.0

Facultatif si vous utilisez le S10TransactionReference

s10TransactionReference

Obligatoire

HP_2.2

Facultatif si vous utilisez le transactionReference . Voir ci-dessous

automaticResponseUrl

Optionnel

HP_1.0

billingFirstDate

Optionnel

HP_2.5

bypassDcc

Optionnel

HP_2.11

captureDay

Optionnel

HP_1.0

captureMode

Optionnel

HP_1.0

customer3DSTransactionDate

Optionnel

HP_2.5

customerBillingNb

Optionnel

HP_2.5

customerDeliverySuccessFlag

Optionnel

HP_2.5

customerId

Optionnel

HP_2.0

customerIpAddress

Optionnel

HP_2.1

customerLanguage

Optionnel

HP_1.0

customerPhoneValidationMethod

Optionnel

HP_2.5

customerRegistrationDateOnline

Optionnel

HP_2.5

customerRegistrationDateProxi

Optionnel

HP_2.5

deliveryFirstDate

Optionnel

HP_2.5

evidenceAcquisitionDate

Optionnel

HP_2.5

evidenceNumber

Optionnel

HP_2.5

evidenceType

Optionnel

HP_2.5

expirationDate

Optionnel

HP_1.0

hashAlgorithm1

Optionnel

HP_2.3

hashAlgorithm2

Optionnel

HP_2.3

hashSalt1

Optionnel

HP_2.1

hashSalt2

Optionnel

HP_2.1

holderAdditionalReference

Optionnel

HP_2.9

intermediateServiceProviderId

Optionnel

HP_2.12

invoiceReference

Optionnel

HP_2.0

mandateId

Optionnel

HP_2.5

merchantSessionId

Optionnel

HP_2.0

merchantTransactionDateTime

Optionnel

HP_2.0

merchantWalletID

Optionnel

HP_2.2

orderChannel

Optionnel

HP_2.1

orderId

Optionnel

HP_1.0

paymentMeanBrandList

Optionnel

HP_1.0

paymentPattern

Conditionnel

HP_2.1

Ce champ est obligatoire pour certain moyens de paiement. Se référer au guide d’implémentation du moyen de paiement concerné pour plus de détail.

returnContext

Optionnel

HP_2.0

riskManagementCustomDataList

Optionnel

HP_2.9

Une liste d’objet riskManagementCustomData

statementReference

Optionnel

HP_2.3

subMerchantCategoryCode

Optionnel

HP_2.15

subMerchantId

Optionnel

HP_2.15

subMerchantLegalId

Optionnel

HP_2.15

subMerchantShortName

Optionnel

HP_2.15

templateName

Optionnel

HP_2.1

transactionActors

Optionnel

HP_2.2

transactionOrigin

Optionnel

HP_2.0

valueDate

Optionnel

HP_2.5

automaticErrorResponseInitPOST

Optionnel

HP_2.19

manualErrorResponseInitPOST

Optionnel

HP_2.19

fraudData

Optionnel

HP_2.1

Voir ci-dessous

riskManagementDynamicSetting

Optionnel

HP_2.10

Voir ci-dessous

paypageData

Optionnel

HP_2.0

Voir ci-dessous

authenticationData

Optionnel

HP_2.2

Voir ci-dessous

paymentMeanData

Optionnel

HP_2.2

Voir ci-dessous

instalmentData

Optionnel

HP_2.2

Voir ci-dessous

billingAddress

Optionnel

HP_2.2

Voir ci-dessous

billingContact

Optionnel

HP_2.2

Voir ci-dessous

customerAddress

Optionnel

HP_2.2

Voir ci-dessous

customerContact

Optionnel

HP_2.2

Voir ci-dessous

customerData

Optionnel

HP_2.2

Voir ci-dessous

deliveryAddress

Optionnel

HP_2.2

Voir ci-dessous

deliveryContact

Optionnel

HP_2.2

Voir ci-dessous

deliveryData

Optionnel

HP_2.2

Voir ci-dessous

holderAddress

Optionnel

HP_2.2

Voir ci-dessous

holderContact

Optionnel

HP_2.2

Voir ci-dessous

shoppingCartDetail

Optionnel

HP_2.2

Voir ci-dessous

shoppingCartItem

Optionnel

HP_2.2

Voir ci-dessous

riskManagementCustomData

Optionnel

HP_2.2

Voir ci-dessous

subMerchantAddress

Optionnel

HP_2.2

Voir ci-dessous

orderContext

Optionnel

HP_2.2

Voir ci-dessous

travelContext

Optionnel

HP_2.2

Voir ci-dessous

subMerchantName

Optionnel

HP_2.20

subMerchantContractNumber

Optionnel

HP_2.20

customerAccountHistoric

Facultatif

HP_2.21

Voir la partie Containers

Champs optionnels relatifs à la fraude
  • Contenu de fraudData :

Champ

Présence

Version

Commentaires

allowedCardArea

Optionnel

HP_2.1

allowedCardCountryList

Optionnel

HP_2.1

allowedIpArea

Optionnel

HP_2.1

allowedIpCountryList

Optionnel

HP_2.1

bypass3DS

Optionnel

HP_2.1

bypassCtrlList

Optionnel

HP_2.1

bypassInfoList

Optionnel

HP_2.1

deniedCardArea

Optionnel

HP_2.1

deniedCardCountryList

Optionnel

HP_2.1

deniedIpArea

Optionnel

HP_2.1

deniedIpCountryList

Optionnel

HP_2.1

riskManagementDynamicSettingList

Optionnel

HP_2.10

Une liste d’objet riskManagementDynamicSetting

challengeMode3DS

Optionnel

HP_2.21

addressDeliveryBillingMatchIndicator

Optionnel

HP_2.21

nameDeliveryCustomerMatchIndicator

Optionnel

HP_2.21

reorderProductIndicator

Optionnel

HP_2.21

productAvailabilityIndicator

Optionnel

HP_2.21

  • Contenu de riskManagementDynamicSetting :

Champ

Présence

Version

Commentaires

riskManagementDynamicParam

Conditionnel

HP_2.10

riskManagementDynamicValue

Conditionnel

HP_2.10

Champ optionnel relatif aux pages de paiement
  • Contenu de paypageData

Champ

Présence

Version

Commentaires

bypassReceiptPage

Optionnel

HP_2.0

Champs optionnels relatifs à l’authentification du porteur
  • Contenu de authenticationData :

Champ

Présence

Version

Commentaires

issuerWalletPolicy

Optionnel

HP_2.2

Voir ci-dessous

cardAuthPolicy

Optionnel

HP_2.2

Voir ci-dessous

  • Contenu deissuerWalletPolicy :

Champ

Présence

Version

Commentaires

check3DS

Optionnel

HP_2.2

checkCSC

Optionnel

HP_2.2

  • Contenu de cardAuthPolicy :

Champ

Présence

Version

Commentaires

checkAVS

Optionnel

HP_2.8

ignoreAddressCheckResult

Optionnel

HP_2.8

ignorePostcodeCheckResult

Optionnel

HP_2.8

ignoreCSCCheckResult

Optionnel

HP_2.17

Champs optionnels relatifs aux moyens de paiement
  • Contenu de paymentMeanData :

Champ

Présence

version

Commentaires

paypal

Optionnel

HP_2.2

Voir ci-dessous

sdd

Optionnel

HP_2.2

Voir ci-dessous

cofinoga3xcb

Optionnel

HP_2.2

Voir ci-dessous

passbe

Optionnel

HP_2.5

Voir ci-dessous

accord

Optionnel

HP_2.6

Voir ci-dessous

facilypay

Optionnel

HP_2.6

Voir ci-dessous

cetelemNxcb

Optionnel

HP_2.9

Voir ci-dessous

presto

Optionnel

HP_2.10

Voir ci-dessous

cofidis3x

Optionnel

HP_2.11

Voir ci-dessous

cofidis4x

Optionnel

HP_2.12

Voir ci-dessous

unEuroCom

Optionnel

HP_2.11

Voir ci-dessous

cofinoga

Optionnel

HP_2.15

Voir ci-dessous

cetelem3x

Optionnel

HP_2.16

Voir ci-dessous

cetelem4x

Optionnel

HP_2.16

Voir ci-dessous

franfinance3xcb

Optionnel

HP_2.18

Voir ci-dessous

franfinance4xcb

Optionnel

HP_2.18

Voir ci-dessous

Accordkdo

Optionnel

HP_2.18

Voir ci-dessous

visaCheckout

Optionnel

HP_2.21

Voir ci-dessous

  • Contenu de paypal :

Champ

Présence

version

Commentaires

addrOverride

Optionnel

HP_2.2

dupCustom

Optionnel

HP_2.2

dupDesc

Optionnel

HP_2.2

dupFlag

Optionnel

HP_2.2

dupType

Optionnel

HP_2.2

invoiceId

Optionnel

HP_2.2

landingPage

Optionnel

HP_2.2

mobile

Optionnel

HP_2.2

orderDescription

Optionnel

HP_2.16

  • Contenu de sdd :

Champ

Présence

Version

Commentaires

mandateAuthentMethod

Optionnel

HP_2.2

mandateCertificationType

Optionnel

HP_2.5

mandateUsage

Optionnel

HP_2.2

  • Contenu de cofinoga3xcb :

Champ

Présence

Version

Commentaires

creditIndicator

Optionnel

HP_2.4

  • Contenu de passbe :

Champ

Présence

Version

Commentaires

settlementModeList

Optionnel

HP_2.5

  • Contenu d’accord :

Champ

Présence

Version

Commentaires

settlementMode

Optionnel

HP_2.6

  • Contenu de facilypay :

Champ

Présence

Version

Commentaires

depositRefundIndicator

Optionnel

HP_2.6

receiverType

Optionnel

HP_2.6

settlementMode

Optionnel

HP_2.6

settlementModeVersion

Optionnel

HP_2.6

  • Contenu de cetelemNxcb :

Champ

Présence

Version

Commentaires

nxcbTransactionReference1

Optionnel

HP_2.9

nxcbTransactionReference2

Optionnel

HP_2.9

s10NxcbTransactionId1

Optionnel

HP_2.9

s10NxcbTransactionId2

Optionnel

HP_2.9

  • Contenu de presto :

Champ

Présence

Version

Commentaires

financialProduct

Conditionnel

HP_2.10

paymentMeanCustomerId

Conditionnel

HP_2.10

prestoCardType

Optionnel

HP_2.10

  • Contenu de cofidis3x :

Champ

Présence

Version

Commentaires

basket

Optionnel

HP_2.20

cofidisDisplayCancelButton

Optionnel

HP_2.11

cofidisPrivateData

Optionnel

HP_2.11

preScoreValue

Optionnel

HP_2.11

  • Contenu de cofidis4x :

Champ

Présence

Version

Commentaires

cofidisDisplayCancelButton

Optionnel

HP_2.12

cofidisPrivateData

Optionnel

HP_2.12

preScoreValue

Optionnel

HP_2.12

  • Contenu de unEuroCom :

Champ

Présence

Version

Commentaires

cofidisPrivateData

Optionnel

HP_2.11

preScoreValue

Optionnel

HP_2.11

  • Contenu de cofinoga :

Champ

Présence

Version

Commentaires

paymentMeanTradeOptionList

Optionnel

HP_2.15

Une liste d’objet paymentMeanTradeOption

  • Contenu de paymentMeanTradeOption:

Champ

Présence

Version

Commentaires

paymentMeanTradingName

Optionnel

HP_2.15

settlementModeList

Optionnel

HP_2.15

  • Contenu de cetelem3x :

Champ

Présence

Version

Commentaires

cetelemPrivateMerchantData

Optionnel

HP_2.16

cetelemPrivateData

Optionnel

HP_2.16

  • Contenu de cetelem4x :

Champ

Présence

Version

Commentaires

cetelemPrivateMerchantData

Optionnel

HP_2.16

cetelemPrivateData

Optionnel

HP_2.16

  • Contenu de franfinance3xcb :

Champ

Présence

Version

Commentaires

authenticationKey

Conditionnel

HP_2.18

Obligatoire uniquement pour une transaction franfinance

pageCustomizationCode

Optionnel

HP_2.18

redirectionTimer

Optionnel

HP_2.18

testEnvironment

Optionnel

HP_2.18

birthPlaceCode

Optionnel

HP_2.18

  • Contenu de franfinance4xcb :

Champ

Présence

Version

Commentaires

authenticationKey

Conditionnel

HP_2.18

Obligatoire uniquement pour une transaction franfinance

pageCustomizationCode

Optionnel

HP_2.18

redirectionTimer

Optionnel

HP_2.18

testEnvironment

Optionnel

HP_2.18

birthPlaceCode

Optionnel

HP_2.18


  • Contenu de accordkdo :

Champ

Présence

Version

Commentaires

blockAmountModification

Optionnel

HP_2.18


  • Contenu de visaCheckout

Champ

Présence

Version

Commentaires

visaCheckoutCallID

Optionnel

HP_2.21

Champs optionnels relatifs au paiement échelonné
  • Contenu d’instalmentData :

Champ

Présence

Version

Commentaires

number

Optionnel

HP_2.2

datesList

Optionnel

HP_2.2

transactionReferencesList

Conditionnel

HP_2.2

s10TransactionIdsList

Conditionnel

HP_2.7

amountsList

Optionnel

HP_2.2

Champs optionnel relatifs à l’adresse de facturation du client
  • Contenu de billingAddress :

Champ

Présence

Version

Commentaires

addressAdditional1

Optionnel

HP_2.2

addressAdditional2

Optionnel

HP_2.2

addressAdditional3

Optionnel

HP_2.2

city

Optionnel

HP_2.2

company

Optionnel

HP_2.2

country

Optionnel

HP_2.2

postBox

Optionnel

HP_2.2

state

Optionnel

HP_2.2

street

Optionnel

HP_2.2

streetNumber

Optionnel

HP_2.2

zipCode

Optionnel

HP_2.2

Tableau 1: Champs prévus pour l’élément billingAddress

  • Contenu de billingContact :
Contenu de customerAccountHistoric :

Champ

Présence

Version

Commentaires

email

Optionnel

HP_2.2

firstname

Optionnel

HP_2.2

gender

Optionnel

HP_2.2

lastname

Optionnel

HP_2.2

mobile

Optionnel

HP_2.2

phone

Optionnel

HP_2.2

title

Optionnel

HP_2.2

Champ

Présence

Version

Commentaires

creationDate

HP_2.21

numberOfAttemptsAddCard24Hours

HP_2.21

numberOfPurchase180Days

HP_2.21

numberOfTransaction24Hours

HP_2.21

suspiciousActivityIndicator

HP_2.21

Champs optionnels relatifs à l’adresse du client
  • Contenu de customerAddress :

Champ

Présence

Version

Commentaires

addressAdditional1

Optionnel

HP_2.2

addressAdditional2

Optionnel

HP_2.2

addressAdditional3

Optionnel

HP_2.2

city

Optionnel

HP_2.2

company

Optionnel

HP_2.2

country

Optionnel

HP_2.2

postBox

Optionnel

HP_2.2

state

Optionnel

HP_2.2

street

Optionnel

HP_2.2

streetNumber

Optionnel

HP_2.2

zipCode

Optionnel

HP_2.2

businessName

Optionnel

HP_2.17

  • Contenu de customerContact :

Champ

Présence

Version

Commentaires

email

Optionnel

HP_2.2

firstname

Optionnel

HP_2.2

gender

Optionnel

HP_2.2

lastname

Optionnel

HP_2.2

mobile

Optionnel

HP_2.2

phone

Optionnel

HP_2.2

title

Optionnel

HP_2.2

legalId

Optionnel

HP_2.17

positionOccupied

Optionnel

HP_2.17

workPhone

Optionnel

HP_2.21

  • Contenu de customerData :

Champ

Présence

Version

Commentaires

birthCity

Optionnel

HP_2.2

birthCountry

Optionnel

HP_2.2

birthDate

Optionnel

HP_2.2

birthZipCode

Optionnel

HP_2.2

nationalityCountry

Optionnel

HP_2.2

newPwd

Optionnel

HP_2.2

Pwd

Optionnel

HP_2.2

maidenName

Optionnel

HP_2.18

Champs optionnels relatifs à l’adresse de livraison du client
  • Contenu de deliveryAddress :

Champ

Présence

Version

Commentaires

addressAdditional1

Optionnel

HP_2.2

addressAdditional2

Optionnel

HP_2.2

addressAdditional3

Optionnel

HP_2.2

city

Optionnel

HP_2.2

company

Optionnel

HP_2.2

country

Optionnel

HP_2.2

postBox

Optionnel

HP_2.2

state

Optionnel

HP_2.2

street

Optionnel

HP_2.2

streetNumber

Optionnel

HP_2.2

zipCode

Optionnel

HP_2.2

  • Contenu de deliveryContact :

Champ

Présence

Version

Commentaires

email

Optionnel

HP_2.2

firstname

Optionnel

HP_2.2

gender

Optionnel

HP_2.2

lastname

Optionnel

HP_2.2

mobile

Optionnel

HP_2.2

phone

Optionnel

HP_2.2

title

Optionnel

HP_2.2

initials

Optionnel

HP_2.11

legalId

Optionnel

HP_2.17

positionOccupied

Optionnel

HP_2.17

workPhone

Optionnel

HP_2.21

  • Contenu de deliveryData :

Champ

Présence

Version

Commentaires

deliveryChargeAmount

Optionnel

HP_2.6

deliveryMethod

Optionnel

HP_2.6

deliveryMode

Optionnel

HP_2.6

deliveryOperator

Optionnel

HP_2.6

estimatedDeliveryDate

Optionnel

HP_2.6

estimatedDeliveryDelay

Optionnel

HP_2.7

deliveryAddressCreationDate

Optionnel

HP_2.21

electronicDeliveryIndicator

Optionnel

HP_2.21

Champs optionnels relatifs aux données du titulaire de la carte
  • Contenu de holderAddress :

Champ

Présence

Version

Commentaires

addressAdditional1

Optionnel

HP_2.2

addressAdditional2

Optionnel

HP_2.2

addressAdditional3

Optionnel

HP_2.2

city

Optionnel

HP_2.2

company

Optionnel

HP_2.2

country

Optionnel

HP_2.2

postBox

Optionnel

HP_2.2

state

Optionnel

HP_2.2

street

Optionnel

HP_2.2

streetNumber

Optionnel

HP_2.2

zipCode

Optionnel

HP_2.2

  • Contenu de holderContact :

Champ

Présence

Version

Commentaires

email

Optionnel

HP_2.2

firstname

Optionnel

HP_2.2

gender

Optionnel

HP_2.2

lastname

Optionnel

HP_2.2

mobile

Optionnel

HP_2.2

phone

Optionnel

HP_2.2

title

Optionnel

HP_2.2

initials

Optionnel

HP_2.11

legalId

Optionnel

HP_2.17

positionOccupied

Optionnel

HP_2.17

workPhone

Optionnel

HP_2.21

Champs optionnels relatifs au panier
  • Contenu de shoppingCartDetail :

Champ

Présence

Version

Commentaires

mainProduct

Optionnel

HP_2.6

shoppingCartItemList

Optionnel

HP_2.6

Une liste de shoppingCartItem

shoppingCartTotalAmount

Optionnel

HP_2.6

shoppingCartTotalQuantity

Optionnel

HP_2.6

shoppingCartTotalTaxAmount

Optionnel

HP_2.7

  • Contenu de shoppingCartItem :

Champ

Présence

Version

Commentaires

productCategory

Optionnel

HP_2.6

productCode

Optionnel

HP_2.6

productDescription

Optionnel

HP_2.6

productName

Optionnel

HP_2.6

productQuantity

Optionnel

HP_2.6

productSKU

Optionnel

HP_2.6

productTaxCategory

Optionnel

HP_2.11

productTaxRate

Optionnel

HP_2.6

productUnitAmount

Optionnel

HP_2.6

productUnitTaxAmount

Optionnel

HP_2.6

Champs optionnels relatifs au transactionId Mercanet 1.0
  • Contenu de s10TransactionReference :

Champ

Présence

Version

Commentaires

s10TransactionId

Optionnel

HP_2.7

s10TransactionIdDate

Optionnel

HP_2.7

Champs optionnels relatifs à la gestion des risques
  • Contenu de riskManagementCustomData :

Champ

Présence

Version

Commentaires

riskManagementCustomSequence

Optionnel

HP _2.9

riskManagementCustomValue

Optionnel

HP _2.9

Champs optionnels relatifs aux données vendeurs (cas des marketplace)
  • Contenu de subMerchantAddress :

Champ

Présence

Version

Commentaires

addressAdditional1

Optionnel

HP_2.15

addressAdditional2

Optionnel

HP_2.15

addressAdditional3

Optionnel

HP_2.15

city

Optionnel

HP_2.15

company

Optionnel

HP_2.15

country

Optionnel

HP_2.15

postBox

Optionnel

HP_2.15

state

Optionnel

HP_2.15

street

Optionnel

HP_2.15

streetNumber

Optionnel

HP_2.15

zipCode

Optionnel

HP_2.15

Champs optionnels relatifs à AMEX-EA.
  • Contenu d’orderContext :

Champ

Présence

Version

Commentaires

customerHostName

Optionnel

HP_2.16

customerBrowserType

Optionnel

HP_2.16

customerANI

Optionnel

HP_2.16

customerANIInformationIdentifier

Optionnel

HP_2.16

travelContext.

Optionnel

HP_2.16

Voir ci-dessous

  • Contenu de travelContext :

Champ

Présence

Version

Commentaires

departureDate

Optionnel

HP_2.16

passengerName

Optionnel

HP_2.16

originAirport

Optionnel

HP_2.16

numberOfRoutingCities

Optionnel

HP_2.16

routingCitiesList

Optionnel

HP_2.16

numberOfAirlineCarriers

Optionnel

HP_2.16

airlineCarriersList

Optionnel

HP_2.16

fareBasis

Optionnel

HP_2.16

numberOfPassengers

Optionnel

HP_2.16

destinationAirport

Optionnel

HP_2.16

reservationCode

Optionnel

HP_2.16

Paramétrer la requête de paiement

Voici un exemple de paramétrage de la requête de paiement pour chaque fonctionnalité disponible dans Mercanet Paypage POST (le détail de ces fonctionnalités est décrit dans le guide des fonctionnalités).

Affichage dynamique des moyens de paiement

Il faut filtrer ceux qui s’afficheront dans la page de sélection des moyens de paiement grâce au champ paymentMeanBrandList:

..|paymentMeanBrandList=VISA,PAYPAL|..
Affichage du ticket par Mercanet

La page de confirmation du paiement, affichée par défaut par Mercanet peut être désactivée. Cette désactivation se fait par le champ paypageData.bypassReceiptPage:

..|paypageData.bypassReceiptPage=Y|..
Canal de paiement

Pour choisir votre canal de paiement, vous devez remplir le champ orderChannel dans la requête de paiement:

..|orderChannel= INTERNET|..
Paiement en fin de journée

Dans le cas d’un paiement en fin de journée, il suffit de remplir les champs captureMode et captureDay:

..|captureDay=0|captureMode=AUTHOR_CAPTURE|..
Paiement différé

Dans le cas d’un paiement à remiser N jours après l’acceptation en ligne, il suffit de remplir les champs captureMode et captureDay(3 jours dans notre exemple) :

…|captureDay=3|captureMode=AUTHOR_CAPTURE|..
Paiement à l’expédition

Dans le cas d’un paiement à l’expédition, la transaction est envoyée en paiement lors votre validation, il faut juste remplir les champs captureMode et captureDay(3 jours de délai possible avant validation dans notre exemple) :

…|captureDay=3|captureMode=VALIDATION|..
Paiement échelonné

Dans le cas d’un paiement en plusieurs échéances liées à une même transaction, il faut renseigner le champ paymentPattern à INSTALMENT et fournir le détail des échéances dans le champ instalmentData (600€ payés en 3 échéances dans notre exemple) :

…|amount=60000|…|transactionReference=tref1|…|paymentPattern=INSTALMENT|instalmentData.number=3|instalmentData.datesList=20170412,20170512,20170612|instalmentData.transactionReferencesList=tref1,tref2,tref3|instalmentData.amountsList=10000,30000,20000|..
Paiement immédiat

Si vous souhaitez un paiement immédiat (disponible uniquement pour certains moyens de paiement), la transaction est payée lors de l’autorisation en ligne :

…|captureMode=IMMEDIATE|..
Acceptation multidevises

Dans le casdes transactions multidevises le code devise doit être spécifié dans la requête. C’est dans le contrat d’acquisition qu’est précisée la devise de règlement.

…|currencyCode=840|..
Règlement en devises

L’acceptation et le règlement sont effectués dans la même devise qui doit être spécifiée dans la requête. Le règlement en devises est une option du contrat d’acquisition.

…|currencyCode=826|..
Conversion dynamique des devises (DCC)

Dans le cas où un service financier de conversion dynamique de devise (DCC) est utilisé, le code devise de référence doit être spécifié:

…|currencyCode=978|..
Débrayage dynamique du 3D Secure

Pour désactiver dynamiquement l’authentification 3D Secure, il faut spécifier cette action dans le champ fraudData.bypass3DS:

…|fraudData.bypass3DS=ALL|..
Débrayage 3D Secure pour paiement Oneclick

Pour désactiver dynamiquement l’authentification 3D Secure pour les paiements en One click, il faut spécifier cette action dans le champ fraudData.bypass3DS:

…|fraudData.bypass3DS= MERCHANTWALLET|..
Inscription et paiement Oneclick

Pour un paiement One click, l’identifiant du wallet du client doit être renseigné dans le champ merchantWalletId.

…|merchantWalletId=1205987|..
Prestataire agissant pour le compte d’un commerçant

Il faut passer l’identifiant du prestataire dans la requête dans le champ intermediateServiceProvider et utiliser la clé secrète de ce dernier pour calculer la donnée Seal:

..|intermediateServiceProviderId=241591|..

Traiter la réponse de paiement

Deux types de réponse sont prévus. Bien que les protocoles, formats et contenus des deux réponses soient exactement les mêmes, elles doivent être gérées de manière différente car elles répondent à deux besoins différents.

Les réponses de paiements sont des réponses HTTP(S) POST envoyées aux l’URL normalReturnUrl (obligatoire) et automaticResponseUrl (optionnel) précisées dans la requête.

Vous devez mettre en place le système permettant de décoder ces réponses, afin de connaitre le résultat du paiement.

Les quatre données suivantes sont définies dans les réponses:

Données

Notes/règles

Data

Concaténation des champs en réponse

Encode

Type d’encodage utilisé pour la donnée Data

Seal

Signature du message réponse

InterfaceVersion

Version de l’interface du connecteur

Si la valeur de la donnée Encode est “base64” ou “base64url”, la donnée Data doit-être décodée en Base64/Base64Url pour retrouver la chaîne des champs concaténée. La chaîne concaténée est structurée comme suit: clé1=valeur1|clé2=valeur2… Le sceau (donnée Seal) des 2 réponses est «hashé» avec le même algorithme utilisé en entrée et fourni dans le champ sealAlgorithm. Si aucune valeur n’a été définie, la valeur SHA-256 est utilisée par défaut.

Renseigner l’URL de la réponse manuelle

L’objectif principal de la réponse manuelle est de rediriger le client vers votre site Web avec le résultat du paiement pour que vous puissiez prendre la bonne décision le concernant. Par exemple, en cas d’erreur, vous pouvez suggérer de retenter le paiement. Dans le cas de paiement réussi, vous pouvez afficher un message de remerciement et commencer à expédier les marchandises.
À la dernière étape, un bouton «Continuer» est affiché sur la page de paiement chez Mercanet avec un lien de redirection vers votre site. Lorsque le client clique sur ce bouton, le serveur Mercanet le redirige vers l’adresse URL contenue dans le champ normalReturnUrl fourni dans la requête. La redirection est une requête HTTP(S) POST qui contient les données de la réponse, tels que décrits ci-dessus. Il est de votre responsabilité de récupérer ces paramètres et de vérifier la signature pour ainsi assurer l’intégrité des données de la réponse. De plus, vous êtes responsable d’afficher les messages pertinents (relatifs aux détails de la réponse) à votre client.
Ce champ normalReturnUrl est également utilisé pour tous les résultats de paiement (annulation, refus ...) afin de rediriger vers votre site.
Il est important de noter qu’il est impossible de garantir la réception de la réponse, celle-ci étant envoyée par le navigateur Web du client. Tout d’abord, le client a la possibilité de ne pas cliquer sur le lien. Ensuite, la connexion qu’il utilise peut tout simplement avoir un problème et bloquer l’envoi de cette réponse. Par conséquent, celle-ci ne peut pas constituer la base unique pour vos processus métier. Remarque

La version actuelle d’InterfaceVersion est HP_2.21. Veuillez consulter le dictionnaire de données Mercanet pour une description complète des paramètres inclus dans la réponse.

Renseigner l’URL de la réponse automatique

La réponse automatique est envoyée seulement si le champ automaticResponseUrl a été envoyé dans la requête de paiement. Si tel est le cas, le serveur Mercanet envoie une réponse HTTP(S) POST à l’adresse URL reçue. Les champs de la réponse automatique sont identiques à ceux de la réponse manuelle. La seule différence entre les deux procédures est que la réponse automatique est envoyée directement par le serveur Mercanet sans passer par le navigateur Web du client. Par conséquent, elle est bien plus fiable car elle est toujours envoyée. Le serveur Mercanet n’attend aucune réponse après l’envoi de la réponse automatique. Il vous appartient de récupérer les différentes données de la réponse, vérifier la signature pour vous assurer de l’intégrité des champs de la réponse et, par conséquent, mettre à jour votre back office.
Remarque

La version actuelle d’InterfaceVersion est HP_2.21. Veuillez consulter le dictionnaire de données Mercanet pour une description complète des paramètres inclus dans la réponse.

Remarque : attention !

La réponse automatique est systématique, asynchrone et renvoyée par le réseau : elle est par définition dépendante des problèmes techniques potentiels des différents éléments de ce réseau et peut donc parfois être reçue avec un retard plus ou moins conséquent, voire même ne jamais être reçue. Si une réponse automatique n’est pas reçue, vous pouvez obtenir le résultat d’un paiement en appelant la méthode getTransactionData de l’interface Office Server, ou en analysant le contenu du journal des transactions.

Résoudre les problèmes de réception des réponses

Ci-dessous, vous trouverez une liste des problèmes les plus couramment observés qui bloquent la réception des réponses automatiques et manuelles. Assurez-vous de les avoir vérifiés avant d’appeler le service d’assistance technique.

  • Vérifiez si les adresses URL de réponse sont fournies dans la requête de paiement et si elles sont valides. Pour le faire, vous pouvez tout simplement les copier et coller dans votre navigateur.
  • Les adresses URL fournies doivent être accessibles depuis l’extérieur, c’est-à-dire de l’Internet. Le contrôle d’accès (identifiant/mot de passe ou filtre IP) ou le pare-feu peuvent bloquer l’accès à votre serveur.
  • L’accès aux adresses URL de réponse doit être confirmé dans le journal des notifications de votre serveur Web.
  • Si vous utilisez un port non standard, il doit être compris entre 80 et 9999 pour assurer la compatibilité avec Mercanet.
  • Il est impossible d’ajouter des paramètres de contexte aux adresses URL de réponse. Certains champs peuvent être néanmoins utilisés, par exemple, les champs orderID ou returnContext sont prévus pour les paramètres supplémentaires. Éventuellement, vous pouvez vous servir du champ sessionId pour retrouver les renseignements sur votre client à la fin du processus de paiement.

Dans certains cas d’erreurs, le serveur Mercanet n’est pas capable de signer le message de réponse. Cela s’applique, par exemple, à l’erreur «MerchantID inconnu» et au cas où la clé secrète est inconnue de Mercanet. Pour ces raisons, le serveur de paiement envoie une réponse sans signature dans le champ Seal.

Récupérer les champs des réponses

Le contenu des réponses Web automatiques et manuelles de Mercanet Paypage est identique. Le contenu lui-même peut varier selon le résultat du paiement (réussi ou autre).

Champ

version

Commentaires

acceptanceSystemApplicationId*

HP_2.18

acquirerNativeResponseCode*

HP_2.12

acquirerResponseCode*

HP_2.0

acquirerResponseIdentifier*

HP_2.8

acquirerResponseMessage*

HP_2.8

additionalAuthorisationNumber*

HP_2.8

amount

HP_1.0

idem requête

authorisationId*

HP_1.0

authorisationTypeLabel*

HP_2.18

authorMessageReference*

HP_2.18

avsAddressResponseCode*

HP_2.17

avsPostcodeResponseCode*

HP_2.17

captureDay

HP_1.0

Champ de la requête qui peut-être surchargé par Mercanet

captureLimiteDate*

HP_2.3

captureMode

HP_1.0

Champ de la requête qui peut-être surchargé par Mercanet.

cardCSCResultCode*

HP_2.0

cardProductCode*

HP_2.12

cardProductName*

HP_2.12

cardProductProfile*

HP_2.12

cardProductUsageLabel*

HP_2.18

complementaryCode**

HP_1.0

complementaryInfo*

HP_2.0

creditorId*

HP_2.7

currencyCode

HP_1.0

idem requête

customerBusinessName

HP_2.17

customerCompanyName

HP_2.17

customerEmail

HP_2.0

idem requête

customerId

HP_2.0

idem requête

customerIpAddress

HP_2.0

idem requête ou recalculé par Mercanet Paypage si absent

customerLegalId

HP_2.17

customerMobilePhone

HP_2.1

idem requête

customerPositionOccupied

HP_2.17

dccAmount*

HP_2.3

dccCurrencyCode*

HP_2.3

dccExchangeRate*

HP_2.3

dccExchangeRateValidity*

HP_2.3

dccProvider*

HP_2.3

dccStatus*

HP_2.3

dccResponseCode*

HP_2.3

dueDate

HP_2.3

guarantheeIndicator*

HP_2.0

hashPan1*

HP_2.0

hashPan2*

HP_2.0

holderAuthentMethod**

HP_2.4

holderAuthentProgram*

HP_2.5

holderAuthentRelegation*

HP_2.0

holderAuthentStatus*

HP_2.0

holderContactEmail*

HP_2.20

instalmentAmountsList*

HP_2.6

instalmentDatesList*

HP_2.6

instalmentNumber*

HP_2.6

instalmentTransactionReferencesList*

HP_2.6

interfaceVersion*

HP_1.0

invoiceReference

HP_2.10

issuerCode*

HP_2.12

issuerCountryCode*

HP_2.12

issuerEnrollementIndicator*

HP_2.0

issuerWalletInformation

HP_2.9

keyVersion*

HP_1.0

idem requête

mandateAuthentMethod*

HP_2.2

mandateCertificationType*

HP_2.7

mandateId*

HP_2.3

mandateUsage*

HP_2.2

maskedPan**

HP_1.0

merchantId

HP_1.0

idem requête

merchantSessionId

HP_2.0

idem requête

merchantTransactionDateTime

HP_2.0

idem requête

merchantWalletId

HP_2.0

idem requête

orderChannel

HP_2.0

idem requête.

orderId

HP_1.0

idem requête

panEntryMode*

HP_2.4

panExpiryDate*

HP_2.0

paymentAttemptNumber

HP_2.18

paymentMeanBrand*

HP_1.0

paymentMeanBrandSelectionStatus*

HP_2.14

paymentMeanData*

HP_2.2

paymentMeanId*

HP_2.6

paymentMeanTradingName*

HP_2.8

paymentMeanType*

HP_1.0

paymentPattern*

HP_2.0

idem requête

preAuthenticationColor

HP_2.10

preAuthenticationInfo

HP_2.10

preAuthenticationProfile

HP_2.10

preAuthenticationProfileValue*

HP_2.14

preAuthenticationRuleResultList*

HP_2.14

Une liste d’objet preAuthenticationRuleResult.
Voir ci-dessous pour son contenu et son format

preAuthenticationThreshold

HP_2.10

preAuthenticationValue

HP_2.10

preAuthorisationProfile*

HP_2.14

preAuthorisationProfileValue*

HP_2.14

preAuthorisationRuleResultList*

HP_2.14

Une liste d’objet preAuthorisationRuleResult.
Voir ci-dessous pour son contenu et son format

responseCode

HP_1.0

returnContext

HP_1.0

idem requête

s10TransactionId

HP_2.9

s10TransactionIdDate

HP_2.9

s10transactionIdsList*

HP_2.11

scoreColor*

HP_2.0

scoreInfo*

HP_2.0

scoreProfile*

HP_2.0

scoreThreshold*

HP_2.0

scoreValue*

HP_2.0

settlementMode

HP_2.7

settlementModeComplement

HP_2.13

statementReference*

HP_2.4

tokenPan*

HP_2.0

transactionActors*

HP_2.2

idem requête

transactionDateTime*

HP_1.0

transactionOrigin*

HP_2.0

idem requête

transactionPlatform

HP_2.16

Usage futur (systématiquement valorisé à ‘PROD’ pour le moment)

transactionReference

HP_1.0

walletType*

HP_2.4

  • champs renseignés s’ils sont disponibles, en fonction de l’état de la transaction et du moyen de paiement choisi.
Champs optionnels relatifs aux contrôles de fraude
  • Contenu de preAuthenticationRuleResult

Champ

version

Commentaires

ruleCode

HP_2.14

ruleType

HP_2.14

ruleWeight

HP_2.14

ruleSetting

HP_2.14

ruleResultIndicator

HP_2.14

ruleDetailedInfo

HP_2.14

  • Contenu de preAuthorisationRuleResult

Champ

Version

Commentaires

ruleCode

HP_2.14

ruleType

HP_2.14

ruleWeight

HP_2.14

ruleSetting

HP_2.14

ruleResultIndicator

HP_2.14

ruleDetailedInfo

HP_2.14

Syntaxe des Listes d’objets complexes dans les réponses

Le format d'une liste d'objets complexes dans les réponses automatiques et manuelles est défini comme suit: (surligné en jaune)

..|amount=1000|currencyCode=978|objectNameList=[{"field1":"value1a", "field2":"value2a","field3":"value3a"…},{"field1":"value1b", "field2":"value2b","field3":"value3b"}…]|transactionReference=1452687287828|..

Le contenu de la liste est enveloppé dans une paire de crochets [ ].

Chaque entrée de la liste est enveloppé dans une paire d'accolades { }.

Chaque champ est représenté comme "nomChamp" = "valeurChamp".

Notez que le nom et la valeur du champ sont tous deux enveloppés dans une paire de doubles guillemets "".

Les paires de nom/valeur adjacents sont séparés par une virgule.

Exemple du champ preAuthorisationRuleResultList Détail des règles fraude executées en préautorisation (surligné en jaune)

..|amount=1000|currencyCode=978|preAuthorisationRuleResultList=[
{”ruleCode”:"SC",”ruleType”:"NG",”ruleWeight”:"I",”ruleSetting”:"S",”ruleResultIndicator”:"0",“ruleDetailedInfo”:"TRANS=1:5;CUMUL=1000:99999900"},
{”ruleCode”:"GC",”ruleType”:"NG",”ruleWeight”:"D",”ruleSetting”:"N",”ruleResultIndicator”:"0",“ruleDetailedInfo”:""},
{”ruleCode”:"CR",”ruleType”:"NG",”ruleWeight”:"D",”ruleSetting”:"S",”ruleResultIndicator”:"N",“ruleDetailedInfo”:"CARD_COUNTRY=USA"}]
|transactionReference=1452687287828|..

Analyser la réponse de paiement

Etat

Champs de la réponse

Action à réaliser

Paiement accepté

responseCode = 00 acquirerResponseCode = 00 garanteeIndicator = Y,N,U, vide

Vous pouvez livrer la commande en fonction du niveau de garantie que vous souhaitez (champ garanteeIndicator)

Refus Fraude Mercanet GONOGO

responseCode = 05 complementaryCode = XX preAuthorisationRuleResultList

Le paiement a été refusé par le moteur de fraude Mercanet que vous avez configuré. Ne livrez pas la marchandise. Analysez le détail des règles fraudes exécutées par Mercanet pour connaitre la cause du refus (champ preAuthorisationRuleResultList).

Refus Fraude Mercanet GONOGO

responseCode = 05 complementaryCode = XX preAuthorisationRuleResultList

Le paiement a été refusé par le moteur de fraude Mercanet que vous avez configuré. Ne livrez pas la marchandise. Analysez le détail des règles fraudes exécutées par Mercanet pour connaitre la cause du refus (champ preAuthorisationRuleResultList).

Refus Fraude Mercanet BUSINESS SCORE

responseCode = 05 scoreColor = RED, BLACK
scoreValue = X (score de la transaction) scoreThreshold = X,Y (seuil orange, seuil vert)

Le paiement a été refusé par le moteur de fraude Mercanet que vous avez configuré Ne livrez pas la marchandise. Analysez le détail des règles fraudes exécutées par Mercanet pour connaitre la cause du refus (champ preAuthorisationRuleResultList).

Warning Fraude Mercanet BUSINESS SCORE

responseCode = 05 scoreColor = ORANGE scoreValue = X (score de la transaction) scoreThreshold = X,Y (seuil orange, seuil vert)

Le paiement a été autorisé par l’acquéreur mais le moteur de fraude Mercanet émet un warning par rapport aux règles que vous avez configurées. Analysez le détail des règles fraudes exécutées par Mercanet pour connaitre la cause du warning (champ preAuthorisationRuleResultList). Si transaction non risquée alors acceptez la avec la fonction acceptChallenge. Si transaction risquée alors refusez la avec la fonction refuseChallenge. Les fonctions acceptChallenge et refuseChallenge sont disponibles sur l’extranet et les connecteurs office.

Refus 3D Secure

reponseCode = 05 holderAuthenStatus = FAILURE

L’authentification de l’acheteur a échoué, ce n’est pas nécessairement un cas de fraude. Vous pouvez proposer à votre client de payer avec autre moyen de paiement en générant une nouvelle requête

Refus bancaire acquéreur

responseCode = 05 acquirerResponseCode = XX

L’autorisation est refusée pour un motif non lié à la fraude. Vous pouvez proposer à votre client de payer avec autre moyen de paiement en générant une nouvelle requête.

Refus fraude acquéreur

responseCode = 34 acquirerResponseCode = XX

Autorisation refusée pour cause de fraude. Ne livrez pas la commande.

Refus nombre max essais atteint

responseCode = 75 acquirerResponseCode = XX

L’acheteur a fait plusieurs tentatives toutes échouées car les informations saisies n’étaient pas correctes. Deux possibilités: Difficulté pour votre client pour renseigner les informations cartes Tentative de carding (recherche de numéros de cartes possibles) Prenez contact avec votre client pour définir la suite à donner.

Refus suite problème technique

responseCode = 90, 99 acquirerResponseCode = 90 à 98

Problème technique temporaire lors du traitement de la transaction. Proposez à votre client de refaire un paiement ultérieurement.

Etape 3: Tester sur l’environnement de test

Une fois le développement de la connexion à Mercanet Paypage réalisé, vous pouvez effectuer un test sur le serveur Mercanet Paypage de test.

Pour effectuer ce test, il faut utiliser les identifiants en fonction du mode d’identification des transactions que vous souhaitez :

URL de test du serveur https://payment-webinit-mercanet.test.sips-atos.com/paymentInit

[Les informations sur la boutique de test à utiliser est décrite ici].

Ce serveur de test n’est pas raccordé aux serveurs bancaires réels car sa fonction est de valider la connexion entre votre site Web et le serveur de paiement.
Mercanet Paypage simule donc l’appel aux serveurs d’autorisation pour vous permettre de tester les différents résultats d’un paiement.
Les tests s'effectuent avec des cartes de tests (cf paragraphe suivant).

Remarque

Puisque l’identifiant Marchand est partagé entre tous les commerçants/prospects, il existe un risque de doublon de transactionReference. Par conséquent, il est vivement recommandé que tous les transactionReference soient préfixés par le nom de la future boutique qui sera utilisée dans l’environnement de production. Cela facilite aussi le support en cas d’appel à l’assistance technique.

Vous utilisez une boutique générique sans personnalisation de la page de paiement.
C’est lors de l’étape 4 que vous pouvez personnaliser vos pages de paiements.

Tester des transactions

[Pour tester des transactions sur la boutique de test, vous devez utiliser des cartes de tests fournies ici]

Etape 4: Valider le passage en production

Une fois la connexion de votre site web à Mercanet paypage testée, vous êtes à présent en mesure de valider la connexion à Mercanet Paypage de production.

Si vous souhaitez personnaliser vos pages de paiement, vous pouvez utiliser notre outil CustomPages, permettant de tester et visualiser le rendu sur les pages de paiement. Pour cela, merci de vous référer à la documentation CustomPages afin d’utiliser l’outil.

Au préalable, nous conseillons d’isoler votre site web du public pour éviter que des clients effectuent des transactions pendant cette phase de validation.

Pour basculer sur le serveur de production, vous devez changer l’URL pour vous connecter au serveur Mercanet de production en utilisant les identifiants reçus lors l’inscription merchantId, secretKey et keyVersion).

Information Valeur
URL Mercanet https://payment-webinit.mercanet.bnpparibas.net/paymentInit
merchantId Identifiant de la boutique reçu par mail
SecretKey Clé secrète que vous récupérez via l’extranet Mercanet Download
KeyVersion Version clé secrète récupérée sur Mercanet Download (logiquement 1 pour la 1ère clé)

Remarque

Une erreur fréquente est d’oublier un de ces 4 paramètres ce qui conduit systématiquement à une erreur.

Comment valider le bon fonctionnement en production

Immédiatement

  • Faîtes une transaction avec une carte de paiement réelle (si possible la vôtre)

Si la transaction est acceptée, elle sera envoyée en banque pour créditer votre compte commerçant et débiter le compte carte.

  • Vérifier que vos pages de paiement intègrent vos paramètres de personnalisation
  • Consultez la transaction via Mercanet Office Extranet à partir du transactionReference

Le lendemain

  • Vérifiez la présence de la transaction dans le journal des transactions
  • Vérifiez sur votre compte que l’opération a bien été créditée
  • Remboursez la transaction via Mercanet Office Extranet (optionnel)

Le surlendemain

  • Vérifiez que l’opération de remboursement apparait dans le journal des opérations
  • Vérifiez sur votre compte commerçant le débit suite au remboursement

Etape 5: Démarrer en production

Une fois la validation du passage en production effectuée, ouvrez votre site au public pour permettre à vos clients d’acheter et de payer.

Dans la journée

  • Surveillez le taux d’acceptation (nombre de responseCode 00/nombre total de transactions).
  • Vérifiez la nature des refus non bancaires
    • Problème technique: responseCode 90, 97, 99
    • Fraude: responseCode 34
    • Nombre max de tentatives de paiement atteint: responseCode 75

Le lendemain

  • Vérifiez dans le journal des transactions la présence de toutes les transactions traitées (acceptées et refusées)
  • Vérifiez dans le journal des opérations les opérations que vous avez effectuées ainsi que les remises (option du journal)