Préambule

Les fonctionnalités et moyens de paiement décrits dans le présent guide correspondent à la solution WL Sips proposée par Worldline, sur laquelle l’offre Sogenactif repose techniquement. Elles ne sont pas toutes disponibles sur l’offre Sogenactif ; pour connaître l’exhaustivité des fonctionnalités et moyens de paiement disponibles sur cette offre, veuillez-vous référer au guide « Configuration des fonctionnalités ».

Introduction

Sogenactif 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 échelonné , …).

L’objectif du présent document est d’expliquer la mise en œuvre de la solution Sogenactif Paypage POST jusqu’au démarrage en production.

A qui s’adresse ce document

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

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

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

  • Présentation fonctionnelle ;
  • Configuration des fonctionnalités.

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 à Sogenactif Paypage POST .

Note: toutes les portions de code de ce document sont fournies à titre d’exemple, il convient de les adapter à votre site Web afin qu’elles soient pleinement exploitables.

Gestion de la clé secrète

Lors de votre inscription, Société Générale met à disposition sur Sogenactif Téléchargement (voir l'annexe "Télécharger la clé secrète"), une clé secrète qui permet de sécuriser les échanges entre votre site et le serveur Sogenactif .

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

IMPORTANT: 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 Sogenactif Téléchargement (voir l'annexe « Révocation et demande de renouvellement de la clé secrète » du guide de démarrage rapide Paypage POST ).

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

IMPORTANT: une clé secrète est associée à une version. Après avoir obtenu une nouvelle clé secrète, vous devez impérativement modifier votre requête et indiquer la nouvelle version dans le champ keyVersion , sans quoi vous obtiendrez un code réponse 34 (suspicion de fraude).

Contacter l'assistance

Pour toute question technique ou demande d'assistance, nos services sont disponibles du lundi au vendredi, hors jours fériés, de 9 h à 19 h :

  • par téléphone au : +33 (0) 825 090 095 ;
  • par e-mail : supportsogenactif@worldline.com.

Pour faciliter le traitement de vos demandes, veuillez communiquer votre identifiant de commerçant : merchantId (numéro à 15 chiffres).

Comprendre le paiement avec Sogenactif Paypage POST

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

1. Lorsque le client procède au paiement, une requête de paiement doit être envoyée au connecteur Sogenactif Paypage POST . Société Générale 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. Sogenactif Paypage POST redirige l’application appelante vers les pages de paiement Sogenactif . Le client doit saisir les informations du moyen de paiement pour que le serveur de paiement Sogenactif 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 ou d’un mandat Sepa). À 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 sur 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 Sogenactif 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 Sogenactif .

Note: si vous n'avez pas l'option "Nouvelle tentative de paiement (voir partie "Nouvelle tentative de paiement dans le document "Configuration des fonctionnalités"), 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 Sogenactif 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 Sogenactif Paypage .

Démarrer avec Sogenactif Paypage POST en 5 étapes

Étape 1 : inscrire la boutique

Afin d’inscrire votre boutique, vous devez remplir le contrat Sogenactif envoyé par Société Générale et le retourner à ce dernier.

Lors de la saisie du formulaire, vous désignez un contact administratif (qui accèdera à Sogenactif Gestion ) et un contact technique (qui accèdera à Sogenactif Téléchargement ) afin que Société Générale puisse vous communiquer les informations nécessaires pour démarrer votre boutique.

Société Générale procède alors à l’enregistrement de la boutique et vous retourne par e-mail votre identifiant commerçant (merchantId) ainsi que vos identifiants et les modalités de connexion au Portail Sogenactif et à Sogenactif Téléchargement .

Pour la connexion au Portail Sogenactif , le contact renseigné dans le contrat Sogenactif – rubrique « Portail Sogenactif » recevra un e-mail contenant l’identifiant et un lien pour générer lui-même son mot de passe. Pour la connexion à Sogenactif Téléchargement , le contact renseigné dans le contrat Sogenactif – rubrique « Sogenactif Téléchargement » recevra son mot de passe par e-mail, l’identifiant sera envoyé par mail séparé au contact renseigné pour le Portail Sogenactif .

Note: 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.

Étape 2 : effectuer un paiement

La requête paiement est envoyée depuis une page de votre site web vers le serveur Sogenactif via un formulaire web avec 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 Sogenactif .
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.33 .

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 paiement de 55 euros :

      amount=5500|currencyCode=978|merchantId=011223744550001|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=011223744550001|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 moi@email.com 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=011223744550001|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.

Note: 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écuriser la requête

La requête contient les paramètres de la transaction et est envoyée par le navigateur Web du client. Il est théoriquement possible pour un pirate d’intercepter la demande et de la modifier avant l’envoi au 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. Sogenactif répond à ce besoin par un échange de signatures qui permet de vérifier :

  • l’intégrité des messages requête et réponse ;
  • l’authentification de l’émetteur et du destinataire car ils se partagent la même clé secrète ;
IMPORTANT: 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 à Sogenactif 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 partagent pas la même clé secrète.

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

Calcul de la donnée Seal

Algorithme HMAC-SHA

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

  • Contenu du champ Data envoyé dans le formulaire POST. Donnant la donnée data , mentionnée dans les exemples ci-dessous;
  • Codage UTF-8 des données constituant le résultat de l’opération précédente
  • HMAC avec chiffrement SHA256 des octets obtenus avec la clé secrète.

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

      HMAC-SHA256( UTF-8(Data), UTF-8(secretKey))
    
Note: par défaut, le sceau est calculé avec l'algorithme SHA-256, pour qu’un sceau soit calculé avec l'algorithme HMAC-SHA-256, les paramètres d'entrée de la requête doivent contenir le champ sealAlgorithm avec la valeur suivante : “HMAC-SHA-256”.
Exemples de code Hmac Sha256
  • Exemple d’encodage Hmac Sha256 en Php 5
            <?php
    
    …
    
    // Seal computation thanks to hash sorted data hash with merchant key
    
    $data_to_send= utf8_encode($data)
    
    $seal=hash_hmac('sha256', $data_to_send, $secretKey);
    
    …
    …
    
    ?> 
          

    data_to_send et secretKey doivent utiliser un jeu de caractères UTF-8. Référez-vous à la fonction utf8_encode pour la conversion de caractères ISO-8859-1 en UTF-8.

  • 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.getBytes(), "HmacSHA256");
      hmacSHA256.init(keySpec);
    
      return encodeHexString(hmacSHA256.doFinal(data.getBytes()));
    }
    
    /**
     * @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

    (Exemple effectué à l’aide d’un simple formulaire nommé « Form1 » contenant deux champs texte pour saisir data et txtSecretKey , ainsi qu’un autre champ pour 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 = data.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();
            }
    
        }
    }
          
Validation du calcul de seal

Une fois votre calcul de seal mis en place, voici un exemple de requête vous permettant de vérifier que vous retrouvez bien le bon seal :

      automaticResponseURL=https://automatic-response-url.fr/|normalReturnURL=https://normal-return-url/|captureDay=0|captureMode=AUTHOR_CAPTURE|merchantId=011223344550000|amount=2500|orderId=ORD101|currencyCode=978|transactionReference=TREFEXA2012|keyVersion=1|transactionOrigin=SO_WEBAPPLI|returnContext=ReturnContext|orderChannel=INTERNET|customerContact.email=customer@email.com

    

Pour la requête ci-dessus, avec un algorithme de hachage HMAC-SHA-256 et une clé secrète valant :

      secret123
    

Le seal attendu est :

      ac2332b57a674aba5b28a03dae677fa2f4c1ae8a349ebbdd6772a098c7f29861
    
Algorithme SHA-256

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

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

Exemple complété à l’aide d’un simple formulaire appelé « Form 1 » contenant deux champs de texte à renseigner : data, 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 = data.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();
        }

    }
}
    

Exemple de requête de paiement

Ci-dessous, voici un exemple du formulaire avec données Data non encodée :

      <form method="post" action="https://url.vers.serveur.sips/paymentInit">
    <input type="hidden" name="Data" value="amount=5500|currencyCode=978|merchantId=011223744550001|normalReturnUrl=http://www.normalreturnurl.com|transactionReference=534654|keyVersion=1">
    <input type="hidden" name="InterfaceVersion" value="HP_2.20">
    <input type="hidden" name="Seal" value="21a57f2fe765e1ae4a8bf15d73fc1bf2a533f547f2343d12a499d9c0592044d4">
    <input type="submit" value="Payer">   
  </form>
    

Traiter les erreurs lors de l’initialisation du paiement

Tous les champs reçus par Sogenactif 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.

Note: 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.33 ).

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 Sogenactif Téléchargement .

Invalid signature

La vérification du Seal de la requête de paiement a échoué. Cela peut être dû à un calcul incorrect de la donnée Seal ou à 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 Sogenactif 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 Sogenactif . Vérifier si la 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.

Renseigner les champs de la requête

Note: Les fonctionnalités et moyens de paiement décrits dans le présent guide correspondent à la solution Sips proposée par Worldline, sur laquelle l’offre Sogenactif repose techniquement. Elles ne sont pas toutes disponibles sur l’offre Sogenactif ; pour connaître l’exhaustivité des fonctionnalités et moyens de paiement disponibles sur cette offre, veuillez-vous référer au guide « Configuration des fonctionnalités ».

Champs génériques

Champ Présence A partir de la version Commentaires
amount Obligatoire HP_ 2.0
automaticResponseUrl Facultatif HP_ 2.0
captureDay Facultatif HP_ 2.0
captureMode Facultatif HP_ 2.0
currencyCode Obligatoire HP_ 2.0
customerEmail Facultatif HP_ 2.0
customerId Facultatif HP_ 2.0
customerLanguage Facultatif HP_ 2.0
fraudData Facultatif HP_ 2.0 Voir la partie Containers
hashSalt1 Facultatif HP_ 2.0
hashSalt2 Facultatif HP_ 2.0
hashAlgorithm1 Facultatif HP_ 2.0
hashAlgorithm2 Facultatif HP_ 2.0
interfaceVersion Obligatoire HP_ 2.0
merchantId Obligatoire HP_ 2.0
merchantSessionId Facultatif HP_ 2.0
merchantTransactionDateTime Facultatif HP_ 2.0
merchantWalletId Facultatif HP_ 2.0
normalReturnUrl Obligatoire HP_ 2.0
orderChannel Obligatoire HP_ 2.0
orderId Facultatif HP_ 2.0
paymentMeanBrandList Facultatif HP_ 2.0
paymentMeanData Facultatif HP_ 2.0 Voir la partie Containers
responseKeyVersion Facultatif HP_ 2.0
returnContext Facultatif HP_ 2.0
templateName Facultatif HP_ 2.0
transactionActors Facultatif HP_ 2.0
transactionReference Conditionnel HP_ 2.0 Obligatoire si vous n'utilisez pas le s10TransactionReference ou que Sogenactif ne le calcule pas pour pour vous, dépend de votre configuration commerçant
transactionOrigin Facultatif HP_ 2.0
invoiceReference Facultatif HP_ 2.0
bypassReceiptPage Facultatif HP_ 2.0
customerIpAddress Facultatif HP_ 2.0
customerTimestampIpAddress Facultatif HP_ 2.26
bypassDcc Facultatif HP_ 2.0
instalmentData Facultatif HP_ 2.0 Voir la partie Containers
billingAddress Facultatif HP_ 2.0 Voir la partie Containers
billingContact Facultatif HP_ 2.0 Voir la partie Containers
customerAddress Facultatif HP_ 2.0 Voir la partie Containers
customerContact Facultatif HP_ 2.0 Voir la partie Containers
deliveryAddress Facultatif HP_ 2.0 Voir la partie Containers
deliveryContact Facultatif HP_ 2.0 Voir la partie Containers
holderAddress Facultatif HP_ 2.0 Voir la partie Containers
holderContact Facultatif HP_ 2.0 Voir la partie Containers
customerData Facultatif HP_ 2.0 Voir la partie Containers
paymentPattern Conditionnel HP_ 2.0
statementReference Facultatif HP_ 2.0
authenticationData Facultatif HP_ 2.0 Voir la partie Containers
mandateId Facultatif HP_ 2.0
billingFirstDate Facultatif HP_ 2.0
customer3DSTransactionDate Facultatif HP_ 2.0
customerBillingNb Facultatif HP_ 2.0
customerDeliverySuccessFlag Facultatif HP_ 2.0
customerPhoneValidationMethod Facultatif HP_ 2.0
customerRegistrationDateOnline Facultatif HP_ 2.0
customerRegistrationDateProxi Facultatif HP_ 2.0
deliveryFirstDate Facultatif HP_ 2.0
evidenceAcquisitionDate Facultatif HP_ 2.0
evidenceNumber Facultatif HP_ 2.0
evidenceType Facultatif HP_ 2.0
valueDate Facultatif HP_ 2.0
deliveryData Facultatif HP_ 2.6 Voir la partie Containers
shoppingCartDetail Facultatif HP_ 2.6 Voir la partie Containers
holderData Facultatif HP_ 2.6 Voir la partie Containers
s10TransactionReference Conditionnel HP_ 2.7 Obligatoire si vous n'utilisez pas le transactionReference ou que Sogenactif ne le calcule pas pour pour vous, dépend de votre configuration commerçant. Voir la partie Containers
holderAdditionalReference Facultatif HP_ 2.9
riskManagementCustomDataList Facultatif HP_ 2.9 Liste de conteneur riskManagementCustomData . Voir la partie Containers
intermediateServiceProviderId Facultatif HP_ 2.10
seal Obligatoire HP_ 2.0
keyVersion Obligatoire HP_ 2.0
sealAlgorithm Facultatif HP_ 2.10
paypageData Facultatif HP_ 2.11 Voir la partie Containers
subMerchantId Facultatif HP_ 2.15
subMerchantShortName Facultatif HP_ 2.15
subMerchantCategoryCode Facultatif HP_ 2.15
subMerchantLegalId Facultatif HP_ 2.15
subMerchantAddress Facultatif HP_ 2.15 Voir la partie Containers
orderContext Facultatif HP_ 2.16 Voir la partie Containers
travelContext Facultatif HP_ 2.16 Voir la partie Containers
responseEncoding Facultatif HP_ 2.19
subMerchantName Facultatif HP_ 2.20
subMerchantContractNumber Facultatif HP_ 2.20
customerAccountHistoric Facultatif HP_ 2.21 Voir la partie Containers
merchantName Facultatif HP_ 2.23 Permet de modifier le nom affiché sur la page d'authentification 3-D Secure
merchantUrl Facultatif HP_ 2.29 Permet de modifier l'url du site marchand affiché sur la page d'authentification 3-D Secure

Champs optionnels relatifs à l'authentification du porteur

Contenu de authenticationData

Champ A partir de la version Commentaires
cardAuthPolicy HP_ 2.0 Voir la partie Containers
issuerWalletAuthPolicy HP_ 2.0 Voir la partie Containers

Contenu de cardAuthPolicy

Champ A partir de la version Commentaires
checkAVS HP_ 2.0
ignoreCSCCheckResult HP_ 2.0
ignorePostcodeCheckResult HP_ 2.0
ignoreAddressCheckResult HP_ 2.0

Contenu de issuerWalletAuthPolicy

Champ A partir de la version Commentaires
check3DS HP_ 2.0
checkCSC HP_ 2.0

Champs optionnels relatifs à l'adresse de facturation du client

Contenu de billingAddress

Champ A partir de la version Commentaires
addressAdditional1 HP_ 2.0
addressAdditional2 HP_ 2.0
addressAdditional3 HP_ 2.0
city HP_ 2.0
company HP_ 2.0
country HP_ 2.0
postBox HP_ 2.0
state HP_ 2.0
street HP_ 2.0
streetNumber HP_ 2.0
zipCode HP_ 2.0
businessName HP_ 2.17

Contenu de billingContact

Champ A partir de la version Commentaires
email HP_ 2.0
firstname HP_ 2.0
gender HP_ 2.0
lastname HP_ 2.0
mobile HP_ 2.0
phone HP_ 2.0
title HP_ 2.0
initials HP_ 2.11
legalId HP_ 2.17
positionOccupied HP_ 2.17
workPhone HP_ 2.21

Contenu de customerAccountHistoric

Champ A partir de la version Commentaires
creationDate HP_ 2.21
numberOfAttemptsAddCard24Hours HP_ 2.21
numberOfPurchase HP_ 2.26
numberOfPurchase180Days HP_ 2.21
numberOfTransaction24Hours HP_ 2.21
suspiciousActivityIndicator HP_ 2.21
firstPurchaseDate HP_ 2.24
lastPurchaseDate HP_ 2.24
changeDate HP_ 2.27
passwordChangeDate HP_ 2.27
numberOfTransactionYear HP_ 2.27
addPaymentMeanDate HP_ 2.27
customerAccountId HP_ 2.27

Champs optionnels relatifs à l'adresse du client

Contenu de customerAddress

Champ A partir de la version Commentaires
addressAdditional1 HP_ 2.0
addressAdditional2 HP_ 2.0
addressAdditional3 HP_ 2.0
city HP_ 2.0
company HP_ 2.0
country HP_ 2.0
postBox HP_ 2.0
state HP_ 2.0
street HP_ 2.0
streetNumber HP_ 2.0
zipCode HP_ 2.0
businessName HP_ 2.17

Contenu de customerContact

Champ A partir de la version Commentaires
email HP_ 2.0
firstname HP_ 2.0
gender HP_ 2.0
lastname HP_ 2.0
mobile HP_ 2.0
phone HP_ 2.0
title HP_ 2.0
initials HP_ 2.11
legalId HP_ 2.17
positionOccupied HP_ 2.17
workPhone HP_ 2.21

Contenu de customerData

Champ A partir de la version Commentaires
birthCity HP_ 2.0
birthCountry HP_ 2.0
birthDate HP_ 2.0
birthZipCode HP_ 2.0
nationalityCountry HP_ 2.0
newPassword HP_ 2.0
password HP_ 2.0
maidenName HP_ 2.18

Champs optionnels relatifs à l'adresse de livraison du client

Contenu de deliveryAddress

Champ A partir de la version Commentaires
addressAdditional1 HP_ 2.0
addressAdditional2 HP_ 2.0
addressAdditional3 HP_ 2.0
city HP_ 2.0
company HP_ 2.0
country HP_ 2.0
postBox HP_ 2.0
state HP_ 2.0
street HP_ 2.0
streetNumber HP_ 2.0
zipCode HP_ 2.0
businessName HP_ 2.17

Contenu de deliveryContact

Champ A partir de la version Commentaires
email HP_ 2.0
firstname HP_ 2.0
gender HP_ 2.0
lastname HP_ 2.0
mobile HP_ 2.0
phone HP_ 2.0
title HP_ 2.0
initials HP_ 2.11
legalId HP_ 2.17
positionOccupied HP_ 2.17
workPhone HP_ 2.21

Contenu de deliveryData

Champ A partir de la version Commentaires
deliveryChargeAmount HP_ 2.6
estimatedDeliveryDate HP_ 2.6
deliveryMode HP_ 2.6
deliveryMethod HP_ 2.6
deliveryOperator HP_ 2.6
estimatedDeliveryDelay HP_ 2.6
deliveryAddressCreationDate HP_ 2.21
electronicDeliveryIndicator HP_ 2.21
deliveryAddressStatus HP_ 2.26

Champs optionnels relatifs à la fraude

Contenu de fraudData

Champ A partir de la version Commentaires
bypassCtrlList HP_ 2.0
bypassInfoList HP_ 2.0
bypass3DS HP_ 2.0
allowedCardCountryList HP_ 2.0
deniedCardCountryList HP_ 2.0
allowedIpCountryList HP_ 2.0
deniedIpCountryList HP_ 2.0
allowedCardArea HP_ 2.0
deniedCardArea HP_ 2.0
allowedIpArea HP_ 2.0
deniedIpArea HP_ 2.0
riskManagementDynamicSettingList HP_ 2.0 Liste de conteneur riskManagementDynamicSetting . Voir la partie Containers
challengeMode3DS HP_ 2.21
addressDeliveryBillingMatchIndicator HP_ 2.21
nameDeliveryCustomerMatchIndicator HP_ 2.21
reorderProductIndicator HP_ 2.21
productAvailabilityIndicator HP_ 2.21
merchantCustomerAuthentMethod HP_ 2.23
merchantCustomerAuthentDateTime HP_ 2.27
merchantCustomerAuthentData HP_ 2.27
productAvailabilityDate HP_ 2.27

Contenu de riskManagementDynamicSetting

Champ A partir de la version Commentaires
riskManagementDynamicParam HP_ 2.0
riskManagementDynamicValue HP_ 2.0

Champs optionnels relatifs aux données du titulaire de la carte

Contenu de holderAddress

Champ A partir de la version Commentaires
addressAdditional1 HP_ 2.0
addressAdditional2 HP_ 2.0
addressAdditional3 HP_ 2.0
city HP_ 2.0
company HP_ 2.0
country HP_ 2.0
postBox HP_ 2.0
state HP_ 2.0
street HP_ 2.0
streetNumber HP_ 2.0
zipCode HP_ 2.0
businessName HP_ 2.17

Contenu de holderContact

Champ A partir de la version Commentaires
email HP_ 2.0
firstname HP_ 2.0
gender HP_ 2.0
lastname HP_ 2.0
mobile HP_ 2.0
phone HP_ 2.0
title HP_ 2.0
initials HP_ 2.11
legalId HP_ 2.17
positionOccupied HP_ 2.17
workPhone HP_ 2.21

Contenu de holderData

Champ A partir de la version Commentaires
birthCity HP_ 2.6
birthCountry HP_ 2.6
birthDate HP_ 2.6
birthZipCode HP_ 2.6
nationalityCountry HP_ 2.6
newPassword HP_ 2.6
password HP_ 2.6
maidenName HP_ 2.18

Champs optionnels relatifs à AMEX-EA (Enhanced authorization)

Contenu de orderContext

Champ A partir de la version Commentaires
customerHostName HP_ 2.16
customerBrowserType HP_ 2.16
customerANI HP_ 2.16
customerANIInformationIdentifier HP_ 2.16

Contenu de travelContext

Champ A partir de la version Commentaires
departureDate HP_ 2.16
passengerName HP_ 2.16
originAirport HP_ 2.16
numberOfRoutingCities HP_ 2.16
routingCityList HP_ 2.16
numberOfAirlineCarriers HP_ 2.16
airlineCarrierList HP_ 2.16
fareBasis HP_ 2.16
numberOfPassengers HP_ 2.16
destinationAirport HP_ 2.16
reservationCode HP_ 2.16

Champs optionnels relatifs aux moyens de paiement

Contenu de paymentMeanData

Champ A partir de la version Commentaires
paypal HP_ 2.0 Voir la partie Containers
sdd HP_ 2.0 Voir la partie Containers
cofinoga3xcb HP_ 2.0 Voir la partie Containers
passbe HP_ 2.0 Voir la partie Containers
accord HP_ 2.0 Voir la partie Containers
facilypay HP_ 2.0 Voir la partie Containers
accordkdo HP_ 2.0 Voir la partie Containers
presto HP_ 2.0 Voir la partie Containers
cofidis3x HP_ 2.0 Voir la partie Containers
unEuroCom HP_ 2.0 Voir la partie Containers
cofidis4x HP_ 2.0 Voir la partie Containers
cofinoga HP_ 2.14 Voir la partie Containers
cetelem3x HP_ 2.15 Voir la partie Containers
cetelem4x HP_ 2.15 Voir la partie Containers
franfinance3xcb HP_ 2.18 Voir la partie Containers
franfinance4xcb HP_ 2.18 Voir la partie Containers
visaCheckout HP_ 2.21 Voir la partie Containers
bcacb3X HP_ 2.24 Voir la partie Containers
bcacb4X HP_ 2.24 Voir la partie Containers
oney34x HP_ 2.29 Voir la partie Containers

Contenu de paypal

Champ A partir de la version Commentaires
landingPage HP_ 2.0
addrOverride HP_ 2.0
invoiceId HP_ 2.0
dupFlag HP_ 2.0
dupDesc HP_ 2.0
dupCustom HP_ 2.0
dupType HP_ 2.0
mobile HP_ 2.0
orderDescription HP_ 2.16

Contenu de sdd

Champ A partir de la version Commentaires
mandateAuthentMethod HP_ 2.0
mandateUsage HP_ 2.0
mandateCertificationType HP_ 2.0

Contenu de cofinoga3xcb

Champ A partir de la version Commentaires
creditIndicator HP_ 2.0

Contenu de passbe

Champ A partir de la version Commentaires
settlementModeList HP_ 2.0

Contenu de accord

Champ A partir de la version Commentaires
settlementMode HP_ 2.0
additionalAuthorisationNumber HP_ 2.0

Contenu de facilypay

Champ A partir de la version Commentaires
settlementMode HP_ 2.0
settlementModeVersion HP_ 2.0
receiverType HP_ 2.0
depositRefundIndicator HP_ 2.0

Contenu de accordkdo

Champ A partir de la version Commentaires
additionalAuthorisationNumber HP_ 2.0
blockAmountModification HP_ 2.18

Contenu de presto

Champ A partir de la version Commentaires
paymentMeanCustomerId HP_ 2.0
financialProduct HP_ 2.0
prestoCardType HP_ 2.0

Contenu de cofidis3x

Champ A partir de la version Commentaires
preScoreValue HP_ 2.0
cofidisDisplayCancelButton HP_ 2.0
cofidisPrivateData HP_ 2.0
basket HP_ 2.20

Contenu de unEuroCom

Champ A partir de la version Commentaires
preScoreValue HP_ 2.0
cofidisPrivateData HP_ 2.0
basket HP_ 2.19

Contenu de cofidis4x

Champ A partir de la version Commentaires
preScoreValue HP_ 2.0
cofidisDisplayCancelButton HP_ 2.0
cofidisPrivateData HP_ 2.0

Contenu de cofinoga

Champ A partir de la version Commentaires
paymentMeanTradeOptionList HP_ 2.14 Liste de conteneur paymentMeanTradeOption . Voir la partie Containers

Contenu de paymentMeanTradeOption

Champ A partir de la version Commentaires
paymentMeanTradingName HP_ 2.14
settlementModeList HP_ 2.14

Contenu de cetelem3x

Champ A partir de la version Commentaires
cetelemPrivateMerchantData HP_ 2.15
cetelemPrivateData HP_ 2.15

Contenu de cetelem4x

Champ A partir de la version Commentaires
cetelemPrivateMerchantData HP_ 2.15
cetelemPrivateData HP_ 2.15

Contenu de franfinance3xcb

Champ A partir de la version Commentaires
authenticationKey HP_ 2.18
pageCustomizationCode HP_ 2.18
redirectionTimer HP_ 2.18
testEnvironment HP_ 2.18
birthPlaceCode HP_ 2.18
conversionCurrency HP_ 2.26
convertedAmount HP_ 2.26

Contenu de franfinance4xcb

Champ A partir de la version Commentaires
authenticationKey HP_ 2.18
pageCustomizationCode HP_ 2.18
redirectionTimer HP_ 2.18
testEnvironment HP_ 2.18
birthPlaceCode HP_ 2.18
conversionCurrency HP_ 2.26
convertedAmount HP_ 2.26

Contenu de visaCheckout

Champ A partir de la version Commentaires
visaCheckoutCallID HP_ 2.21

Contenu de bcacb3X

Champ A partir de la version Commentaires
agencyCode HP_ 2.24
challengeMode3DS HP_ 2.24
numberOfCapturedTransaction HP_ 2.24
numberOfRejectedTransaction HP_ 2.24

Contenu de bcacb4X

Champ A partir de la version Commentaires
agencyCode HP_ 2.24
challengeMode3DS HP_ 2.24
numberOfCapturedTransaction HP_ 2.24
numberOfRejectedTransaction HP_ 2.24

Contenu de oney34x

Champ A partir de la version Commentaires
settlementMode HP_ 2.29

Champ optionnel relatif aux pages de paiement

Contenu de paypageData

Champ A partir de la version Commentaires
bypassReceiptPage HP_ 2.11

Champs optionnels relatifs au transactionId Sogenactif 1.0

Contenu de s10TransactionReference

Champ A partir de la version Commentaires
s10TransactionId HP_ 2.7
s10TransactionIdDate HP_ 2.7 Ce champ est calculé par notre serveur. Il est donc inutile de le valoriser (il sera ignoré si valorisé)

Champs optionnels relatifs au panier

Contenu de shoppingCartDetail

Champ A partir de la version Commentaires
shoppingCartTotalAmount HP_ 2.6
shoppingCartTotalQuantity HP_ 2.6
shoppingCartTotalTaxAmount HP_ 2.6
mainProduct HP_ 2.6
shoppingCartItemList HP_ 2.6 Liste de conteneur shoppingCartItem . Voir la partie Containers
mainProductCategoryList HP_ 2.24
discountAmount HP_ 2.24
giftCardAmount HP_ 2.27
giftCardCurrencyCode HP_ 2.27
giftCardCount HP_ 2.27

Contenu de shoppingCartItem

Champ A partir de la version Commentaires
productName HP_ 2.6
productDescription HP_ 2.6
productCode HP_ 2.6
productSKU HP_ 2.6
productUnitAmount HP_ 2.6
productQuantity HP_ 2.6
productTaxRate HP_ 2.6
productUnitTaxAmount HP_ 2.6
productCategory HP_ 2.6
productTaxCategory HP_ 2.6

Paramétrer la requête de paiement

Voici un exemple de paramétrage de la requête de paiement pour chaque fonctionnalité disponible dans Sogenactif Paypage POST (le détail de ces fonctionnalités est décrit dans le guide de configuration 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 Sogenactif

La page de confirmation du paiement, affichée par défaut par Sogenactif 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 multidevise

Dans le cas des transactions multidevises le code devise doit être spécifié dans la requête. C’est dans le contrat d’acquisition où 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|..
    

3-D Secure sélectif

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

      …|fraudData.bypass3DS=ALL|..
    

3-D Secure sélectif pour paiement One Clic

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

      …|fraudData.bypass3DS= MERCHANTWALLET|..
    

Inscription et paiement One Clic

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

      …|merchantWalletId=1205987|..
    

Traiter la réponse

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 sont des réponses HTTP(S) POST envoyées aux URL normalReturnUrl (obligatoire - réponse manuelle) et automaticResponseUrl (optionnelle - réponse automatique) précisées dans la requête.

Vous devez mettre en place le système permettant de décoder ces réponses, afin de connaître le résultat de requête.

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 . Ce champ est valorisé avec le champ responseEncoding de la requête.
Seal Signature du message réponse.
InterfaceVersion Version de l’interface du connecteur.

Si la valeur du champ 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.

Note: pour qu’un sceau soit calculé avec l'algorithme HMAC-SHA-256, les paramètres d'entrée de la requête doivent contenir le champ sealAlgorithm avec la valeur suivante : “HMAC-SHA-256”.

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

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 Sogenactif avec un lien de redirection vers votre site. Lorsque le client clique sur ce bouton, le serveur Sogenactif 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.

Note: la version actuelle d’InterfaceVersion est HP_ 2.33 . Veuillez consulter le dictionnaire de données 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 Sogenactif 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 Sogenactif sans passer par le navigateur Web du client. Par conséquent, elle est bien plus fiable car elle est toujours envoyée. Le serveur Sogenactif 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.

Note: la version actuelle d’InterfaceVersion est HP_ 2.33 . Veuillez consulter le dictionnaire de données pour une description complète des paramètres inclus dans la réponse.
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.

La réponse automatique est transmise en fin de paiement. Toutefois, si votre client abandonne son achat, par exemple en quittant son navigateur, la réponse automatique est transmise lorsque la session utilisateur expire (au bout de 15 minutes d’inactivité). Par conséquent, si votre client abandonne son achat, vous recevrez uniquement la réponse automatique (pas la réponse manuelle), avec un code réponse renseigné à 97, environ 15 à 16 minutes après la redirection du client sur les pages de paiement.

Si une réponse automatique n’est pas reçue au bout de 16 minutes environ, vous pouvez obtenir le résultat d’un paiement en appelant la méthode getTransactionData de l’interface Sogenactif Office Serveur , ou en analysant le contenu du journal des transactions. Vous pouvez également rechercher une transaction et voir son état en utilisant Sogenactif Gestion .

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 et si elles sont valides. Pour ce 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 Sogenactif .
  • 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 Sogenactif 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 Sogenactif . 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 Sogenactif Paypage automatiques et manuelles est identique. Le contenu peut varier en fonction du résultat (réussi ou autre).

Note: dans les réponses, en fonction de l’état de la transaction et du moyen de paiement choisi, certains champs peuvent être nuls, vides ou non renseignés. Veuillez consulter les documentations des moyens de paiement pour connaître les champs attendus dans les réponses.
Champ version Commentaires
acceptanceSystemApplicationId HP_ 2.18
acquirerContractNumber HP_ 2.25
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
authentExemptionReasonList HP_ 2.31
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 Sogenactif .
captureLimitDate HP_ 2.3
captureMode HP_ 1.0 Champ de la requête qui peut être surchargé par Sogenactif .
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 Sogenactif 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
guaranteeIndicator HP_ 2.0
hashPan1 HP_ 2.0
hashPan2 HP_ 2.0
holderAuthentMethod HP_ 2.4
holderAuthentProgram HP_ 2.5
holderAuthentRelegation HP_ 2.0
holderContactEmail HP_ 2.20
holderAuthentStatus HP_ 2.0
holderAuthentType HP_ 2.24
instalmentAmountsList HP_ 2.6
instalmentDatesList HP_ 2.6
instalmentNumber HP_ 2.6
instalmentTransactionReferencesList HP_ 2.6
interfaceVersion HP_ 1.0
intermediateServiceProviderOperationId HP_ 2.23
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
paymentAccountReference HP_ 2.31
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 preAuthenticationRuleResult.

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
schemeTransactionIdentifier HP_ 2.31
scoreColor HP_ 2.0
scoreInfo HP_ 2.0
scoreProfile HP_ 2.0
scoreThreshold HP_ 2.0
scoreValue HP_ 2.0
secureReference HP_ 2.26
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 systématiquement valorisé à ‘PROD’ pour le moment.
transactionReference HP_ 1.0
walletType HP_ 2.4

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 (en gras) :

      ..|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 adjacentes sont séparés par une virgule .

Exemple du champ preAuthorisationRuleResultList

Détail des règles fraude exécutées en préautorisation (en gras)

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

Si vous procédez à une authentification par sceau électronique (seal), vous devez impérativement vérifier que le sceau reçu correspond bien au sceau que vous recalculez avec les champs de la réponse.

Si le sceau reçu ne correspond pas au sceau que vous recalculez, l’état de la transaction est considéré comme inconnu : laissez la transaction en l’état, contactez le support et ne ré-exécutez pas la transaction de manière automatisée.

État 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 Sogenactif Go-No-Go

responseCode  = 05

complementaryCode  = XX

preAuthorisationRuleResultList

Le paiement a été refusé par le moteur de fraude Sogenactif que vous avez configuré.

Ne livrez pas la marchandise. Analysez le détail des règles fraudes exécutées par Sogenactif pour connaître la cause du refus (champ preAuthorisationRuleResultList ).

Refus Fraude Sogenactif

Scoring

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 Sogenactif que vous avez configuré

Ne livrez pas la marchandise. Analysez le détail des règles fraudes exécutées par Sogenactif pour connaître la cause du refus (champ preAuthorisationRuleResultList ).

Warning Fraude Sogenactif

Scoring

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 Sogenactif é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 Sogenactif pour connaître 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 le Portail Sogenactif et les connecteurs Sogenactif Office Serveur et Sogenactif Office Batch .

Refus 3-D Secure

reponseCode  = 05

holderAuthenStatus  = FAILURE

L’authentification du client a échoué, ce n’est pas nécessairement un cas de fraude. Vous pouvez proposer à votre client de payer avec un 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 un autre moyen de paiement en générant une nouvelle requête.

Repli VADS

responseCode  = 05

acquirerResponseCode  = A1

Le paiement a été refusé par l'acquéreur car il manque les données 3-D Secure dans la demande d'autorisation.
Veuillez retenter le paiement avec une cinématique 3-D Secure.

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.

Abandon du paiement responseCode = 97

acquirerResponseCode = non renseigné

Ne livrez pas la commande

Étape 3 : tester sur l’environnement de simulation

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

URL de simu du serveur https://payment-webinit.simu.sogenactif.com/paymentInit

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

Table 1. transactionReference généré par le commerçant
champ Valeur
ID du commerçant (merchantId) 002010000000002
Version de la clé (keyVersion) 1
Clé secrète 002010000000002_KEY1
Table 2. transactionReference généré par Sogenactif
champ Valeur
ID du commerçant (merchantId) 002010000000001
Version de la clé (keyVersion) 1
Clé secrète 002010000000001_KEY1
Table 3. transactionId généré par le commerçant
champ Valeur
ID du commerçant (merchantId) 002010000000003
Version de la clé (keyVersion) 1
Clé secrète 002010000000003_KEY1
Table 4. transactionId généré par Sogenactif
champ Valeur
ID du commerçant (merchantId) 002010000000004
Version de la clé (keyVersion) 1
Clé secrète 002010000000004_KEY1

Ce serveur de simulation 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.

Sogenactif Paypage simule donc l’appel aux serveurs d’autorisation pour vous permettre de tester les différents résultats d’un paiement.

Il n’est donc pas nécessaire d’utiliser des cartes réelles pour effectuer les tests.

Attention: puisque le merchantId 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 CB, VISA, MASTERCARD, AMEX

Les règles de simulation suivantes s’appliquent :

  • le numéro de carte (PAN) doit comporter de 15 à 19 chiffres (selon le moyen de paiement utilisé) ;
  • les six premiers chiffres du PAN déterminent le type de carte, conformément au tableau ci-dessous ;
    Type de carte Début du numéro de carte
    AMEX 340000
    VPAY 400000
    VISA 410000
    CB 420000
    Cartes co-badgées CB et VISA 430000
    Cartes co-badgées CB et VPAY 440000
    Cartes co-badgées CB et VISA_ELECTRON 450000
    Cartes co-badgées VISA et MASTERCARD 460000
    MAESTRO 500000
    MASTERCARD 510000
    Cartes co-badgées CB et MASTERCARD 520000
    Cartes co-badgées CB et MAESTRO 530000
  • le code réponse Sogenactif (champ responseCode ) est calculé à partir des deux derniers chiffres du numéro de carte ;
  • le code de sécurité (CVV) comporte 3 ou 4 chiffres. Cette valeur est sans importance pour le résultat de la simulation.

Exemple : si vous utilisez le numéro de carte 4100 00 00 0000 00 05 , la carte sera identifiée comme VISA et le paiement sera refusé (code réponse Sogenactif 05 ).

Note: si le code réponse Sogenactif calculé n’est pas référencé, la transaction est acceptée ( respondeCode  = 00).

Les cartes co-badgées peuvent être utilisées avec chacune des marques définies dans le tableau.

Toutes les cartes sont enrôlées 3-D Secure, vous êtes redirigé vers le serveur de simulation 3-D Secure sur lequel vous choisissez le résultat désiré de l’authentification 3-D Secure.

Tester des transactions iDeal

Si vous choisissez de tester iDeal, vous serez redirigé vers le serveur de simulation qui simule les transactions iDeal selon leur montant. Ensuite, vous retournerez au serveur de paiement qui affiche le ticket avec le résultat de la transaction.

Règles de simulation d’un paiement iDeal :

Montant de la transaction Réponse de iDeal
2,00 EUR Transaction annulée
3,00 EUR Transaction expirée
4,00 EUR Transaction non réalisée
5,00 EUR Échec de la transaction
Autres cas Transaction OK

Tester des transactions PayPal

Si vous choisissez de tester PayPal, vous êtes redirigé vers le serveur de simulation qui simule les transactions PayPal selon leur résultat du paiement chez PayPal. Ensuite, vous retournez au serveur de paiement qui affiche le ticket avec le résultat du paiement.

Étape 4 : valider le passage en production

Une fois la connexion de votre site Web à Sogenactif Paypage POST testée, vous êtes à présent en mesure de valider la connexion à Sogenactif Paypage POST de production.

Au préalable, nous conseillons d’isoler votre site Web du public pour éviter que des clients ne génèrent des requêtes pendant cette phase de validation.

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

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

URL https://payment-webinit.sogenactif.com/paymentInit
merchantId Identifiant de la boutique reçu par mail
SecretKey Clé secrète que vous récupérez via l’extranet Sogenactif Téléchargement
keyVersion Version clé secrète récupérée sur Sogenactif Téléchargement (logiquement 1 pour la 1ère clé)
Note: 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 :

  • faites 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érifiez que vos pages de paiement intègrent vos paramètres de personnalisation ;
  • consultez la transaction via Sogenactif Gestion à 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 Sogenactif Gestion (optionnel).

Le surlendemain :

  • vérifiez que l’opération de remboursement apparaît dans le journal des opérations ;
  • vérifiez sur votre compte le débit suite au remboursement.

Cette procédure de validation est également applicable au moyen de paiement PayPal.

Étape 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, 99,
    • fraude : responseCode  34,
    • nombre max de tentatives de paiement atteint : responseCode  75,
    • abandon : responseCode 97.

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 (si vous avez choisi cette option du journal).