Le MID
En souscrivant à Axepta, vous aurez accès à un ou plusieurs MID. Un MID ou Merchant ID permet d’identifier une boutique en ligne.
Il existe 3 types de MIDs :
- MasterMID: Permet d’avoir une vue globale de l’activité du commerçant sur les différentes boutiques qu’il possède. Le masterMID ne peut pas être utilisé pour réaliser des transactions mais est principalement utilisé pour se connecter au backoffice et visualiser l’ensemble de son activité.
- MID de test: Permet d’effectuer des transactions de test (sans remise en banque).
- MID de production: Permet d’effectuer des transactions dans un environnement de production (environnement LIVE, avec remise en banque).
Le passage en production se fait tout simplement à la main du commerçant, en changeant de MIDs (du MID de test au MID de production).
Les URLs
Redirection du client : URLSucess & URLFailure
Axepta redirige l’acheteur vers une page du marchand en fonction du résultat du paiement :
- URLSuccess : Page de "Succès du paiement" du marchant si le paiement est réussi
- URLFailure : Page de "Echec du paiement" du marchant si le paiement est échoué
Lorsque le paiement est effectué, le client est redirigé via HTTP GET vers la boutique du commerçant.
Axepta retourne ensuite un statut HTTP 302 (objet déplacé) et joint le statut du paiement en tant que paramètre avec chiffrement Blowfish à URLSuccess ou URLFailure.
Notification envoyée au Système d’information du commerçant : URLNotify
Après l’exécution du paiement, la solution de paiement notifie la boutique du résultat du paiement.
Pour ce faire, la solution de paiement appelle URLNotify via HTTP POST. Il s’agit d’une communication entièrement distincte de la connexion d’origine entre la boutique, l’acheteur et la solution de paiement.
L’appel Notify est autorisé uniquement via le Port 443 (TLS) pour des raisons de sécurité.
Si l’URLNotify de la boutique n’est pas accessible (p. ex. statut HTTP 500/404), la notification est répétée 8 fois en 24h.
Les données de réconciliation
Certaines données permettent au commerçant de faire le lien entre l’initialisation d’un paiement et le paiement effectif :
Reference number (RefNr) ou référence d’archivage :
La référence d’archivage ou « RefNr » est un champ qui doit être véhiculé dans toutes vos requêtes. Elle est présente dans tous les reportings Axepta.
Il s’agit d’un paramètre obligatoire de 12 caractères alpha-numériques (uniquement chiffres & lettres).
Transaction ID (TransID)
Ce champ représente la référence de la transaction unique sous la forme d’un paramètre obligatoire de 64 caractères alpha-numériques et pouvant comporter des caractères spéciaux.
Cette donnée est présente dans tous les reportings Axepta.
Description du panier (orderDesc)
Ce champ permet de passer en paramètre des données (descriptions des articles/produits achetés) qui seront retournées en l’état au commerçant.
Il peut également être affiché dans la page de paiement (customField) et est transmis de la requête de paiement au fichier de rapprochement.
Cette donnée est présente dans tous les reportings Axepta.
Synthèse des données clés de réconciliation : Réconciliation : Données clés
Les codes retours
Les codes retours se présentent sous la forme d’un code de 8 caractères répartis en 3 blocs : N8, ( N NNNNNNN)
N (status)
NNN (Catégorie)
NNNN (détails)
Exemple d’un code retour :
2 206 0203
2 Error
206 3DS credit card adapater for authorization protocol GICC
0203 Card brand does not support 3DS
Lien vers la liste complète des codes retours : https://docs.axepta.bnpparibas/display/DOCBNP/Codes+retour
Lien vers la liste des codes retours 3DSv2 : https://docs.axepta.bnpparibas/display/DOCBNP/3DS+Response+Codes