You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »



MultiExcerpt named Axepta FR was not found -- Please check the page name and MultiExcerpt name used in the MultiExcerpt-Include macro


Que faire lorsque je reçois mes données d’accès AXEPTA BNP PARIBAS ?


Vous allez d’abord recevoir un e-mail de bienvenue de la part de notre équipe support AXEPTA BNP Paribas (bnpparibas@computop.com).  Cet e-mail vous informe que vous allez recevoir, dans les prochaines minutes, un e-mail chiffré contenant vos données d’accès confidentielles. 


L’e-mail chiffré se présente sous la forme suivante (cet e-mail contient un numéro de référence, voir ci-dessous) :


Comment accéder au contenu de l'e-mail chiffré reçu ?


  1. Clic droit sur le fichier en pièce jointe (original_email.zip).
  2. Enregistrer sous un emplacement de votre choix dans votre ordinateur




3. Accéder au fichier, précédemment enregistré, et cliquer droit sur 7-ZIP et ensuite cliquer sur Extraire ici.

N.B. Si vous n’avez pas 7-ZIP sur votre machine, utilisez un équivalent tel que WINZIP.



4. Une fenêtre va alors apparaître pour vous demander un mot de passe. Renseigner le mot de passe que vous avez reçu par sms de BNP_Paribas.



NB. Si vous avez plusieurs boutiques, le sms contient votre numéro de référence mentionné sur l’e-mail chiffré reçu.



5. Une fois le mot de passe renseigné, un fichier nommé «BodyText » apparait dans votre dossier (format .htm). Double-cliquez dessus et ouvrez-le avec le navigateur web de votre choix (Firefox, Chrome, Edge, Safari…).

Vous aurez alors accès à une page contenant vos données d’accès:

  • Identifiant commerçant
  • Clé de chiffrement Blowfish
  • Clé HMAC


Ces 3 données vous permettront d’intégrer la solution de paiement AXEPTA BNP Paribas.



6. Enfin, vous allez recevoir un email récapitulant tous vos MIDs : 

  • Le Master MID vous permettra d’avoir une vue globale de votre activité sur les différents comptes que vous possédez (Test et Prod). Pour ce faire, connectez-vous sur le Back office Axepta en utilisant ce MasterMID et le mot de passe reçu (https://backoffice.axepta.bnpparibas/login.aspx). Veuillez noter que le masterMID ne peut pas être utilisé pour réaliser des transactions.
  • Le MID Test vous servira à effectuer des tests sans que les transactions soient remises en banque. Vous resterez dans un environnement de test.
  • Le MID Prod vous permettra d’accéder à l’environnement de production. Veuillez noter que le passage en mode de production de votre MID et la remise en banque de vos transactions seront effectifs dès que la configuration de votre compte sera finalisée.

Dans cet email vous recevrez également des cartes de test valables tout au long de la phase de test. 

Vous utilisez un module de paiement AXEPTA?

Si vous souhaitez utiliser un module de paiement AXEPTA BNP Paribas pour les CMS suivants : Prestashop / WooCommerce/ Magento, veuillez trouver ci-dessous les liens pour acheter ces modules.

Les liens vers ces boutiques sont les suivants :

  • Prestashop  :

https://addons.prestashop.com/fr/paiement-carte-wallet/50069-axepta-bnp-paribas.html

https://shop.quadra-informatique.fr/modules-ecommerce-cms/89-19-axepta-prestashop.html#/6-option_tranquillite_garantie_maintenance-sans_option_de_mise_a_jour_du_modu

  • WooCommerce

https://shop.quadra-informatique.fr/modules-ecommerce-cms/88-22-axepta-woocommerce.html#/6-option_tranquillite_garantie_maintenance-sans_option_de_mise_a_jour_du_module

  • Magento

Axepta Magento 2 (quadra-informatique.fr)


Une fois le module acheté, le commerçant envoie sa facture (preuve d'achat) à l'assistance de BNP Paribas ( assistance.ecommerce@bnpparibas.com ), et reçoit alors une clé d'activation qui lui permet d'activer et de configurer son module de paiement.

Les guides d'installation et de configuration des modules de paiements sont disponibles via ces liens :



Table des matières

Acronymes et abréviations

Formats des données :

a

alphabétique

as

alphabétique avec caractères spéciaux

n

numérique

an

alphanumérique

ans

alphanumérique avec caractères spéciaux

ns

numérique avec caractères spéciaux

bool

expression booléenne (true ou false)

3

longueur fixe avec 3 chiffres/caractères

..3

longueur variable avec maximum 3 chiffres/caractères

enum

énumération de valeurs admissibles

dttm

Date et heure ISO (AAAA-MM-JJThh:mm:ss)


Abréviations :

CND

condition

M

obligatoire (mandatory en anglais)

O

optionnel

C

conditionnel


Remarque : Veuillez noter que les noms des paramètres peuvent être en majuscules ou en minuscules.


Fichiers Batch

Le paiement via Batch consiste à transférer les données des transactions collectées des clients vers le serveur Axepta BNP Paribas sous forme de fichiers formatés. Le transfert peut se faire :

  • Manuellement via le back-office de BNP Paribas. (Se référer à la documentation Backoffice)
  • Automatiquement via un protocole de transfert sécurisé (sFTP).

Lors de ce processus, vous associez les données des transactions (comme l’identifiant, le montant et la devise) dans un fichier batch que vous transmettez ultérieurement à la solution de paiement. La solution de paiement procède ensuite aux paiements et enregistre le statut de transaction dans le fichier batch de retour. Après traitement, le commerçant peut télécharger le fichier batch avec les détails sur le statut de la transaction.

L’accès sFTP pour le transfert du fichier batch doit être demandé à l’Assistance BNP Paribas.

Les fichiers batch doivent être correctement structurés pour que la solution de paiement puisse les traiter.



Nom des fichiers Batch

Le nom d’un nouveau fichier batch commence par une lettre indiquant la phase. Par exemple T pour indiquer que le fichier vient d’être transféré. Il est suivi de la date de soumission au format AAAAMMJJ. Par exemple : 20160112. Celle-ci est suivie d’un décompte à trois chiffres qui commence à 001 et de l’identifiant du commerçant émis par BNP Paribas. Si vous soumettez plusieurs fichiers le même jour, vous devez définir le décompte sur 002, 003, 004, etc. L’extension du fichier doit être .DAT.

Le nom d’un fichier batch comprend donc quatre composants :

<Phase><Date><MerchantID><Counter>.dat

Le nom d’un fichier batch via FTP :

<Phase><Date><Counter><MerchantID>.dat


Composant

Description

Phase

T=Transféré, P= Traité (Processed en anglais)

Date

Date au format AAAAMMJJ (année, mois, jour)

Counter

Trois chiffres, décompte journalier de 001 à 999.

MerchantIDIdentifiant du commerçant (MID)

 

Le traitement du fichier batch passe par plusieurs phases indiquées dans le nom du fichier : le fichier d’origine du commerçant débute par le caractère T pour « transféré ». Après traitement, le fichier batch comporte le suffixe P (pour processed)

Si un commerçant (ayant le MerchandID : MerchantID) soumet deux fichiers batch le même jour, ces deux fichiers sont nommés comme suit :

T20160112001MerchantID.dat
T20160112002MerchantID.dat

Remarque : après que vous ayez transmis le fichier batch, le traitement des transactions débute. Après transmission et durant le traitement, le préfixe W (Waiting, en attente) est ajouté au fichier. Si le fichier batch est soumis via FTP/sFTP pour traitement, la phase doit être renommée W après l’upload par le système du commerçant. Le traitement commence uniquement après cette étape.

W20160112001MerchantID.dat
W20160112002MerchantID.dat

Lorsque toutes les transactions de paiement ont été effectuées, la solution de paiement marque les fichiers traités, qui contiennent désormais les détails du statut de transaction, avec la lettre P pour « Processed » (traité) et auxquels vous pouvez accéder dans la vue par batch du back office BNP Paribas via un téléchargement :

P20160112001MerchantID.dat
P20160112002MerchantID.dat


Transfert FTP de fichiers Batch

La solution de paiement vous permet de transférer des fichiers batch automatiquement via FTP (File Transfer Protocol). Pour transférer un fichier batch via FTP/sFTP, procédez comme suit :

  1. Enregistrer les données de transaction dans un fichier batch formaté
  2. Chiffrer le fichier batch
  3. Transférer le fichier batch
  4. Changer de phase après chargement (T ® W)
  5. Récupérer le fichier batch après traitement
  6. Vérifier le statut des transactions


Chiffrement du fichier Batch

Pour des raisons de sécurité, les fichiers batch doivent être chiffrés avant la transmission FTP/sFTP. Pour garantir un niveau de sécurité maximum, la solution de paiement utilise un chiffrement asymétrique avec PGP (Pretty Good Privacy). Le chiffrement avec GPG (GNU Privacy Guard) est également possible. Le fichier enregistré doit toutefois avoir l’extension .PGP, sans quoi aucun traitement n’est possible.

Le haut niveau de sécurité du chiffrement PGP repose sur un processus avec deux clés : une clé privée et une clé publique. BNP Paribas vous fournit une clé publique pour le chiffrement de votre fichier batch. Le fichier batch chiffré peut ensuite être déchiffré uniquement avec la clé secrète privée de BNP Paribas.

Vous pouvez également générer une clé publique et une clé privée pour votre entreprise. La solution de paiement chiffre le fichier batch avec votre clé publique. Le fichier peut ensuite être lu uniquement avec votre clé privée secrète.


Format des fichiers Batch

Un fichier batch comprend un en-tête (Header), plusieurs enregistrements et un pied de page (footer). Chaque entrée du fichier correspond à une ligne complétée avec CRLF (touche  Entrée). Les valeurs dans une ligne sont séparées par des virgules. Il s’agit du format CSV (Comma Separated Values, valeurs séparées par une virgule).

Les sections suivantes décrivent le format du fichier batch que vous transmettez à la solution de paiement et le fichier de réponse, dans lequel la solution de paiement enregistre les résultats des paiements.


Format des fichiers Batch soumis

Remarque : le fichier batch ne doit pas inclure de lignes vides au début et à la fin du fichier. Les lignes vides dans les listes sont uniquement prévues pour faciliter la lecture.

Remarque : les paramètres comme « Reason » ou « OrderDesc » peuvent ne pas contenir de virgules.

Remarque : dans les versions batch 2.x, il existe un autre champ pour <MID>. Il est donc possible pour un paramètre MasterMID de soumettre les transactions d’un SubMID


En-tête

Type,MerchantID,Date,Version


Enregistrement

Type,Action,<Amount>,<Currency>,<TransID>,<Data depends on Action>


Pied de page

Type,CountRecords,SumAmount


L’exemple suivant représente un fichier batch pour la capture de trois transactions par carte avec une valeur de 1,00 et 2,00 euros. Pour le premier paiement, le système du commerçant fournit le numéro de référence 123456, mais aucun numéro de référence n’est fourni pour le deuxième et le troisième :

HEAD,MerchantID,20160112,1.2


CC,Sale,100,EUR,1567890,123456,MasterCard,5490011234567890,200506,Your order from Jan. 4.

CC,Sale,100,EUR,1567891,,MasterCard,5490011234567890,200506,Your order from Jan. 4.

CC,Sale,200,EUR,10202280,,VISA,4907621234567890,200504,Your order from Jan. 4.


FOOT,3,400

 

La description de chaque champ et valeurs du jeu de données (Enregistrements/RECORDS) dans le fichier batch est disponible dans le chapitre correspondant du manuel sur la méthode de paiement.

 

Les paramètres généraux pour le transfert dans l’en-tête et le pied de page sont expliqués dans le tableau suivant :

Paramètre

Format

CND

Description

Type

a..11

M

« HEAD » pour en-tête (Header), « FOOT » pour pied de page (Footer) et, par exemple, « CC » pour carte. Le champ n’a pas à contenir 11 chiffres.

MerchantID

ans..30

M

Identifiant du commerçant (MID) fourni par BNP Paribas

Date

dttm8

M

Date de production du fichier au format AAAAMMJJ

Version

an6

M

La version batch utilisée détermine les paramètres facultatifs utilisés en addition. Les versions batch possibles dans chaque cas diffèrent selon la méthode de paiement et l’action effectuée.

Vous trouverez les versions possibles dans le chapitre sur les fichiers batch de la méthode de paiement correspondante.

CountRecords

n..5

M

Nombre d’enregistrements soumis sans en-tête (header) ni pied de page (footer)

SumAmount

n..12

M

Total des montants dans l’unité de devise la plus faible, p. ex. centimes dans le cas des euros, selon le tableau des devises.

Contactez l’Assistance si vous voulez capturer des montants inférieurs à 100 (unité de devise la plus faible).


Format des fichiers de reponse Batch

Lors du traitement des transactions, le gestionnaire des fichiers batch enregistre le statut de la transaction dans le fichier batch. Dans cette optique, les champs de statut et de code sont ajoutés dans les entrées de transaction dans la zone d’enregistrement (Record):

Enregistrement (Record)

CC,Capture,<Amount>,<Currency>,<TransID>,<RefNr>,<PayID>,<Status>,<Code>


Remarque : en règle générale, le retour des paramètres facultatifs dans le fichier de réponse se produit uniquement si ceux-ci étaient inclus dans le fichier soumis. En règle générale, aucune information d’envoi n’est fournie dans le fichier de réponse. Si vous avez à nouveau besoin de ces données, lisez-les à partir du paramètre de notification correspondant.

Les paramètres de réponse particuliers que le gestionnaire des fichiers batch enregistre dans la section d’enregistrement pour chaque transaction sont disponibles dans le chapitre relatif aux fichiers batch pour la méthode de paiement concernée.


Codes retours Batch

La solution de paiement prend en charge les codes d’erreur détaillés depuis la version 3.0. Il s’agit de codes hexadécimaux à huit chiffres. La structure et la signification des codes d’erreur sont décrites sur la base de l’exemple suivant :

2 105 0014


Le premier chiffre décrit le niveau de gravité de l’erreur. Toutes les valeurs supérieures à 0 indiquent un avertissement ou une erreur.

Remarque : un code d’erreur ne signifie pas nécessairement que la solution de paiement ou le système du commerçant a subi une erreur technique. La solution de paiement génère également un code d’erreur si une transaction a échoué car la banque refuse un paiement.

Les 2e, 3e et 4e chiffres du code d’erreur décrivent la catégorie de l’erreur. Les catégories d’erreur se rapportent aux erreurs de chiffrement (001) et de format (010), et aux détails des méthodes de paiement, initiés dans le cas des cartes (100) à débit immédiats (110) ou Cash&Go (140).

Les chiffres 5 à 8 du code d’erreur fournissent une indication sur les détails de l’erreur : instructions sur les problèmes de configuration comme des identifiants de terminaux manquants (0047) et dysfonctionnements au niveau du centre informatique de la banque du porteur de carte (121), mais également des refus standard de paiements par carte en cas de cartes expirées (110) ou de messages refusés (0100).

Remarque : les transactions sans erreur, pour des raisons de compatibilité avec la version 2.1, ne sont pas spécifiées par un 8, mais un zéro (0).

Vous trouverez la liste complète des codes d’erreur de la solution de paiement dans le fichier Excel.


Appels et réponses de Batch

Cette section décrit les paramètres qui doivent être transférés dans les enregistrements (Records) pour l’exécution d’un paiement par carte, et quelles informations peuvent être trouvées dans le fichier de réponse sur le statut du paiement.

La structure pour un paiement par carte dans un fichier batch à soumettre est la suivante :

HEAD,<MerchantID>,<Date>,<Version>

CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>]

CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,[<FinishAuth,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>]

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>]

CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>]

CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>]

CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>

FOOT,<CountRecords>,<SumAmount>

 

Exemple de versions batch :

Version 1.2:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>

Version 1.2.1:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>

Version 1.3:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>

Version 1.5:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<Zone>


Le tableau suivant décrit les champs et valeurs utilisés dans le jeu de données (Record (enregistrement)) dans le fichier batch :

Paramètre

Format

CND

Description

Type

a..11

M

« HEAD » pour en-tête (header), « FOOT » pour pied de page (footer), « CC » pour carte

Action

a..20

M

Le paramètre Action définit le type de la transaction :

Authorize (autorisation)

Capture

Sale

Refund

CreditEx (remboursement sans capture ; convenez de cela au préalable avec le Support BNP Paribas)

Reverse (annulation)

AuthSplit (capture partielle)

Renewal (renouvellement d’autorisation)

Amount

n..10

M

Montant dans l’unité de devise la plus petite (p. ex. centime d’euro).

Contactez l’Assistance si vous voulez capturer des montants inférieurs à 100 (unité de devise la plus faible).

Currency

a3

M

Code de devise, trois chiffres DIN / ISO 4217

TransID

ans..64

M

Identifiant de la transaction devant être unique pour chaque paiement.

Notez pour certaines connexions, les différents formats fournis au sein des paramètres spécifiques.

RefNr

an12

M

Numéro de référence unique

PayID

an32

M

Identifiant de cette transaction fournie par la solution de paiement

OrderDesc

ans..127

O

Description des produits achetés, prix à l’unité, etc.

CCBrand

a..22

C

Marque de la carte.

Notez bien l’orthographe ! Selon le tableau des marques de carte !

CCNr

n..16

C

Numéro de carte d’au moins 12 chiffres, numériques sans espace. Vous pouvez également transmettre un TOKEN (numéro de carte temporaire)

PCNr

n..16

O

Vous pouvez également transmettre un TOKEN (PCN) au lieu du numéro de carte réelle.

CCCVC

n..4

O

Vérification de carte : dans le cas de Visa et MasterCard, les 3 derniers chiffres sur la bande de signature de la carte. 4 chiffres dans le cas d’American Express.

CCExpiry

n6

O

Date d’expiration de la carte au format AAAAMM, p. ex. 201707.

FinishAuth

ans1

O

Version=1.4 : si vous utilisez le renouvellement d’autorisation, annulez la répétition avec la valeur Y dans le champ FinishAuth dans le cas d’une capture ou d’un remboursement. Exemple : vous capturez une livraison partielle. Le reste de la commande ne peut pas être fourni. Vous saisissez par conséquent Y dans le champ FinishAuth pour une capture partielle, afin que la solution de paiement n’autorise pas le montant restant.

RTFa1O

Abonnement à durée et montant fixes

  • Paiement initial : RTF=I
  • Echéances suivantes : RTF=R


Abonnement à durée et montants variables

  • Paiement initial : RTF=E
  • Echéances suivantes : RTF=M


La zone d’enregistrement dans le fichier de réponse pour les transactions par batch se présente comme suit :

HEAD,<MerchantID>,<Date>,<Version>

CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>],<Status>,<Code>

CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>],<Status>,<Code>

CC,AuthSplit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]

CC,Renewal,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>],<Status>,<Code>

CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>],<Status>,<Code>

CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>],<Status>,<Code>

CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<Status>,<Code>

FOOT,<CountRecords>,<SumAmount>

 

Le tableau suivant décrit les paramètres de réponse que le gestionnaire des fichiers batch enregistre dans la zone d’enregistrement (record) pour chaque transaction (paramètres standard non expliqués ici, comme <TransID> ou <RefNR>, et les paramètres de requête sont retournés non modifiés et correspondent à l’appel tel que spécifié auparavant) :

Paramètre

Format

CND

Description

Action

a..20

M

Le paramètre Action définit le type de la transaction : capture ou remboursement (voir ci-dessous).

PayID

an32

M

Identifiant de cette transaction fournie par la solution de paiement

Status

a..50

M

OK ou FAILED (échec)

Code

n8

M

Code d’erreur selon les codes de réponses de la solution de paiement

PCNr

n..16

C

Le TOKEN est uniquement retourné dans le cas des types de transaction Authorize ou Sale et RefundEx. Il commence par 0 et les 3 derniers chiffres correspondent à ceux du véritable numéro de carte.

 


Acronymes et abréviations

Formats des données :

a

alphabétique

as

alphabétique avec caractères spéciaux

n

numérique

an

alphanumérique

ans

alphanumérique avec caractères spéciaux

ns

numérique avec caractères spéciaux

bool

expression booléenne (true ou false)

3

longueur fixe avec 3 chiffres/caractères

..3

longueur variable avec maximum 3 chiffres/caractères

enum

énumération de valeurs admissibles

dttm

Date et heure ISO (AAAA-MM-JJThh:mm:ss)


Abréviations :

CND

condition

M

obligatoire (mandatory en anglais)

O

optionnel

C

conditionnel


Remarque : Veuillez noter que les noms des paramètres peuvent être en majuscules ou en minuscules.


Intégration du paiement par carte

Informations générales sur les paiement par carte

La plateforme de paiement de BNP Paribas prend en charge les principales cartes de paiement et devises dans le monde. Les données cartes sont protégées contre tout accès non autorisé grâce au chiffrement TLS. Des fonctions de sécurité supplémentaires sont intégrées, comme la prévention de la fraude et la gestion des risques.

MasterCard SecureCode (UCAF), Verified by Visa (VbV), Diners ProtectBuy, JCB J/Secure et American Express SafeKey permettent de sécuriser les demandes de paiement avec une validation du porteur de la carte grâce à la technologie 3D Secure, ce qui signifie que le porteur de carte doit confirmer son identité via une fonctionnalité d’authentification.

Le traitement d’une transaction par carte peut être effectué via :

  • Le formulaire de la plateforme de paiement,
  • Une connexion serveur-to-serveur,
  • Un transfert par batch


Les commerçants bénéficient du transfert de responsabilité lorsqu’ils utilisent l’authentification 3D Secure.

Sur le plan technique, le 3D Secure représente un processus d’authentification qui précède le paiement. Une fois les données de carte saisies, la plateforme de paiement vérifie l’identité du porteur de carte et le paiement n’est seulement exécuté qu’après l’authentification.

Il est essentiel de savoir si le paiement par carte est effectué via la page de paiement ou via une connexion serveur-to-serveur. Dans le premier cas, la page de paiement gère le processus d’authentification, alors que dans le cas d’une connexion server-to-server, le commerçant doit gérer l’authentification via une interface distincte.


Le formulaire de la page de paiement et les données de cartes sont hébergés par BNP Paribas (payssl.aspx)

Schéma des flux



Exécution d’une transaction avec 3D Secure

  • Le client sélectionne le paiement par carte sur le site et saisit les informations relatives à sa carte.
  • La plateforme de paiement reçoit les informations liées à la carte et vérifie, via une connexion au réseau de la carte (Visa, MasterCard, Diners, JCB, American Express) si la carte est enregistrée 3D Secure (Verified, SecureCode, Diners ProtectBuy, JCB-Card J/Secure ou SafeKey). Si la carte ne l’est pas, le paiement se fait via TLS.
  • La transaction est marquée par un « flag ». Cette marque (flag) indique à la banque acquéreur que cette transaction utilise l’authentification 3DS. Cette indication est essentielle dans le cas où le porteur de la carte contesterait le paiement car elle indique à la banque le transfert de responsabilité (Liability Shift).
  • La plateforme de paiement ouvre alors une fenêtre qui va permettre le client de se connecter à sa banque. Dans cette fenêtre, le client saisit le code d’accès reçu par sa banque.

 

Si le mot de passe est correct, la plateforme de paiement obtient une confirmation. Ce n’est qu’après confirmation que la plateforme de paiement débute le paiement.

Remarque : Veuillez noter qu'en cas de Fallback vers 3-D Secure 1.0, URLSuccess ou URLFailure est appelé avec GET. Par conséquent, vos systèmes devraient pouvoir recevoir des paramètres à la fois via GET et via POST.


Paramètres de la requête de paiement

Pour effectuer un paiement par carte via le formulaire de la plateforme de paiement, accédez à l’URL suivante :

 

Cette section décrit les paramètres à envoyer pour chaque connexion. Le second tableau décrit les paramètres de réponse qui sont identiques pour tous les paiements carte.

Remarque : pour des raisons de sécurité, la plateforme de paiement rejette toutes les requêtes de paiement avec des erreurs de formatage. Par conséquent, utilisez le type de donnée approprié pour chaque paramètre.

Le tableau suivant décrit les paramètres de requête de paiement chiffrés :

Paramètre

Format

CND

Description

RefNran12M

Le numéro de référence univoque du commerçant, qui sert de référence de remboursement dans le fichier EPA de l'acquéreur. Veuillez noter que sans la livraison de référence propre à la boutique, vous ne pouvez pas lire la transaction EPA ; quant au fichier de règlement supplémentaire, nous ne pouvons pas ajouter les données de paiement supplémentaires.

Notes:

  • Taille fixe de 12 caractères (uniquement des caractères alphabétiques (A..Z, a..z) et numériques (0..9) sont autorisés, pas de caractères spéciaux comme les espaces, )
  • Si le nombre de caractères renseignés est inférieur à 12, alors BNP Paribas complètera, en partant de la gauche, avec des "0" (Exemple : 000018279568)

MerchantID

ans..30

M

Identifiant du commerçant désigné par BNP Paribas. Ce paramètre doit être transmis non chiffré.

MsgVer

ans..5

M

Valeur : 2.0

Pour toutes les transactions cartes (CB, Visa, Mastercard, AMEX)

TransID

ans..64

M

Identifiant unique de la transaction

Amount

n..10

M

Montant dans l’unité de devise la plus petite (p. ex. centime d’euro).

Contactez l’Assistance si vous voulez capturer des montants inférieurs à 100 (unité de devise la plus faible).

Currency

a3

M

Devise, trois chiffres selon ISO 4217

MAC

an64

M

Code HMAC (Hash Message Authentication Code) avec algorithme SHA-256

URLSuccess

ans..256

M

URL appelant la plateforme de paiement si le paiement a abouti. L’URL peut uniquement être appelée via le port 443. Cette URL ne doit pas contenir de paramètre: afin d’échanger les valeurs entre la plateforme de paiement et la boutique, utilisez le paramètre UserData (Données utilisateur).

URLFailure

ans..256

M

URL complète appelant la plateforme de paiement si le paiement n’a pas abouti. L’URL peut uniquement être appelée via le port 443. Cette URL ne doit pas contenir de paramètre. Afin d’échanger les valeurs entre la plateforme de paiement et la boutique, utilisez le paramètre UserData (Données utilisateur).

Response

a7

O

Réponse de statut envoyée par la plateforme de paiement à URLSuccess et URLFailure, doit être chiffrée. À cette fin, transmettez le paramètre Response=encrypt.

URLNotify

ans..256

M

URL appelée par la plateforme de paiement afin de notifier la boutique du résultat du paiement. L’URL peut uniquement être appelée via le port 443. Cette URL ne doit pas contenir de paramètre ; utilisez le paramètre UserData.

UserData

ans..1024

O

Si cela est spécifié dans la requête, la plateforme de paiement transmet le paramètre avec le résultat du paiement à la boutique

Capture

ans..6

O

Détermine le type et l’heure de la capture.

AUTO : capture immédiate après autorisation (valeur par défaut). MANUAL : capture effectuée par le commerçant.

<Number> : délai en heures jusqu’à la capture (nombre de 1 à 696).

OrderDesc

ans..768

M

Description des produits achetés, prix à l’unité, etc.

ReqID

ans..32

O

Pour éviter les paiements en double, saisissez une valeur alphanumérique qui identifie votre transaction et ne peut être attribuée qu’une seule fois. Si la transaction est à nouveau soumise avec le paramètre ReqID identique, la plateforme de paiement n’exécute pas le paiement et se contente de retourner le statut de la transaction d’origine. Attention : Plateforme de paiement doit afficher un statut de transaction finalisée pour la première action initiale. Les introductions avec un ReqID identique pour un statut ouvert sont traitées à intervalles réguliers.

Plain

ans..50

O

Valeur définie par le commerçant pour retourner certaines informations non chiffrées (p. ex. identifiant du commerçant (MID))

Custom

ans..1024

O

Le commerçant peut soumettre plusieurs valeurs séparées par | et qui sont retournées non chiffrées et séparées par &.

Custom=session=123|id=456 devient dans la réponse Session=123&id=456

expirationTime

ans..19

O

Date et heure de fin du traitement de la transaction, en heure UTC.

Format : AAAA-MM-jjTHH:mm:ss

AccVerify

a3

O

Si AccVerify=Yes, la carte sera vérifiée du côté de l’acquéreur selon la description de l’interface de l’acquéreur. Le commerçant doit soumettre uniquement ce paramètre ; le paramètre Amount est facultatif. Si Amount est utilisé, nous remplaçons le montant selon la description de l’interface de l’acquéreur. Au paiement, Amount=0 est enregistré.

Valeur autorisée : yes

Pour adapter la mise en page de la page SSL de votre boutique, vous pouvez utiliser les paramètres non chiffrés suivants :

Paramètre

Format

CND

Description

Template

ans..20

O

Nom du fichier XSLT avec votre propre mise en page pour le formulaire de paiement. Si vous voulez utiliser le modèle BNP Paribas repensé et avec rétrocompatibilité, transférez le nom de modèle « ct_compatible ». Si vous voulez utiliser le modèle BNP Paribas réactif (responsive) pour les périphériques mobiles, transférez le nom de modèle « ct_responsive ».

Language

a2

(enum)

O

Code de langue : <de> allemand, <en> anglais, <fr> français, <it> italien, <nl> néerlandais, <pt> portugais, <es> espagnol

La langue par défaut est le français.

URLBack

ans..256

O

URL pour le bouton « Annuler »

CCSelect

a..16

O

Détermine le type de carte présélectionnée dans le formulaire

CustomField[n]

Ans..50

O

Champs pouvant être utilisés par le commerçant. Nous proposons actuellement 9 champs. De « CustomField1 » à « CustomField9 »


Paramètres du résultat de la requête de paiement


Le tableau suivant décrit les paramètres du résultat transmis par la plateforme de paiement à URLNotify, URLSuccess ou URLFailure. Si vous avez spécifié le paramètre Response=encrypt, les paramètres suivants sont envoyés chiffrés avec la méthode Blowfish à votre système :

Paramètre

Format

CND

Description

RefNran12OC

Le numéro de référence univoque du commerçant, qui sert de référence de remboursement dans le fichier EPA de l'acquéreur. Veuillez noter que sans la livraison de référence propre à la boutique, vous ne pouvez pas lire la transaction EPA ; quant au fichier de règlement supplémentaire, nous ne pouvons pas ajouter les données de paiement supplémentaires.

Notes:

  • Taille fixe de 12 caractères (uniquement des caractères alphabetiques (A..Z, a..z) et numériques (0..9) sont autorisés, pas de caractères spéciaux comme les espaces)
  • Pour AMEX : le champ RefNr est obligatoire
  • Si le nombre de caracètres renseignés est inférieur à 12, alors BNP Paribas complètera, en partant de la gauche, avec des "0" (Exemple : 000018279568)

MID

ans..30

M

Identifiant du commerçant (MerchantID) attribué par BNP Paribas.

PayID

an32

M

Identifiant attribué par la plateforme de paiement pour le paiement ; p. ex. pour référencement dans les fichiers batch

XID

an32

M

Identifiant pour toutes les transactions uniques (autorisation, capture, remboursement) pour un paiement attribué par la plateforme de paiement

TransID

ans..64

M

Numéro de transaction du commerçant

Status

a..50

M

OK / AUTHORIZED (URLSuccess) / FAILED (URLFailure)

Description

ans..1024

M

Détails supplémentaires dans le cas où le paiement est rejeté. N’utilisez pas la Description, mais le paramètre Code pour l’analyse du statut de transaction !

Code

n8

M

Code erreur de réponses de la plateforme de paiement (voir fichier Excel des codes erreur)

MAC

an64

M

Code HMAC (Hash Message Authentication Code) avec algorithme SHA-256

UserData

ans..1024

O

Si cela est spécifié dans la requête, la plateforme de paiement transmet le paramètre avec le résultat du paiement à la boutique

PCNr

n16

O

TOKEN (Pseudo Card Number, numéro de carte temporaire) : numéro aléatoire généré par la plateforme de paiement qui représente un numéro de carte authentique. Le TOKEN (PCN) commence par 0, et les 3 derniers chiffres correspondent à ceux du véritable numéro de carte. Vous pouvez utiliser le PCN comme un numéro de carte authentique pour une autorisation, une capture et un remboursement.

CCBrand

a..22

OC

Désignation de la marque de carte

CCExpiry

n6

OC

En combinaison avec PCNr : date d’expiration de la carte au format AAAAMM (201706).

maskedpan

an..19

OC

Numéro de carte masqué 6X4

CAVV

ans..40

OC

Dans le cas de 3D Secure avec hébergement d’authentification (requête 3D sans autorisation uniquement) : valeur de validation d’authentification de porteur de carte : contient la signature numérique pour l’authentification avec l’ACS de la banque émettrice de la carte.

ECI

n2

OC

Pour 3D Secure : l’indicateur d’e-commerce ACS : définit le niveau de sécurité d’un paiement par carte via les différents canaux de communication : MOTO, SSL, Verified by Visa, etc.

DDD

a1

C

Pour l’hébergement d’authentification 3D Secure :

Y - entièrement authentifié (authentification complète effectuée)

N - not enrolled (vérifié, mais l’émetteur ne participe pas)

U - non éligible (erreur technique)

A - attempt (la carte ne participe pas)

B - bypass (contournement, uniquement pour CardinalCommerce)

Type

ans..20

C

Pour 3D Secure uniquement, en réponse à URLNotify : abréviation du type de paiement, (exemple : SSL)

Plain

ans..50

O

Une valeur définie par le commerçant pour retourner certaines informations non chiffrées (p. ex. identifiant du commerçant)

Custom

ans..1024

O

Le commerçant peut soumettre plusieurs valeurs séparées par | et qui sont retournées non chiffrées et séparées par &.

Custom=session=123|id=456 devient dans la réponse Session=123&id=456

CustomField[n]

ans..50

O

Champ pouvant être utilisé individuellement par le commerçant. Actuellement, 9 champs de CustomField1 à CustomField9 sont pris en charge.

 CodeExt an2 O Code d'erreur de CAPN. 
Approvalcode an..6 O Code d'autorisation de la transaction
 TerminalID n..7 OTerminalID utilisé pour le processing 
 VUNr n..7 O Numéro de contact d'acquisition 
schemeReferenceIDans..64 O

Générée par la banque du porteur ou le réseau

Cette donnée sera stockée par le marchand et utiliser pour chaîner les transactions récurrentes à la 1ère transaction d'un abonnement (cas du paiement récurrent seulement)

Paiement récurrent carte (Abonnement)

 


Le formulaire de la page de paiement est hébergé par le commerçant et les données de carte sont hébergées par BNP Paribas (paynow.aspx)

Même processus 3DS que pour payssl.aspx

Un Silent-order post associe les avantages des formulaires de la plateforme de paiement et de la connexions serveur-to-serveur : contrairement au formulaire de la plateforme de paiement, où le formulaire est chargé depuis le serveur de la plateforme de paiement via l’appel de payssl.aspx, le Silent order post doit être fourni par le système du commerçant. Le formulaire utilise les mêmes paramètres que ceux décrits ci-dessous.

Contrairement au formulaire de la plateforme de paiement, les paramètres ne sont pas transférés en tant que paramètres d’URL comme c’est le cas lors de l’appel payssl.aspx, mais en tant que paramètres de saisie du formulaire.

Payssl

Paynow

payssl.aspx?MerchantID=[mid]&Len=[len]&Data=[data]

<form action=paynow.aspx>

<input type="hidden" name="MerchantID" value=[mid]>

<input type="hidden" name="Len"        value=[len]>

<input type="hidden" name="Data"       value=[data]>

:

</form>

Les données de carte doivent être transmises à paynow.aspx avec les paramètres suivants :

Paramètre

Format

CND

Description

CCNr

n..16

M

Numéro de carte d’au moins 12 chiffres, numérique sans espace

CCCVC

n3

O

Numéro de vérification de carte : les trois derniers chiffres sur la bande de signature de la carte

CCExpiry

n6

M

Date d’expiration de la carte au format AAAAMM, p. ex. 201807.

CCBrand

a..22

M

Désignation de la marque de carte.

Notez bien l’orthographe ! Selon le tableau des marques de carte !


Une fois que le client a saisi les données de sa carte, les données de paiement sont transférées à la page Silent order post où le paiement est exécuté via 3D Secure. Les détails du formulaire doivent être directement transférés à la page Silent order post, mais ne doivent pas  être transmis au système du commerçant. De plus, il se peut qu’aucune donnée PCI ne soit transmise à la page Silent order post en tant que paramètres de saisie supplémentaires.

Remarque : les nouvelles tentatives automatiques au niveau de la plateforme de paiement doivent être désactivées lors de l’utilisation de Paynow.aspx. En effet, lors d’une nouvelle tentative, la plateforme de paiement ne peut pas rediriger le client vers le formulaire de saisie  de la boutique précédemment utilisé. Contactez le Support BNP Paribas pour désactiver les nouvelles tentatives.

Afin d’utiliser cette option, le commerçant doit respecter l’exigence PCI relative au SAQ A-EP.



Le formulaire de la page de paiement et les données de cartes sont hébergés par le commerçant (Serveur-to-Serveur)

Schéma des flux


Exécution d’une transaction avec 3D Secure via la connexion serveur-to-serveur

Pour procéder à l’authentification, la plateforme de paiement connecte le porteur de carte à sa banque, qui confirme son identité. Un paiement exécuté avec Verified by Visa, MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure ou American Express SafeKey se fait en deux étapes : authentification et paiement.

Dans les étapes suivantes, la plateforme de paiement répond différemment dans deux situations :

  • Cas 1: Authentification 3D Secure via une page affichée en pop-up

Si la carte est enregistrée pour Verified, SecureCode, ProtectBuy, J/Secure ou SafeKey, la plateforme de paiement retourne une page HTML affichée en pop-up (fenêtre superposée). Cette page HTML (qui contient une fonction en Javascript appelée « Initiate3DSec() ») effectue la connexion avec la banque du porteur de la carte et permet de faire la correspondance entre le code entré par le porteur (client de la boutique) et le code envoyé par la banque.  

Remarque : l’utilisation d’une fenêtre séparée peut entraîner des problèmes avec les bloqueurs de fenêtres contextuelles (pop-up) dans le navigateur du client. Par conséquent, le cas 2 décrit une alternative sous la forme d’une variante iFrame.

L’exemple suivant présente une page dans laquelle le code HTML est intégré :

<HTML>

<HEAD>

<META http-equiv=Content-Type content="text/html; charset=unicode">

       <SCRIPT language="javascript">

<!--

<Response excerpt from request: HTML with JavaScript>

       //-->

       </script>

       </HEAD>");

       <BODY onload="javascript:Initiate3DSec();">

<table><tr>

<td align="center"><font face="Verdana" size="-1"><b>Please identify yourself with 3D Secure!</b></font></td>

</tr></table>");

</BODY>

</HTML>

 

Remarque : vous pouvez aussi utiliser ce code si vous voulez uniquement vérifier l’identité du porteur de la carte sans procéder à un paiement par carte. Notre équipe support peut paramétrer votre compte de façon à ce que la plateforme de paiement puisse procéder à l’authentification avec Verified, SecureCode, ProtectBuy, J/Secure ou SafeKey sans faire de paiement (Authentication hosting).

Lorsque le client a été authentifié grâce à sa banque, le serveur de contrôle d’accès (ACS, Access Control Server) de la banque appelle l’url  TermURL de la boutique. Dans le cas de cette requête, l’ACS transfère les paramètres suivants via GET (QueryString)  à l’url  TermURL de la boutique : MID, PayID et TransID. Le paramètre PARes est transféré via POST.

Remarque : le paramètre PAResponse doit être URL-encoded, mais non chiffré avec la méthode Blowfish, car le contenu peut inclure des caractères spéciaux.

Le paramètre doit être transféré dans son intégralité via la méthode POST à l’URL suivante :

Remarque : si vous transférez les paramètres PARes et MID, utilisez les paramètres MerchantID (identifiant du commerçant) et PAResponse pour la page direct3d.aspx.


  • Cas 2: Authentification 3D Secure via une page affichée en iFrame

Une alternative au pop-up, le commerçant peut choisir l’iFrame comme méthode d’affichage de la page d’authentification 3DS. Le porteur de carte peut effectuer l’authentification auprès de sa banque sur la page où il se trouve via une autre interface affichée en iFrame ; cela évite les difficultés rencontrées avec les bloqueurs de fenêtres contextuelles (pop-up) dans le navigateur du client.

Si la carte est enregistrée sur le serveur (Directory Server), la plateforme de paiement renvoie les paramètres suivants via la connexion socket.

Paramètre

Format

CND

Description

ACSURL

ans..

C

Uniquement dans le cas des cartes enregistrées : URL du serveur de contrôle d’accès de l’émetteur de carte avec paramètres de requête joints (sans encodage URL). Il est possible d’utiliser l’esperluette et le point d’interrogation du serveur ACS comme valeurs dans l’URL ; tout caractère précédant le paramètre PAReq fait partie d’ACSURL.

PaReq

ans..

M

Requête d’authentification du payeur (URL-encoded)

MD


M

Les données du commerçant sont une valeur vide, qui doit être transférée pour des raisons de compatibilité

TermURL

ans..

M

Adresse de retour de la boutique. La plateforme de paiement ajoute les paramètres PayID, TransID et MID comme paramètres de demande au TermURL initial séparés par un point d’interrogation.


Exemple de traitement correct d’ACSURL et de TermURL :

acsurl=a?b=c&d=e&pareq=f&termurl=g?PayID=h&TransID=i&MID=j

ACSURL: a?b=c&d=e

TermURL: g?PayID=h&TransID=i&MID=j


Remarque : dans ce processus, les données doivent parfois être transférées directement depuis le réseau de la banque. Par conséquent, le paramètre ACSURL n’est pas URL-encoded, bien que la plateforme de paiement utilise d’autres données URL-encoded.

Ces paramètres doivent être inclus en tant que champs MASQUÉS dans une page HTML qui poste elle-même vers l’URL ACS. L’exemple suivant présente cette page HTML, dans laquelle les paramètres de retour sont intégrés :

<HTML>

<HEAD>

<META http-equiv=Content-Type content="text/html; charset=unicode">

<A content="MSHTML 6.00.2800.1106" name=GENERATOR>

</HEAD>

<BODY onload="sendpareq.submit();">

<FORM action="[ACSURL]" method="POST" name="sendpareq">

<input type="hidden" name="MD" value="">

<input type="hidden" name="PaReq" value="[PaReq]">

<input type="hidden" name="TermUrl" value="[TermUrl]">

</FORM>

</BODY>

</HTML>


Remarque : vous pouvez aussi utiliser ce code si vous voulez uniquement vérifier l’identité du porteur de carte sans procéder immédiatement à un paiement par carte (hébergement d’authentification). Le Support BNP Paribas peut configurer votre paiement, afin que la plateforme de paiement puisse appliquer le Verified by Visa ou le SecureCode sans paiement.

Lorsque le client a été authentifié grâce à sa banque, le serveur de contrôle d’accès (ACS, Access Control Server) de la banque appelle l’url TermURL de la boutique. Dans le cas de cette requête, l’ACS transfère les paramètres suivants via GET (QueryString) via l’url TermURL de la boutique : MID, PayID et TransID (sans chiffrement). Le paramètre PARes est transféré sans chiffrement via POST.

Remarque : le paramètre PAResponse doit être encodé au format URL, mais non chiffré avec la méthode Blowfish, car le contenu peut inclure des caractères spéciaux.

Le paramètre doit être transféré dans son intégralité via POST à l’URL suivante :

 

Remarque : si vous transférez les paramètres ACS, PARes et MID, utilisez l’identifiant du commerçant et PAResponse pour la page direct3d.aspx.



Appel de l’interface : paramètres généraux

Remarque : pour les paiements par carte avec 3D Secure, prenez connaissance des différents cas expliqués dans le chapitre précédent. Si la carte est enregistrée pour Verified, SecureCode ou SafeKey, la phase suivante est divisée en deux étapes : authentification et paiement. Toutefois, cela commence toujours de la même façon via l’interface direct.aspx. La première réponse correspond à la réception du code JavaScript ou d’autres paramètres afin de procéder à un second appel de l’interface direct3d.aspx. Ce n’est qu’après que vous recevez le paramètre répertorié en tant que réponse.

(info) La carte doit être encore valide au moment de la saisie / du remboursement. BNP Paribas accepte donc les cartes lorsqu'elles sont valables au moins 1 semaine avant leurs expirations (par ex. CC expire : 2020-03 autorisations possibles jusqu'au 2020-03-24, 23:59:59).

Pour procéder à un paiement par carte TLS via une connexion serveur-to-serveur, appelez l’URL suivante :


Remarque : pour des raisons de sécurité, la plateforme de paiement rejette toutes les requêtes de paiement avec des erreurs de formatage. Par conséquent, utilisez le type de donnée approprié pour chaque paramètre.

Le tableau suivant décrit les paramètres de requête de paiement chiffrés :

Paramètre

Format

CND

Description

RefNran12OC

Le numéro de référence univoque du commerçant, qui sert de référence de remboursement dans le fichier EPA de l'acquéreur. Veuillez noter que sans la livraison de référence propre à la boutique, vous ne pouvez pas lire la transaction EPA ; quant au fichier de règlement supplémentaire, nous ne pouvons pas ajouter les données de paiement supplémentaires.

Notes:

  • Taille fixe de 12 caractères (uniquement des caractères alphabetiques (A..Z, a..z) et numériques (0..9) sont autorisés, pas de caractères spéciaux comme les espaces)
  • Pour AMEX : le champ RefNr est obligatoire
  • Si le nombre de caracètres renseignés est inférieur à 12, alors BNP Paribas complètera, en partant de la gauche, avec des "0" (Exemple : 000018279568)

MerchantID

ans..30

M

Identifiant du commerçant (MID) attribué par BNP Paribas. Ce paramètre doit être transmis non chiffré.

MsgVerans..5M

Version du message

Valeur acceptée : 2.0

TransID

ans..64

M

Identifiant de la transaction devant être unique pour chaque paiement

Amount

n..10

M

Montant dans l’unité de devise la plus petite (p. ex. centime d’euro).

Contactez l’Assistance si vous voulez capturer des montants inférieurs à 100 (unité de devise la plus faible).

Amount3D

n..10

OC

Uniquement pour 3D Secure : montant pour l’authentification avec Verified, SecureCode et SafeKey si le montant est différent. Par exemple : le client confirme le prix d’un vol de 120 euros avec Verified, mais l’agent de voyage capture uniquement les frais de réservation de 20 euros : Amount3D=12 000; Amount=2 000. Montant dans l’unité de devise la plus petite (p. ex. centime d’euro)

Contactez l’Assistance si vous voulez capturer des montants inférieurs à 100 (unité de devise la plus faible).

Currency

a3

M

Devise, trois chiffres DIN / ISO 4217

CCNr

n..19

M

Numéro de carte d’au moins 12 chiffres, numérique sans espace. Vous pouvez également transmettre un numéro PCN. (pseudo card numnber).

CCCVC

n..4

O

Numéro de vérification de carte (CVV) : pour Visa et MasterCard, les 3 derniers chiffres sur la bande de signature de la carte. Pour American Express, les 4 derniers chiffres.

CCExpiry

n6

M

En combinaison avec TOKEN : date d’expiration de la carte au format AAAAMM (201706).

CCBrand

a..22

M

Désignation de la marque de carte.

Notez bien l’orthographe ! Selon le tableau des marques de carte !

Capture

ans..6

O

Détermine le type et l’heure de la capture. AUTO : capture immédiate après autorisation (valeur par défaut). MANUAL : capture effectuée par le commerçant. <Number> : délai en heures jusqu’à la capture (nombre entier : 1 à 696).

OrderDesc

ans..768

M

Description des produits achetés, prix à l’unité, etc.

TermURL

ans..256

C

Uniquement pour 3D Secure. URL de la boutique sélectionnée par le serveur ACS (Access Control Server) de la banque du porteur de carte pour la transmission du résultat de l’authentification. La banque transfère les paramètres suivants : PayID, TransID et MerchantID via GET et le paramètre PAResponse via POST à TermURL.

UserAgent

ans..128

C

Uniquement pour 3D Secure. Type de navigateur de l’utilisateur appelant la page. Par exemple : IE Mozilla/4. 0 (compatible ; MSIE 6.0 ; Windows NT 5.0 ; NET CLR 1.0.3705)

HTTPAccept

ans..128

C

Uniquement pour 3D Secure : types MIME que les clients du commerçant acceptent. P. ex. image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd. ms-powerpoint, application/vnd. ms-excel, application/msword, */*

MAC

an64

M

Code HMAC (Hash Message Authentication Code) avec algorithme SHA-256

ReqID

ans..32

O

Pour éviter les paiements en double, saisissez une valeur alphanumérique qui identifie votre transaction et ne peut être attribuée qu’une seule fois. Si la transaction est à nouveau soumise avec le paramètre ReqID identique, la plateforme de paiement n’exécute pas le paiement et se contente de retourner le statut de la transaction d’origine. Attention : Plateforme de paiement doit afficher un statut de transaction finalisée pour la première action initiale. Les introductions avec un ReqID identique pour un statut ouvert sont traitées à intervalles réguliers.

AccVerify

a3

O

Si AccVerify=Yes, la carte sera vérifiée du côté de l’acquéreur. alors Le commerçant doit soumettre le paramètre AccVerify (obligatoire) et peux  utiliser le paramètre Amount  (facultatif) pour ajouter un montant . La valeur par defaut du montant (amount) est 0

Le tableau suivant fournit les paramètres avec lesquels la plateforme de paiement répond :

Paramètre

Format

CND

Description

MID

ans..30

M

Identifiant du commerçant

PayID

an32

M

Identifiant attribué par la plateforme de paiement pour le paiement ; p. ex. pour référencement dans les fichiers batch

XID

an32

M

Identifiant pour toutes les transactions uniques (autorisation, capture, remboursement) pour un paiement attribué par la plateforme de paiement

TransID

ans..64

M

Numéro de transaction du commerçant

Status

a..50

M

OK ou AUTHORIZED (URLSuccess) et FAILED (URLFailure)

Description

ans..1024

M

Détails complémentaires dans le cas où le paiement est rejeté. N’utilisez pas la Description, mais le paramètre Code pour l’analyse du statut de transaction !

Code

n8

M

Code d’erreur selon les codes de réponses de la plateforme de paiement

PCNr

n16

O

TOKEN (Pseudo Card Number) : numéro aléatoire généré par la plateforme de paiement qui représente un numéro de carte . Le TOKEN (PCN) commence par 0, et les 3 derniers chiffres correspondent à ceux du véritable numéro de carte. Vous pouvez utiliser le PCN comme un numéro de carte  pour l’autorisation, la capture et les remboursements.

CCExpiry

n6

OC

En combinaison avec TOKEN : date d’expiration de la carte au format AAAAMM (201706).

CCBrand

a..22

OC

En combinaison avec PCNr : Désignation de la marque de carte

Notez bien l’orthographe ! Selon le tableau des marques de carte !

maskedpan

an..19

OC

Numéro de carte masqué 6X4

CAVV

ans..40

OC

Dans le cas de 3D Secure avec hébergement d’authentification (uniquement requête 3D sans autorisation) : valeur de validation d’authentification de porteur de carte : contient la signature numérique pour l’authentification avec l’ACS de la banque émettrice de la carte.

ECI

n2

OC

Pour 3D Secure : indicateur d’e-commerce ACS : définit le niveau de sécurité d’un paiement par carte via les différents canaux de communication : MOTO, SSL, Verified by Visa, etc.

DDD

a1

C

Pour l’hébergement d’authentification 3D Secure :

Y - entièrement authentifié (authentification complète effectuée)

N - non abonné (vérifié, mais l’émetteur ne participe pas)

U - non éligible (erreur technique)

A - tentative (la carte ne participe pas)

B - contournement (contournement, uniquement pour CardinalCommerce)

ACSXID

ans..40

O

Uniquement pour les cas 2 et 3 (avec et sans fenêtre séparée : pages 31 et 32 de ce guide) avec hébergement d’authentification : identifiant de transaction. Le paramètre ACSXID est transféré avec l’autorisation à l’acquéreur

 


Paramètres supplémentaires pour la connexion AMEX CAPN

Outre les paramètres généraux décrits ci-dessus pour la connexion de carte, AMEX exige les paramètres supplémentaires suivants :

Paramètre

Format

CND

Description

RefNran12M

Le numéro de référence univoque du commerçant, qui sert de référence de remboursement dans le fichier EPA de l'acquéreur. Veuillez noter que sans la livraison de référence propre à la boutique, vous ne pouvez pas lire la transaction EPA ; quant au fichier de règlement supplémentaire, nous ne pouvons pas ajouter les données de paiement supplémentaires.

Notes:

  • Taille fixe de 12 caractères (uniquement des caractères alphabetiques (A..Z, a..z) et numériques (0..9) sont autorisés, pas de caractères spéciaux comme les espaces)
  • Si le nombre de caracètres renseignés est inférieur à 12, alors BNP Paribas complètera, en partant de la gauche, avec des "0" (Exemple : 000018279568)

AmountAuth

n..10

M

Carte prépayée : montant actuellement autorisé dans la plus petite unité de la devise

ContractIDn..8OAutre référence pouvant être utilisée pour récupérer la combinaison TerminalID/numéro de cocontractant

Coordonnées/vérification d'adresse (AVS)

FirstName

ans..15

O

Prénom du client

LastName

ans..30

O

Nom du client

AddrStreet

ans..20

O

Rue et numéro, par ex. 18850~N~56~ST~#301

AddrZip

n..9

O

Code postal

eMail

ans..60

O

Adresse e-mail du client

Phone

n..10

O

Numéro de téléphone du client : pour les pays qui n'utilisent pas ce système, veuillez envoyer les 10 derniers chiffres

sdFirstName

ans..15

O

Prénom dans l'adresse de livraison

sdLastName

ans..30

O

Nom dans l'adresse de livraison

sdStreet

ans..50

O

Rue et numéro dans l'adresse de livraison, par ex. 4102~N~289~ST~#301

sdZip

n..9

O

Code postal dans l'adresse de livraison

sdCountryCode

n3

O

Code de pays dans l'adresse de livraison conformément à la norme ISO-3166-1, codes numériques (3 chiffres)

sdPhone

ans..10

O

Numéro de téléphone dans l'adresse de livraison : pour les pays qui n'utilisent pas ce système, veuillez envoyer les 10 derniers chiffres

Le tableau ci-dessous contient les paramètres utilisés par la plate-forme de paiement dans la réponse :

Paramètre

Format

CND

Description

CodeExt

n..10

O

Code d'erreur de CAPN

ApprovalCode

n..6

O

Code d'autorisation de la transaction

TransactionID

ans..48

O

ID de transaction de CAPN

AmountAuth

n..10

M

Montant autorisé dans la plus petite unité de la devise.

Pour les cartes prépayées, ce montant peut être inférieur au montant initialement demandé.

Match

a1

O

Résultat total de la vérification des adresses (American Express via CAPN) : pour les valeurs possibles, voir le manuel Paramètres de correspondance.

cvcmatcha1C

Résultat de la vérification CVC.

Valeurs possibles : M = correspondance, N = pas de correspondance, U = émetteur pas en mesure de traiter la demande


Paiement par batch

Cette section présente les paramètres qui doivent être transmis dans les enregistrements du fichier Batch (Record) pour l'exécution d'un paiement par carte, ainsi que les informations pouvant être contenues dans le fichier de réponse concernant l'état du paiement.

La structure devant être utilisée pour un paiement par carte au sein d'un fichier Batch est comme suit :

HEAD,<MerchantID>,<Date>,<Version>

CC,Authorize,<Amount>,<Currency>,<TransID>,(<refnr>,)<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]

CC,Capture,<Amount>,<Currency>,<TransID>,(<refnr>,)<PayID>,[<FinishAuth,<textfeld1>,<textfeld2>,<approvalcode>]

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>,)<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]

CC,Credit,<Amount>,<Currency>,<TransID>,(<refnr>,)<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>]

CC,CreditEx,<Amount>,<Currency>,<TransID>,(<refnr>,)<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>]

CC,Reverse,<Amount>,<Currency>,<TransID>,(<refnr>,)<PayID>

FOOT,<CountRecords>,<SumAmount>

 

Exemple de différentes versions batch :

Version 1.2 :

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>

Version 1.2.1

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>

Version 1.3 :

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>

Version 1.5 :

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<Zone>


Le tableau ci-dessous présente les différents champs et valeurs utilisés dans l'enregistrement (record) au sein du fichier batch :

Paramètre

Format

CND

Description

RefNran12OC

Le numéro de référence univoque du commerçant, qui sert de référence de remboursement dans le fichier EPA de l'acquéreur. Veuillez noter que sans la livraison de référence propre à la boutique, vous ne pouvez pas lire la transaction EPA ; quant au fichier de règlement supplémentaire, nous ne pouvons pas ajouter les données de paiement supplémentaires.

Notes:

  • Taille fixe de 12 caractères (uniquement des caractères alphabetiques (A..Z, a..z) et numériques (0..9) sont autorisés, pas de caractères spéciaux)
  • Pour AMEX : le champ RefNr est obligatoire

Type

a..11

M

HEAD pour en-tête (header), FOOT pour pied de page (footer) et CC pour carte

Action

a..20

M

Le paramètre Action définit le type de transaction :

Authorize (autorisation)

Capture

Sale

Remboursement

CreditEx (remboursement sans capture préalable; veuillez confirmer cela avec le service Support)

Reverse (annulation)

Amount

n..10

M

Montant indiqué dans la plus petite unité de la devise (par ex. les centimes pour l'euro).

Veuillez contacter notre service d'assistance si vous souhaitez capturer des montants inférieurs à 100 (plus petite unité de la devise).

Currency

a3

M

Code pour la devise, trois caractères DIN / ISO 4217

TransID

an..64

M

ID de la transaction qui doit être unique pour chaque paiement

PayID

an32

M

ID pour cette transaction attribuée par la plateforme de paiement

OrderDesc

ans..127

O

Description des marchandises achetées, des prix unitaires etc.

CCBrand

a..22

C

Réseau auquel appartient la carte de paiement.

Veuillez respecter l'orthographe, Voir le tableau des réseaux des cartes (dans le guide d'intégration de la page de paiement).

CCNr

n..16

C

Numéro de la carte, minimum 12 chiffres sans espaces. Alternativement, vous pouvez transmettre un pseudo-numéro de carte (PCN)

PCNr

n..16

O

Optionnel, vous pouvez également transmettre un pseudo-numéro de carte (PCN) au lieu du vrai numéro de la carte.

CCCVC

n..4

O

Code de vérification de la carte en version 1.3 : les 3 derniers chiffres sur le champ de signature de la carte s'il s'agit de Visa et de MasterCard. 4 chiffres s'il s'agit d'American Express.

CCExpiry

n6

O

Date d'expiration de la carte au format AAAAMM, par ex. 201707.

FinishAuth

ans1

O

Version=1.4 : si vous utilisez le renouvellement d'autorisation, annulez la répétition avec la valeur Y dans le champ FinishAuth dans le cas d'une capture ou d'un crédit. Exemple : vous prélevez le montant d'une livraison partielle. Le reste de la commande ne peut pas être livré. Vous saisissez donc Y dans le champ FinishAuth pour la capture partielle afin que la plateforme de paiement n'autorise pas le montant restant.

RTFa1O

Abonnement à durée et montant fixes

  • Paiement initial : RTF=I
  • Echéances suivantes : RTF=R


Abonnement à durée et montants variables

  • Paiement initial : RTF=E
  • Echéances suivantes : RTF=M

 

La zone d'enregistrement (Record) dans le fichier de réponse pour batch transaction :

HEAD,<MerchantID>,<Date>,<Version>

CC,Authorize,<Amount>,<Currency>,<TransID>,(<refnr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>

CC,Capture,<Amount>,<Currency>,<TransID>,(<refnr>),<PayID>[<textfeld1>,<textfeld2>,<approvalcode>],<Status>,<Code>

CC,AuthSplit,<Amount>,<Currency>,<TransID>,(<refnr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]

CC,Renewal,<Amount>,<Currency>,<TransID>,(<refnr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>

CC,Credit,<Amount>,<Currency>,<TransID>,(<refnr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>],<Status>,<Code>

CC,CreditEx,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>],<Status>,<Code>

CC,Reverse,<Amount>,<Currency>,<TransID>,(<refnr>),<PayID>,<Status>,<Code>

FOOT,<CountRecords>,<SumAmount>

 

Exemple de différentes versions batch :

Version 1.2:

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<Status>,<Code>

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

Version 1.21:

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

Version 1.3:

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

Version 1.5:

CC,Sale,<Amount>,<Currency>,<TransID>,(<refnr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<Zone>,<Status>,<Code>


Le tableau ci-dessous indique les paramètres de réponse que le gestionnaire de fichier Batch (Batch Manager) sauvegarde dans la zone d'enregistrement (Record) pour chaque transaction (les paramètres par défaut non détaillés ici tels que <TransID> ou <refnr>, ainsi que les paramètres de requête sont retournés inchangés et correspondent à l'appel tel que spécifié plus haut) :

 

Paramètre

Format

CND

Description

Action

a..20

M

Le paramètre Action définit le type de transaction comme pour Capture ou Credit – voir ci-dessus.

PayID

an32

M

ID pour cette transaction attribuée par la plateforme de paiement

Status

a..50

M

OK ou FAILED

Code

n8

M

Code d'erreur conformément au fichier Excel des codes de réponse de la plateforme de paiement

PCNr

n..16

C

Le pseudo-numéro de carte est uniquement retourné pour les types de transactions Authorize ou Sale & CreditEx. Le pseudo-numéro de carte commence avec 0 et les 3 derniers chiffres correspondent à ceux du vrai numéro de carte.

 

Gestion des paiements par carte

Capture

Le commerçant peut choisir différentes options de capture :

  • Manuelle
  • Automatique
  • Automatique avec délais personnalisable (de 1 à 696 heures)


En choisissant le mode manuel, il est nécessaire pour le commerçant de valider manuellement chacune des transactions. Le commerçant doit valider la transaction avant 7 jours (délais de garantie des fonds). Les captures manuelles sont possibles via une connexion server-to-server :

En choisissant le mode automatique, la capture se fait automatiquement tous les jours en fin de journée.

En choisissant le mode automatique avec délais personnalisable, le commerçant fixe une durée en heure (de 1 à 696) qui correspond à la fréquence de capture à laquelle il souhaite remettre les transactions en banque.


Capture partielle

Le commerçant peut valider tout ou une partie du montant d’une transaction.

La capture partielle peut se faire :

  • Soit via une connexion server-to-server en valorisant le paramètre « Amount » avec le montant partiel à capturer dans la requête de paiement.
  • Soit via le back-office en sélectionnant la vue détaillée de la transaction où l’utilisateur pourra choisir le montant à capturer ne dépassant pas le montant total de la transaction.


Remarque : pour des raisons de sécurité, la plateforme de paiement rejette toutes les requêtes de paiement avec des erreurs de formatage. Par conséquent, utilisez le type de données approprié pour chaque paramètre.

Le tableau suivant décrit les paramètres de requête de paiement chiffrés :

Paramètre

Format

CND

Description

RefNran..12OC

Le numéro de référence univoque du commerçant, qui sert de référence de remboursement dans le fichier EPA de l'acquéreur. Veuillez noter que sans la livraison de référence propre à la boutique, vous ne pouvez pas lire la transaction EPA ; quant au fichier de règlement supplémentaire, nous ne pouvons pas ajouter les données de paiement supplémentaires.

Notes:

  • Taille fixe de 12 caractères (uniquement des caractères alphabetiques (A..Z, a..z) et numériques (0..9) sont autorisés, pas de caractères spéciaux comme les espaces)
  • Pour AMEX : le champ RefNr est obligatoire
  • Si le nombre de caracètres renseignés est inférieur à 12, alors BNP Paribas complètera, en partant de la gauche, avec des "0" (Exemple : 000018279568)


En cas de capture manuelle, la RefNr doit être identique en autorisation (création du paiement) et la capture.

Si les valeurs sont différentes, la réconciliation financière ne pourra pas être effectuée.

MerchantID

ans..30

M

Identifiant du commerçant attribué par BNP Paribas

PayID

an32

M

Identifiant attribué par la plateforme de paiement pour le paiement

TransID

ans..64


Identifiant de la transaction devant être unique pour chaque paiement

MAC

an64

MM

Code HMAC (Hash Message Authentication Code) avec algorithme SHA-256

Amount

n..10

M

Montant dans l’unité de devise la plus petite (p. ex. centime d’euro).

Contactez l’Assistance si vous voulez capturer des montants inférieurs à 100 (unité de devise la plus faible).

Currency

a3

M

Devise, trois chiffres DIN / ISO 4217

ReqID

ans..32

O

Pour éviter les paiements en double, saisissez une valeur alphanumérique qui identifie votre transaction et ne peut être attribuée qu’une seule fois. Si la transaction est à nouveau soumise avec le paramètre ReqID identique, la plateforme de paiement n’exécute pas le paiement et se contente de retourner le statut de la transaction d’origine. Attention : Plateforme de paiement doit afficher un statut de transaction finalisée pour la première action initiale. Les introductions avec un ReqID identique pour un statut ouvert sont traitées à intervalles réguliers.

FinishAuth

a1

C

Uniquement avec ETM : transmettez la valeur <Y> pour empêcher le renouvellement des autorisations garanties et des montant résiduels à la suite de captures partielles. Veuillez utiliser ce paramètre uniquement si vous utilisez la fonction supplémentaire ETM (Extended Transaction Management).

Textfeld1

ans..30

O

Informations sur le porteur de carte (par exemple : nom)

Textfeld2

ans..30

O

Informations sur le porteur de carte (par exemple : ville)

 

Le tableau suivant décrit les paramètres de réponse de la plateforme de paiement :

Paramètre

Format

CND

Description

RefNran..12OC

Le numéro de référence univoque du commerçant, qui sert de référence de remboursement dans le fichier EPA de l'acquéreur. Veuillez noter que sans la livraison de référence propre à la boutique, vous ne pouvez pas lire la transaction EPA ; quant au fichier de règlement supplémentaire, nous ne pouvons pas ajouter les données de paiement supplémentaires.

Notes:

  • Taille fixe de 12 caractères (uniquement des caractères alphabetiques (A..Z, a..z) et numériques (0..9) sont autorisés, pas de caractères spéciaux comme les espaces)
  • Pour AMEX : le champ RefNr est obligatoire
  • Si le nombre de caracètres renseignés est inférieur à 12, alors BNP Paribas complètera, en partant de la gauche, avec des "0" (Exemple : 000018279568)

MID

ans..30

M

Identifiant du commerçant

PayID

an32

M

Identifiant attribué par la plateforme de paiement pour le paiement ; p. ex. pour référencement dans les fichiers batch

XID

an32

M

Identifiant pour toutes les transactions uniques (autorisation, capture, remboursement) pour un paiement attribué par la plateforme de paiement

TransID

ans..64

M

Numéro de transaction du commerçant

Status

a..50

M

OK ou FAILED (échec)

Description

ans..1024

M

Détails complémentaires dans le cas où le paiement est rejeté. N’utilisez pas la Description, mais le paramètre Code pour l’analyse du statut de transaction !

Code

n8

M

Code d’erreur selon le fichier Excel des codes de réponses de la plateforme de paiement

A noter : Les captures partielles sont également possibles en valorisant le paramètre « Amount » avec le montant partiel à capturer.

 


Annulation

L’annulation permet d’annuler une transaction avant que celle-ci soit remise en banque (capturée, voir paragraphe ci-dessous).

Pour honorer la demande d’annulation, BNP Paribas procède à deux vérifications 

-              Le montant: il est interdit d’annuler un montant supérieur au montant initial de la transaction.

-              Le délai de remise en paiement : le délai est défini au moment de la demande d’autorisation et lorsque ce délai est dépassé la transaction ne peut plus être annulée.

Utilisez l’URL suivante :


Remarque : Pour des raisons de sécurité, la plateforme de paiement rejette toutes les requêtes de paiement avec des erreurs de formatage. Par conséquent, utilisez le type de donnée approprié pour chaque paramètre.

Remarque : Reverse.aspx ne permet pas uniquement d’annuler (reverse) les autorisations, mais toutes les dernières étapes de  ces transactions. Si la dernière transaction était une capture, Reverse.aspx initie l’annulation (reverse) (p. ex. un remboursement). Par conséquent, vous devez faire preuve d’une extrême prudence. Utilisez ce paramètre à vos propres risques. Nous vous recommandons de vérifier le statut de transaction avec Inquire.aspx avant d’utiliser Reverse.aspx.

(Se référer à la documentation « demande de statut » pour des informations supplémentaires sur inquire.aspx)

Le tableau suivant décrit les paramètres de requête de paiement chiffrés :

Paramètre

Format

CND

Description

MerchantID

ans..30

M

Identifiant du commerçant

PayID

an32

M

Identifiant de la plateforme de paiement pour l’identification du paiement

TransID

ans..64

M

Identifiant de la transaction devant être unique pour chaque paiement

Amount

n..10

M

Montant dans l’unité de devise la plus petite (p. ex. centime d’euro).

Contactez l’Assistance si vous voulez capturer des montants inférieurs à 100 (unité de devise la plus faible).


Le montant de l'annulation doit être le même que le montant de l'autorisation. L'annulation partielle n'est pas disponible.

Currency

a3

M

Code de devise, trois chiffres DIN / ISO 4217

MAC

an64

M

Code HMAC (Hash Message Authentication Code) avec algorithme SHA-256

ReqID

ans..32

O

Pour éviter les paiements en double, saisissez une valeur alphanumérique qui identifie votre transaction et ne peut être attribuée qu’une seule fois. Si la transaction est à nouveau soumise avec le paramètre ReqID identique, la plateforme de paiement n’exécute pas le paiement et se contente de retourner le statut de la transaction d’origine. Attention : Plateforme de paiement doit afficher un statut de transaction finalisée pour la première action initiale. Les introductions avec un ReqID identique pour un statut ouvert sont traitées à intervalles réguliers.

Le tableau suivant décrit les paramètres de réponse de la plateforme de paiement :

Paramètre

Format

CND

Description

MID

ans..30

MC

Identifiant du commerçant

PayID

an32

M

Identifiant attribué par la plateforme de paiement pour le paiement ; p. ex. pour référencement dans les fichiers batch

XID

an32

M

Identifiant pour toutes les transactions uniques (autorisation, capture, remboursement) pour un paiement attribué par la plateforme de paiement

TransID

ans..64

M

Numéro de transaction du commerçant

Status

a..50

M

OK ou FAILED (échec)

Description

ans..1024

M

Détails complémentaires dans le cas où le paiement est rejeté. N’utilisez pas la Description, mais le paramètre Code pour l’analyse du statut de transaction !

Code

n8

M

Code d’erreur selon le fichier Excel des codes de réponses de la plateforme de paiement


Remboursement

Le remboursement permet de recréditer un client qui a précédemment été débité (produit non parvenu, indisponible, détérioré, retour… etc.). Le compte du client est crédité du montant remboursé et le compte du commerçant est débité de ce même montant. Le commerçant a la possibilité de rembourser un client jusque dans les 12 mois qui suivent sa commande. Il peut faire autant de remboursements partiels qu'il souhaite tant qu'il ne dépasse pas ce délai de ces 12 mois.

Toute tentative de remboursement sur une transaction impayée sera refusée.

Les remboursements sont possibles via une connexion serveur-to-serveur. La plateforme de paiement autorise les remboursements liés à une capture précédemment activée par la plateforme de paiement, et autorise les commerçants à procéder à des remboursements sans transaction de référence. Cette section décrit l’exécution des remboursements avec des transactions de référence. Si vous vous reportez à une capture pour un remboursement, le montant du remboursement est limité au montant de la capture précédente.

Pour procéder à un remboursement avec une transaction de référence, utilisez l’URL suivante :


Remarque : pour des raisons de sécurité, la plateforme de paiement rejette toutes les requêtes de paiement avec des erreurs de formatage. Par conséquent, utilisez le type de donnée approprié pour chaque paramètre.

Le tableau suivant décrit les paramètres de requête de paiement chiffrés :

Paramètre

Format

CND

Description

RefNran12OC

Le numéro de référence univoque du commerçant, qui sert de référence de remboursement dans le fichier EPA de l'acquéreur. Veuillez noter que sans la livraison de référence propre à la boutique, vous ne pouvez pas lire la transaction EPA ; quant au fichier de règlement supplémentaire, nous ne pouvons pas ajouter les données de paiement supplémentaires.

Notes:

  • Taille fixe de 12 caractères (uniquement des caractères alphabetiques (A..Z, a..z) et numériques (0..9) sont autorisés, pas de caractères spéciaux comme les espaces)
  • Pour AMEX : le champ RefNr est obligatoire
  • Si le nombre de caracètres renseignés est inférieur à 12, alors BNP Paribas complètera, en partant de la gauche, avec des "0" (Exemple : 000018279568)

MerchantID

ans..30

M

Identifiant du commerçant attribué par BNP Paribas

PayID

an32

M

Identifiant attribué par la plateforme de paiement pour le paiement

TransID

ans..64

M

Identifiant de la transaction devant être unique pour chaque paiement

MAC

an64

M

Code HMAC (Hash Message Authentication Code) avec algorithme SHA-256

Amount

n..10

M

Montant dans l’unité de devise la plus petite (p. ex. centime d’euro).

Contactez l’Assistance si vous voulez capturer des montants inférieurs à 100 (unité de devise la plus faible).

Currency

a3

M

Devise, trois chiffres DIN / ISO 4217

OrderDesc

ans..768

O

Numéro de référence du commerçant

ReqID

ans..32

O

Pour éviter les paiements en double, saisissez une valeur alphanumérique qui identifie votre transaction et ne peut être attribuée qu’une seule fois. Si la transaction est à nouveau soumise avec le paramètre ReqID identique, la plateforme de paiement n’exécute pas le paiement et se contente de retourner le statut de la transaction d’origine. Attention : Plateforme de paiement doit afficher un statut de transaction finalisée pour la première action initiale. Les introductions avec un ReqID identique pour un statut ouvert sont traitées à intervalles réguliers.

Textfeld1

ans..30

O

Informations sur le porteur de carte (par exemple : nom)

Textfeld2

ans..30

O

Informations sur le porteur de carte (par exemple : ville)

 

Le tableau suivant décrit les paramètres de réponse de la plateforme de paiement :

Paramètre

Format

CND

Description

RefNran12OC

Le numéro de référence univoque du commerçant, qui sert de référence de remboursement dans le fichier EPA de l'acquéreur. Veuillez noter que sans la livraison de référence propre à la boutique, vous ne pouvez pas lire la transaction EPA ; quant au fichier de règlement supplémentaire, nous ne pouvons pas ajouter les données de paiement supplémentaires.

Notes:

  • Taille fixe de 12 caractères (uniquement des caractères alphabetiques (A..Z, a..z) et numériques (0..9) sont autorisés, pas de caractères spéciaux comme les espaces)
  • Pour AMEX : le champ RefNr est obligatoire
  • Si le nombre de caracètres renseignés est inférieur à 12, alors BNP Paribas complètera, en partant de la gauche, avec des "0" (Exemple : 000018279568)

MID

ans..30

M

Identifiant du commerçant

PayID

an32

M

Identifiant attribué par la plateforme de paiement pour le paiement ; p. ex. pour référencement dans les fichiers batch

XID

an32

M

Identifiant pour toutes les transactions uniques (autorisation, capture, remboursement) pour un paiement attribué par la plateforme de paiement

TransID

ans..64

M

Numéro de transaction du commerçant

Status

a..50

M

OK ou FAILED (échec)

Description

ans..1024

M

Détails complémentaires dans le cas où le paiement est rejeté. N’utilisez pas la Description, mais le paramètre Code pour l’analyse du statut de transaction !

Code

n8

M

Code d’erreur selon le fichier Excel des codes de réponses de la plateforme de paiement



Oops, it seems that you need to place a table or a macro generating a table within the Table Filter macro.

The table is being loaded. Please wait for a bit ...

LogoNomCatégorieRégion d'émissionPaysDevises

AlipayWalletAPACFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceAUD ; CAD ; EUR ; GBP ; HKD ; SGD ; USD

American ExpressCarteInternationalFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; CHF ; USD ; AUD ; CAD ; DKK ; JPY ; NOK ; PLN ; SEK

Apple PayWalletInternationalFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; CHF ; DKK ; USD ; CAD ; JPY ; NOK ; SEK ; PLN ; AUD

BancontactCarteEuropeBelgiqueEUR

BillPayPrélèvementEuropePays-Bas ; Allemagne ; Suisse ; AutricheEUR

Bimpli ; ApétizPrépayéFranceFranceEUR

CBCarteFranceFranceEUR

Cetelem Full CBBNPLEuropeFranceEUR

Cetelem PrestoBNPLEuropeFranceEUR

Chèque DéjeunerPrépayéFranceFranceEUR

Chèque Vacances Connect ; ANCV ConnectPrépayéFranceFranceEUR

CofidisBNPLEuropeFranceEUR

Consors FinanzBNPLEuropeAllemagneEUR

DinersCarteInternationalFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; CHF ; DKK ; USD ; CAD ; JPY ; NOK ; SEK ; PLN ; AUD

DiscoverCarteInternationalFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; CHF ; DKK ; USD ; CAD ; JPY ; NOK ; SEK ; PLN ; AUD

EasyCredit (Ratenkauf)BNPLAllemagneAllemagneEUR

EPSVirementEuropeAutricheEUR

Finnish eBankingVirementEuropeFinlandeEUR

FLOABNPLEuropeFrance ; Italie ; Belgique ; Espagne ; Allemagne ; Portugal EUR

GiropayVirementEuropeAllemagneEUR

Google PayWalletInternationalFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; CHF ; DKK ; USD ; CAD ; JPY ; NOK ; SEK ; PLN ; AUD

iDealVirementEuropePays-BasEUR

InstaneaVirementFranceFranceEUR

JCB ; Japan Credit BureauCarteAPACFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; CHF ; DKK ; USD ; CAD ; JPY ; NOK ; SEK ; PLN ; AUD

KlarnaBNPLEuropeFrance ; Italie ; Belgique ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Suède ; Danemark ; Norvège ; FinlandeEUR ; GBP ; CHF ; DKK ; USD ; CAD ; NOK ; SEK ; PLN

MastercardCarteInternationalFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; CHF ; DKK ; USD ; CAD ; JPY ; NOK ; SEK ; PLN ; AUD

MobilePayWalletEuropeDanemarkEUR

MultibancoVirementEuropePortugalEUR

MyBankVirementEuropeItalieEUR

Sodexo Benefits and Rewards Services becomes Pluxee, the new employee ...

Pluxee (ex Pass Sodexo)BNPLEuropePays-Bas ; Allemagne ; Suède ; Danemark ; Norvège ; Finlande EUR

PaypalWalletInternationalFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; USD ; CAD

PaysafecardPrépayéInternationalFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceAUD ; CAD ; CHF ; EUR ; GBP ; NOK ; PLN ; RON ; SEK ; USD

Przelewy24 ; P24VirementEuropePolognePLN

RatePayVirementEuropeAllemagneEUR

SofincoBNPLFranceFranceEUR

TrustlyVirementEuropeBelgique ; Royaume-Uni ; Pays-Bas ; Espagne ; Allemagne ; Autriche ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; LettonieEUR

Union Pay International ; UPICarteAPACFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; USD

VisaCarteInternationalFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; CHF ; DKK ; USD ; CAD ; JPY ; NOK ; SEK ; PLN ; AUD

WeChat Pay
WalletAPACFrance ; Italie ; Belgique ; Luxembourg ; Royaume-Uni ; Irlande ; Pays-Bas ; Espagne ; Allemagne ; Portugal ; Suisse ; Autriche ; Slovaquie ; Slovénie ; Suède ; Danemark ; Norvège ; Finlande ; Estonie ; Lituanie ; Lettonie ; GrèceEUR ; GBP ; USD

Disponibilité : fin 2024

Assistance Axepta BNP Paribas


Notre service d'assistance est disponible par mail et téléphone de 8h30 à 18h, du lundi au vendredi.

Vous pouvez les contacter à l'adresse bnpparibas@computop.com ou au 0 825 07 27 47 (Service 0,15€ / min. + prix appel) en indiquant votre identifiant marchand (MID) et le cas échéant, les éléments complémentaires indiqués ci-dessous.


Si votre question concerne le Back-Office :
  • Nom d'utilisateur
  • Fonctionnalité utilisée


Si votre question concerne une ou des transactions :

  • Les informations permettant d'identifier vos transactions

MID (Ayant effectué la transaction)

TransID

PayId

RefNr

Date/Heure de la transactionMontant

BNP_DEMO_AXEPTA

TID-20480457802137656

dda7fd92e1f54ac388ded9f55eaftr78

dxmnq0ljk0uu

****
  • Le message d'erreur obtenu
  • Une capture d'écran (optionnel)


Si votre intégration est sous CMS :

  • Le CMS et la version utilisée ainsi que la version du plugin Axepta
  • Une capture d'écran (optionnel)



Où trouver mon payID ?

Vous pouvez consulter la section : Comment retrouver le PayId d'une transaction ?

L'erreur Time-out provient généralement de :

  • La structure ou le format de la clé HMAC
  • La structure ou le format de la clé Blowfish
  • La structure ou le format de votre clé d’activation - dans le cas où vous utilisez un CMS


HMAC

La clé HMAC est une chaîne de 32 caractères composée des chiffres, de lettres et de caractères spéciaux.

La clé HMAC ne doit pas contenir d'espace, veillez à vérifier le dernier caractère de votre clé.


Blowfish

La clé Blowfish est une chaîne de 16 caractères composée des chiffres, de lettres et de caractères spéciaux.

La clé Blowfish ne doit pas contenir d'espace, veillez à vérifier le dernier caractère de votre clé.


Outil de tests

Notre outil de test vous permettra de tester :

  • le chiffrement Blowfish
  • le déchiffrement Blowfish
  • le calcul du MAC
  • L'encodage Base64 pour les objets JSON

 Axepta Platform // Simple Test Tools (paytest.info)


Clé d'activation

Vous trouverez tous les détails concernant la clé d'activation sont disponibles dans la section : Format de la clé d'activation

MultiExcerpt named Axepta EN was not found -- Please check the page name and MultiExcerpt name used in the MultiExcerpt-Include macro


What should I do when I receive my AXEPTA BNP PARIBAS access data?


First, you will receive a welcome email from our support team AXEPTA BNP Paribas (bnpparibas@computop.com). This email will inform you that you will receive, in few minutes, an encrypted email containing your confidential access data.



The encrypted email looks as follows: (this email contains a reference number, see below)

How to access to the content of the encrypted email ?


  1. Right clic on the attached file (original_email.zip).
  2. Save it in the location of your choice on your computer.



3. Go to the, previously saved, file and right clic on 7-ZIP then clic on Extract here

Note:  If you don’t have 7-ZIP on your computer, use an equivalent app like WINZIP.



4. A window will appear asking for a password. Enter the password that you’ve received on your phone from BNP_Paribas.



Note : If you have many shops, the message on your phone contains a reference number mentioned in the encrypted email.



5. Once the password entered, a file called «BodyText » will appear in your folder (format .htm). Double-clic on it and open it with your preferred browser (Firefox, Chrome, Edge, Safari…).


You will finally have access to a page containing your access data:

  • Merchant ID
  • Blowfish encryption key
  • HMAC key


These 3 data will allow you to integrate the AXEPTA BNP Paribas payment solution.



6. Finally, you will receive an email containing the summary of all your MIDs and how to use each one of them :

  • The Master MID will give you a global view of your activity on the different accounts you have (Test and Prod). To do so, log on to the Axepta Backoffice using this MasterMID and the password received (https://backoffice.axepta.bnpparibas/login.aspx). Please note that the MasterMID cannot be used to carry out transactions.
  • The Test MID will be used to perform tests without the transactions being banked. You will remain in a test environment.
  • The Prod MID will allow you to access the production environment. Please note that your MID will go into production mode and your transactions will be banked when your account configuration is finalised.

You will also find your test cards that you can use during the test phase. 

Do you use a BNP Paribas AXEPTA plugin?

You can benefit from our AXEPTA BNP Paribas plugins for the following CMS : Prestashop, WooCommerce, Magento. Please find bellow the links to purchase our plugins :

  • Prestashop

https://addons.prestashop.com/fr/paiement-carte-wallet/50069-axepta-bnp-paribas.html

https://shop.quadra-informatique.fr/modules-ecommerce-cms/89-19-axepta-prestashop.html#/6-option_tranquillite_garantie_maintenance-sans_option_de_mise_a_jour_du_modu

  • WooCommerce

https://shop.quadra-informatique.fr/modules-ecommerce-cms/88-22-axepta-woocommerce.html#/6-option_tranquillite_garantie_maintenance-sans_option_de_mise_a_jour_du_module

  • Magento

Axepta Magento 2 (quadra-informatique.fr)


Once the plugin is purchased, you need to send the invoice (proof of purchase) to BNP Paribas assistance ( bnpparibas@computop.com ) and receive the activation key that allows you to activate and configure the plugin.

Installation and configuration guides for the plugins are available via the following links :


About Batch files

Batch Manager allows you to transmit payment transactions as files. This file transfer can be done:

  • Manually via the Axepta back-office (Please refer to the Back-office document)
  • Automatically via the secure file transfer protocol (sFTP)

In this process you assemble transaction data such as the transaction ID, amount and currency in a batch file that you will later transmit to the payment platform. The payment platform then makes the payments and saves the transaction status in the batch file. After processing, the merchant can access to the batch file with the details on the transaction status via a download.

SFTP access for Batch file transfer must be requested at the BNP Paribas Helpdesk.

Batch files must be correctly structured to enable the payment platform to process them.



Name of the Batch files

The name of a new batch file begins with the letter T to indicate the file was originally transmitted by you. This is followed by the Date of the submission in reverse order: e.g. 20160112. This is followed by a three-figure Counter, which starts at 001 and the MerchantID issued by BNP. If you submit several files on one day, you need to set the counter to 002, 003, 004 etc. The file must end in .DAT.

The name of a batch file comprises four components.

File name for manual transmission via Axepta Backoffice:

<Phase><Date><MerchantID><Counter>.dat

File name for automated FTP transmission:

<Phase><Date><Counter><MerchantID>.dat

(warning) Please pay attention that file name is different for Axepta Backoffice and SFTP-transmission.


Component

Description

Phase

T=Transferring, P=Processed

Date

Date in format YYYYMMDD (Year, Month, Day)

Counter

Three digits, counts up daily from 001, 002 to 999

MerchantIDMerchantID

 

The processing of the batch file goes through several phases which are indicated within the file name: The original file sent by the merchant starts with the character T (for Transferred). After processing, the batch file is suffixed with the letter P (for Processed).

If a merchant with the MerchantID “MerchantID” submits two batch files on 12/01/2016 via Axepta Back Office, these two files are named as follows:

T20160112001MerchantID.dat
T20160112002MerchantID.dat

Notice: After you have transmitted the batch file, the processing of the transactions begins. During this processing the file is prefixed with W (for Waiting). If the T batch file is submitted via FTP/sFTP for processing, the phase must be renamed W after the upload by the merchant system. The processing only starts after this step.

W20160112001MerchantID.dat

W20160112002MerchantID.dat

Once all payment transactions have been carried out, the payment platform marks the processed files, which now contain the details of the transaction status, with the initial letter P for processed, which you can access in the batch view of BNP Paribas Back Office via download.

P20160112001MerchantID.dat

P20160112002MerchantID.dat


FTP transfer of Batch files

The payment platform allows you to transfer batch files automatically via FTP (File Transfer Protocol). To transfer a batch file via FTP/sFTP, proceed as follows:

  1. Save the transaction data in a formatted batch file
  2. Encrypt the batch file
  3. Transfer the batch file
  4. Change of the phase after the upload (T → W)
  5. Retrieve the batch file after processing
  6. Check status of transactions


Encryption of the Batch file

For security reasons, batch files must be encrypted before the FTP/sFTP transmission. To guarantee maximum security the payment platform uses asymmetric encryption with PGP (Pretty Good Privacy). Encryption with GPG (GNU Privacy Guard) is also possible. The saved file must, however, have the extension “.PGP”, otherwise no processing is possible.


If several batch files are to be submitted, for example for a Merchant with the MerchantID MerchantID on the 12/01/2016, then these two files are named as follows (see also Name of the batch files):

T20160112001MerchantID.dat
T20160112002MerchantID.dat

 

The recognized high security of PGP-encryption is based on a process with two keys, a private key and a public key. BNP Paribas provides you with a public key for encryption of your batch file. The encrypted batch file can then be decrypted only with BNP Paribas's secret private key.

You can also generate public and a private key for your company. The payment platform encrypts the processed batch file with your public key. The file can then be read only with your secret private key.


Format of Batch files

The content of a batch file consists of a header, several records and a footer. Each entry in the file is one row which is completed with CRLF (Enter key). The values within a line are comma-separated. The format is thus also described as the CSV format (Comma Separated Values).

The following sections describe the format of the batch file which you transmit to the payment platform and the response-file, in which the payment platform saves the results of the payments.


Format of submitted Batch files

Introduction

The example below shows the components which make up the content of a batch file.

Notice: Please note that the batch file may not include any empty rows either at the start or the end of the file. The empty rows in the listings are for ease of reading only.

Notice: Please note that text parameters like "Reason" or "OrderDesc" may not contain commas.

Notice: In Batch versions 2.x there is another field for <MID>. Thereby it is possible for a MasterMID to submit transactions for SubMID.


Header

Type,MerchantID,Date,Version

 

Record

Type,Action,<Amount>,<Currency>,<TransID>,<Data depends on Action>

The data to be used depend on Batch version and Action. For more details, please see section "Batch calls and answers" below.


Footer

Type,CountRecords,SumAmount

 

The description of the individual fields and values used within the data set (Record) within the batch file you will find in the respective chapter within the manual of the individual payment method.

Header and Footer

The general parameters for transfer within Header and Footer explain the following table:

Parameter

Format

CND

Description

Type

a..11

M

HEAD for Header, FOOT for Footer, and for example CC for card. The field need not contain 11 digits.

MerchantID

ans..30

M

Merchant ID provided by BNP Paribas

Date

dttm8

M

Date of file-production in format YYYYMMDD

Version

an6

M

The used batch version determines which optional parameters are used additionally. The possible batch versions in each case differ depending on the payment method and executed action. You will find the possible versions within the batch chapter of the respective payment method.

CountRecords

n..5

M

Number of submitted Records without Header or Footer

SumAmount

n..12

M

Total of all Amounts in smallest currency unit, e.g. cents in the case of euro’s in accordance with currency table. Please contact the helpdesk, if you want to capture amounts < 100 (smallest currency unit).

Record


This section describes the parameters which must be transferred within the data set (Record) for executing a credit card payment and which information can be found within the response file about the payment status.

Notice: Within Batch process not all functions of online interface are available.

For Batch calls there must be considered batch versions, from which optional parameters depend. All version designations starting with „2.“ pertain calls for a group of enterprises. That means within a batch file for a particular MerchantID can be transferred transactions for other merchants with a separate Sub-MID.


Operations

Following table gives an overview of all batch versions that are possible for a specific action and their specialities:


Authorize

1.2 / 2.2

with textfeld1, textfeld2, RTF, cardholder, transactionID, schemeReferenceID

 

1.21 / 2.21

with textfeld1, textfeld2, RTF, approvalcode, cardholder, transactionID, schemeReferenceID

 

1.3 / 2.3

with CVC, transactionID, schemeReferenceID

 

1.5 / 2.5

with CVC, Zone

Capture

1.2 / 2.2

with textfeld1, textfeld2

 

1.21 / 2.21

with textfeld1, textfeld2, approvalcode

 

1.4 / 2.4

with stop of authorisation renewal (FinishAuth)

CaptureEx

1.3 / 2.3

with CVC

Credit

1.2 / 2.2

with textfeld1, textfeld2

 

1.21 / 2.21

with textfeld1, textfeld2

 

1.4 / 2.4

with stop of authorisation renewal (FinishAuth)

CreditEx

1.2 / 2.2

with textfeld1, textfeld2

 

1.21 / 2.21

with textfeld1, textfeld2

 

1.3 / 2.3

with textfeld1, textfeld2

Sale

1.2 / 2.2

with textfeld1, textfeld2, RTF, cardholder, transactionID, schemeReferenceID

 

1.21 / 2.21

with textfeld1, textfeld2, RTF, approvalcode, cardholder, transactionID, schemeReferenceID

 

1.3 / 2.3

with CVC, textfeld1, textfeld2, transactionID, schemeReferenceID

 

1.5 / 2.5

with CVC, Zone

Reverse

1.x / 2.x

Standard version


Description of the possible batch versions


The structure for a credit card payment within a Batch file to be submitted is the following:

HEAD,<MerchantID>,<Date>,<Version>
CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]
CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,[<FinishAuth,<textfeld1>,<textfeld2>,<approvalcode>]
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]]
CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>]
CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>]
CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>
FOOT,<CountRecords>,<SumAmount>


Versions

Example for batch versions:
Version 1.2

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>


Version 1.21

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>


Version 1.3

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>


Version 1.5

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<Zone>


Examples

Examplefor Master MID function:

HEAD,[Master]MerchantID,Date,2.x
Type,Action,[Slave]MID,Amount,Currency,TransID,Data (depends on Action)
FOOT,CountRecords,SumAmount


The following example is a batch file for the capture of three card transactions to the value of 1.00 and 2.00 euros. For the first payment the merchant system supplies the reference number 123456 but no reference numbers are supplied for the second and third:

HEAD,MerchantID,20160112,1.2


CC,Sale,100,EUR,1567890,123456,MasterCard,5490011234567890,200506,Your order from Jan. 4.

CC,Sale,100,EUR,1567891,,MasterCard,5490011234567890,200506,Your order from Jan. 4.

CC,Sale,200,EUR,10202280,,VISA,4907621234567890,200504,Your order from Jan. 4.


FOOT,3,400

 

Fields

The following table describes the individual fields and values used within the data set (record) in the batch file:


Parameter

Format

CND

Description

Type

a..11

M

HEAD for Header, FOOT for Footer, CC for credit card

Action

a..20

M

The parameter Action defines the type of transaction:

Authorize (authorisation)

Capture

Sale

Credit

CreditEx (credit note without previous capture; please agree this with Axepta Helpdesk beforehand)

Reverse (cancellation)

Amount

n..10

M

Amount in the smallest currency unit (e.g. EUR Cent). Please contact the Axepta Helpdesk, if you want to capture amounts <100 (smallest currency unit).

Currency

a3

M

Currency, three digits DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: A1 Currency table EN

PayID

an32

M

ID assigned by Platform for the payment, e.g. for referencing in batch files as well as for capture or credit request.

TransID

ans..64

M

TransactionID which should be unique for each payment.

Please note for some connections the different formats that are given within the specific parameters.

RefNr

an..12

M

Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional BNP settlement file (CTSF) we cannot add the additional payment data.

OrderDesc

ans..127

O

Description of purchased goods, unit prices etc.

CCBrand

a..22

C

Credit card brand.

Please note the spelling! According to table of credit card brands!

CCNr

n..16

C

Credit card number at least 12-digit, numerical without spaces. You can optionally transmit also a pseudo card number (PCN)

PCNr

n16

O

Pseudo Card Number: Random number generated by Platform which represents a genuine credit card number. The pseudo card number (PCN) starts with 0 and the last 3 digits correspond to those of the real card number. You can use the PCN like a genuine card number for authorisation, capture and credits.

PCNr is a response value from Platform and is sent as CCNr in Request or part of card-JSON

CCExpiry

n6

OC

Optional in combination with PCNr: Expiry date of the credit card in the format YYYYMM (202207).

CCCVC

n..4

O

Card verification number in Version 1.3: In the case of Visa and MasterCard the last 3 numbers on the signature strip of the credit card. 4 numbers in the case of American Express.

FinishAuth

ans1

O

Version=1.4: If using the authorisation renewal, cancel repeat with the value Y in the field FinishAuth in the case of Capture or Credit. Example: You capture a partial delivery. The rest of the order cannot be supplied. You therefore enter Y in the FinishAuth field for Part-capture so that the Platform does not authorise the remaining amount. Please note for this also the following section about Cancel authorisation renewals.

RTFa1O

Subscription with fxed amount and duration

  • Initial payment : RTF=I
  • Next subscriptions : RTF=R


Subscription with variable amount and duration

  • Initial payment : RTF=E
  • subsequent payment : RTF=M


Description of fields within the record for Batch files




Format of Batch response files

During the processing of the transactions the Batch Manager saves the transaction status to the batch file. To this end two fields, Status and Code, are added to the transaction entries in the Record area:

Introduction

CC,Capture,<Amount>,<Currency>,<TransID>,<RefNr>,<PayID>,<Status>,<Code>


Notice: The return of optional parameters in the response file generally occurs only if these were included in the submitted file. Generally, no shipment information is given in the response file. If you need this data again, please read this data from the corresponding Notify.

The particular response parameters which Batch manager stores in the record section for each transaction you will find in the batch chapter for the respective payment method.


Record

The record area within the response file for Batch transactions looks as follows:

HEAD,<MerchantID>,<Date>,<Version>
CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>
CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[<textfeld1>,<textfeld2>,<approvalcode>],<Status>,<Code>
CC,AuthSplit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]
CC,Renewal,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>
CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>],<Status>,<Code>
CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>],<Status>,<Code>
CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<Status>,<Code>
FOOT,<CountRecords>,<SumAmount>

 

Versions

Example for batch versions:
Version 1.2

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<Status>,<Code>
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code>


Version 1.21

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code>


Version 1.3

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>,<Status>,<Code>


Version 1.5

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<Zone>,<Status>,<Code>



Fields

The following table describes the response parameters which the Batch Manager saves in the Record area for each transaction (standard parameters not explained here, such as <TransID> or <RefNR> and request parameters are returned unchanged and correspond to the call as specified before):

Parameter

Format

CND

Description

Action

a..20

M

The parameter Action defines the type of transaction like capture or credit – see above.
PayID

an32

M

ID assigned by Platform for the payment, e.g. for referencing in batch files as well as for capture or credit request.

Status

a..50

M

OK or FAILED

Code

an8

M

Error code according to Platform Response Codes (A4 Error codes)

PCNr

n..16

C

The Pseudo Card Number is only returned in the case of transaction types Authorize or Sale & CreditEx. It starts with 0 and the last 3 digits correspond to those of the real card number.


Description of result parameters within the record for Batch files

Batch error codes

From Version 3.0, the payment platform supports detailed error codes. These are eight-digit, hexadecimal codes. The structure and the meaning of the Error codes are described here on the basis of the following example:

2 105 0014


The first digit describes the degree of severity of the error. All values greater than 0 indicate warnings or errors.

Notice: An error code doesn’t necessary mean that the payment platform or the merchant system has suffered a technical error. The payment platform also generates an error code if a transaction has failed because the bank regular refuses a payment.

The 2nd to 4th digits of the error code describe the error category. The error categories relate to encryption (001) and format errors (010) and the details of payment methods, initiated in the case of cards (100) through direct debits (110) to Cash&Go (140).

The 5th to 8th digits of the error code give an indication of the error details. Details include instructions on configuration problems such as missing TerminalIDs (0047) and failures at the card holder's bank computing centre (121) but also standard refusals of card payments based on expired cards (110) or declined messages (0100).

Notice: Error-free transactions, for reasons compatibility with Version 2.1, are not characterized by eight but by a zero 0.

You can find a full list of the payment platform’s error codes in a separated excel-file provided to you.


Card payments integration

General information about card payments

Axepta BNP Paribas's payment platform processes all major cards and currencies worldwide. Card data is protected against unauthorized access by TLS encryption. Additional security functions are integrated fraud prevention and risk management. Our standardized settlement files guarantee a straightforward reconciliation processes in your accounting.

Verified by Visa and MasterCard SecureCode secure your payment claim by password validation if a customer disputes the payment later. American Express SafeKey also uses the 3D-Secure technology, which means that the card holder must confirm their identity with an authentication feature.

Transaction processing can be made via

  • Payment platform forms
  • Server-to-server connection
  • Batch transfer


Merchants benefit from authentication with 3D Secure because the card schemes provide a liability shift.

From a technical perspective 3D Secure is an authentication process which precedes the payment: Once the card data has been entered, the payment platform checks the identity of the card holder and does not process the payment until the authentication is done.

For further steps it is important to know if the card connection is made via form interface or via Server-to-Server connection. In the first case the payment platform form assumes the further authentication process, with Server-to-Server connection the merchant has to manage the authentication through a separate interface.


Payment page form & card's date are hosted by BNP Paribas (payssl.aspx)

Chart of process flow



Process of a transaction with 3D Secure

  • The customer selects the card payment method in the shop and enters the card information.
  • The payment platform receives the data and checks, via a connection to the scheme (Visa, MasterCard, Diners, JCB or American Express) whether this card is registered for Verified, SecureCode, Diners ProtectBuy, JCB-Card J/Secure or SafeKey. If the card is not registered a card payment is carried out with TLS.
  • With that the transaction gets a flag which identifies payments with 3D Secure. This marking tells the Acquiring Bank that the transaction is using 3DS authentication and a secured payment claim is obtained based on the Liability Shift in case the card holder disputes the payment.
  • The payment platform opens a new browser window which connects the customer to its bank. In this window the customer enters the password received by his bank.

If the password is correct, the payment platform obtains a confirmation (as signature). Only after confirmation does the payment platform start the payment and send the transaction with the signature to BNP Paribas.

Notice: Please notice that in case of Fallback to 3-D Secure 1.0 the URLSuccess or URLFailure is called with GET. Therefore your systems should be able to receive parameters both via GET and via POST.


Payment request

In order to make a card payment via the payment platform form, go to the following URL:

 

This section explains the parameters which are the same for each connection. The second table explains all response parameters which are also the same for all card connections.

Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.


All information about payssl integration are available in the section Axepta Credit Card Form (payssl.aspx)

To adapt the layout of the SSL-page to your shop you can use unencrypted parameters, all details available in the section Customize checkout experience


Payment page form is hosted by the merchant & card's data are hosted by BNP Paribas (paynow.aspx)

Same 3DS Process as for payssl.aspx.

Silent order post links the benefits of the payment platform forms and Server-to-Server connections: AS opposed to the payment platform form, where the form is loaded from the payment platform server by calling payssl.aspx, the Silent order post form has to be provided by the merchant’s system. The form uses the same parameters as described here below.

In contrast to the payment platform form, the parameters are not forwarded as URL parameters as is the case when calling the payssl.aspx, but as form input parameters.


Payssl.aspx

Paynow.aspx

payssl.aspx?MerchantID=[mid]&Len=[len]&Data=[data]

<form action=paynow.aspx>

<input type="hidden" name="MerchantID" value=[mid]>

<input type="hidden" name="Len"        value=[len]>

<input type="hidden" name="Data"       value=[data]>

:

</form>


The card data must be transmitted to paynow.aspx with the following parameters:

Parameter

Format

CND

Description

CCNr

n..16

M

card number at least 12-digit, numerical without spaces

CCCVC

n3

O

Card verification number: The last 3 digits on the signature strip of the card

CCExpiry

n6

M

Expiry date of the card in the format YYYYMM, e.g. 201807

CCBrand

a..22

M

Designation of card brand.

Please note the spelling! According to table of card brands


After the customer has entered his card data, the payment data is forwarded to the Silent order post page, where the further payment processing takes place via 3D-Secure. The form details must be directly forwarded to the Silent order post page and may not be transmitted to the merchant’s system! Also, no PCI-relevant data may be transmitted to the Silent order post page as additional input parameters!

Notice: Please note, that automatic retry attempts at the payment platform must be deactivated when using the Paynow.aspx. The background is that at a retry attempt, the payment platform cannot send back the customer to the previously used special shop form. Please contact the BNP Paribas Support to deactivate the retry attempts.



Payment page form & card's data are hosted by the merchant (Server-to-Server)

Chart of process flow via Server-to-Server


Process of a transaction with 3D Secure via Server-to-Server connection

To carry out authentication, the payment platform connects the card holder to his bank, which confirms the identity. A payment process with Verified by Visa or MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure or American Express SafeKey comprises two steps: authentication and payment.

In the next steps, there are two different cases in which the payment platform responds:


  • Case 1: card registered for a 3D Secure system with a pop-up payment page

If the card is registered for Verified or SecureCode, ProtectBuy, J/Secure or SafeKey, the payment platform returns the socket-connection HTML source code with a JavaScript function. This JavaScript function creates the connection to the bank with which the customer is authenticated by entering its password into a popup-window. The HTML source code with the JavaScript function Initiate3DSec() which the payment platform sends to the shop must be embedded in the response page which the shop displays in the customer's browser.

Notice: Please note that the use of a popup window can lead to problems with popup blockers in the customer's browser. Therefore case 2 describes an alternative in the form of an iFrame variant.

The following example shows a response page in which the HTML code is embedded:

<HTML>

<HEAD>

<META http-equiv=Content-Type content="text/html; charset=unicode">

       <SCRIPT language="javascript">

<!--

<Response excerpt from request: HTML with JavaScript>

       //-->

       </script>

       </HEAD>");

       <BODY onload="javascript:Initiate3DSec();">

<table><tr>

<td align="center"><font face="Verdana" size="-1"><b>Please identify yourself with 3D Secure!</b></font></td>

</tr></table>");

</BODY>

</HTML>

 

Notice: You can also use this code if you only want to verify the identity of the card holder without making a card payment. Our Support team can set your account in a way that the payment platform can carry out just the authentication with Verified or SecureCode, ProtectBuy, J/Secure or SafeKey without payment (Authentication Hosting).

After the customer has been authenticated with its bank, the bank's Access Control Server (ACS) requests the TermURL in the shop. In the case of this Request the ACS transfers the following parameters via GET (QueryString) to the TermURL of the shop: MID, PayID and TransID. The PARes parameter is transferred via POST.

Notice: The PAResponse parameter must be URL encoded but not Blowfish-encrypted since the content can include special characters.

The parameter must be transferred via POST to the following URL:

Notice: If you forward the PARes and MID of the ACS parameters please use the specified parameter name MerchantID, PAResponse for the direct3d.aspx page.


  • Case 2: card registered for a 3D Secure system with an iFramed payment page

Alternatively to the popup window, the card holder can also carry out authentication with the bank in an iFrame variant; this avoids difficulties with popup blockers in the customer's browser. Provided the card is registered on the Directory Server, the payment platform returns the following parameters via the socket connection.

If the card is registered with the server (Directory Server), the payment platform returns following parameters via socket connection.

Parameter

Format

CND

Description

ACSURL

ans..

C

Only in the case of registered cards: URL of the Access Control Server of the card issuer with attached request parameters (not URL-encoded!)

PaReq

ans..

M

Payer Authentication Request, which must be URL-encoded.

MD


M

Merchant Data is an empty value, which must be transferred for compatibility reasons

TermURL

ans..

M

Shop return address


Example of correct using of the ACSURL and TermURL :

acsurl=a?b=c&d=e&pareq=f&termurl=g?PayID=h&TransID=i&MID=j

ACSURL: a?b=c&d=e

TermURL: g?PayID=h&TransID=i&MID=j


Notice: Please note in this process that data must sometimes be transferred directly from the bank network. Therefore e.g. the ACSURL parameter is not URL-encoded, although the payment platform uses other URL-encoded data.

These parameters should be included as HIDDEN fields in an HTML page which posts itself to the ACS-URL. The following listing shows one such HTML page, in which the return parameters are embedded:

<HTML>

<HEAD>

<META http-equiv=Content-Type content="text/html; charset=unicode">

<A content="MSHTML 6.00.2800.1106" name=GENERATOR>

</HEAD>

<BODY onload="sendpareq.submit();">

<FORM action="[ACSURL]" method="POST" name="sendpareq">

<input type="hidden" name="MD" value="">

<input type="hidden" name="PaReq" value="[PaReq]">

<input type="hidden" name="TermUrl" value="[TermUrl]">

</FORM>

</BODY>

</HTML>


Notice: You can also use this code if you only want to verify the identity of the card holder without immediately making a card payment (Authentication Hosting). BNP Paribas Support can configure your checkout so that the payment platform can carry out Verified by Visa or SecureCode without payment.

After the customer has been authenticated with its bank, the bank's Access Control Server (ACS) requests the TermURL in the shop. In the case of this Request the ACS transfers the following parameters via GET (QueryString) to the TermURL of the shop: MID, PayID and TransID (unencrypted). The PARes parameter is transferred unencrypted via POST.

Notice: The PAResponse parameter must be URL encoded but not Blowfish-encrypted since the content can include special characters.

The parameter must be transferred in whole via POST to the following URL:


Notice: If you forward the PARes and MID of the ACS parameters please use the specified parameter name MerchantID, PAResponse for the direct3d.aspx page.

 


Call of interface: general parameters

Notice: For card payments with 3D Secure, please note the different cases as explained separately in the previous chapter. If the card is registered for Verified or SecureCode or SafeKey, the next phase is divided into two steps of authentication and payment. However, it always begins in the same way via the direct.aspx interface. The first response is the receipt of Javascript code or other parameters in order to carry out a second call up of the direct3d.aspx interface. Only after that, you receive the listed parameter as a response.

(info) Credit card still must be valid at time of capture / refund. Therefore BNP accepts credit cards when the card is at least 1 week valid before expire (e.g.: CC expire: 2020-03 authorizations possible until 2020-03-24, 23:59:59).

To carry out a TLS card payment via a Server-to-Server connection, call the following URL:


Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.


All information about payssl integration are available in the section Server-2-Server - MIT payments - direct.aspx


Payment via batch

This section describes the parameters that must be transferred within the data set (Record) for executing a card payment and which information can be found within the response file about the payment status.

The structure for a card payment within a Batch file to be submitted is the following:

HEAD,<MerchantID>,<Date>,<Version>

CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]

CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,[<FinishAuth,<textfeld1>,<textfeld2>,<approvalcode>]

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]

CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>]

CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>]

CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>

FOOT,<CountRecords>,<SumAmount>


Example for batch versions:

Version 1.2:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>

Version 1.21:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>

Version 1.3:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>

Version 1.5:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<Zone>


The following table describes the individual fields and values used within the data set (record) in the batch file:

ParameterFormatCNDDescription
RefNran12OC

Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file we cannot add the additional payment data.

Notes:

  • Fixed length of 12 characters (only characters (A..Z, a..z) and digits (0..9) are allowed, no special characters like whitespace, underscore...)
  • For AMEX : RefNr is mandatory
  • If the number of characters entered is lower than 12, BNP will complete, starting from the left side, with "0" (Example : 000018279568)

Type

a..11

M

HEAD for Header, FOOT for Footer, CC for card

Action

a..20

M

The parameter Action defines the type of transaction:

Authorize (authorisation)

Capture

Sale

Credit

CreditEx (credit note without previous capture; please agree this with Support beforehand)

Reverse (cancellation)

Amount

n..10

M

Amount in the smallest currency unit (e.g. EUR Cent).

Please contact the helpdesk, if you want to capture amounts < 100 (smallest currency unit).

Currency

a3

M

Currency code, three digits DIN / ISO 4217

TransID

ans..64

M

TransactionID which should be unique for each payment

PayID

an32

M

ID for this transaction given by the payment platform

OrderDesc

ans..127

O

Description of purchased goods, unit prices etc.

CCBrand

a..22

C

Card brand.

Please note the spelling! According to table of card brands!

CCNr

n..16

C

Card number at least 12-digit, numerical without spaces. You can optionally transmit also a pseudo card number (PCN)

PCNr

n..16

O

You can optionally transmit also a pseudo card number (PCN) instead of the real card number

CCCVC

n..4

O

Card verification number in Version 1.3: In the case of Visa and MasterCard the last 3 numbers on the signature strip of the card. 4 numbers in the case of American Express.

CCExpiry

n6

O

Expiry date of the card in the format YYYYMM, e.g. 201707.

FinishAuth

ans1

O

Version=1.4: If using the authorisation renewal, cancel repeat with the value Y in the field FinishAuth in the case of Capture or Credit. Example: You capture a partial delivery. The rest of the order cannot be supplied. You therefore enter Y in the FinishAuth field for Part-capture so that the payment platform does not authorise the remaining amount. Please note for this also the following section about Cancel authorisation renewals.

The record area within the response file for Batch transactions looks as follows:

HEAD,<MerchantID>,<Date>,<Version>

CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>

CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[<textfeld1>,<textfeld2>,<approvalcode>],<Status>,<Code>

CC,AuthSplit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]

CC,Renewal,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>

CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>],<Status>,<Code>

CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>],<Status>,<Code>

CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<Status>,<Code>

FOOT,<CountRecords>,<SumAmount>

 

Example for batch versions:

Version 1.2:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<Status>,<Code>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

Version 1.21:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

Version 1.3:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

Version 1.5:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<Zone>,<Status>,<Code>


The following table describes the response parameters which the batch Manager saves in the “Record” area for each transaction (standard parameters not explained here, such as <TransID> or <RefNr> and request parameters are returned unchanged and correspond to the call as specified before):

ParameterFormatCNDDescription

Action

a..20

M

The parameter Action defines the type of transaction like capture or credit – see above.

PayID

an32

M

ID for this transaction given by the payment platform

Status

a..50

M

OK or FAILED

Code

n8

M

Error code according to the payment platform Response Codes Excel file

PCNr

n..16

C

The Pseudo Card Number is only returned in the case of transaction types Authorize or Sale & CreditEx. It starts with 0 and the last 3 digits correspond to those of the real card number.

 


Card payments management

Capture

The merchant can choose one of these different options of capture:

  • Manual capture
  • Automatic capture
  • Automatic capture with customized delay (number from 1 to 696)

When choosing the manual mode, it’s necessary for the merchant to validate manually each transaction. A transaction must be validated before 7 days. Captures are possible via a Server-to-Server connection. To perform captures via a Server-to-Server connection please use the following URL:


When choosing the automatic, capture is made every day at the end of the day.

When choosing the automatic mode with customized delay, the merchant sets a delay in hours (from 1 to 696) that corresponds to the frequency of capture

Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Parameter

Format

CND

Description

RefNran12OC

Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file we cannot add the additional payment data.

Notes:

  • Fixed length of 12 characters (only characters (A..Z, a..z) and digits (0..9) are allowed, no special characters like whitespace, underscore...)
  • For AMEX : RefNr is mandatory
  • If the number of characters entered is lower than 12, BNP will complete, starting from the left side, with "0" (Example : 000018279568)


In cas of manual capture, the RefNr should be the same for authorization (payement creation) and capture. 

If values are different, the financial reconciliation will not work.

MerchantID

ans..30

M

Merchant ID, assigned by BNP

PayID

an32

M

ID assigned by the payment platform for the payment

TransID

ans..64

M

TransactionID which should be unique for each payment

MAC

an64

M

Hash Message Authentication Code (HMAC) with SHA-256 algorithm

Amount

n..10

M

Amount in the smallest currency unit (e.g. EUR Cent).

Please contact the helpdesk, if you want to capture amounts < 100 (smallest currency unit).

Currency

a3

M

Currency, three digits DIN / ISO 4217

ReqID

ans..32

O

To avoid double payments, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction is submitted again with the same ReqID, the payment platform will not carry out the payment, but will just return the status of the original transaction. Please note that the payment platform must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly.

FinishAutha1COnly with ETM: Transmit value <Y> in order to stop the renewal of guaranteed authorisations and rest amounts after partial captures. Please use this parameter only if you are using the additional function ETM (Extended Transactions Managament).

Textfeld1

ans..30

O

Card holder information: Name

Textfeld2

ans..30

O

Card holder information: City

 

The following table describes the payment platform‘s response parameters:

ParameterFormatCNDDescription

MID

ans..30

M

MerchantID

RefNran12OC

Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file we cannot add the additional payment data.

Notes:

  • Fixed length of 12 characters (only characters (A..Z, a..z) and digits (0..9) are allowed, no special characters like underscore, minus...)
  • For AMEX : RefNr is mandatory

PayID

an32

M

ID assigned by the payment platform for the payment, e.g. for referencing in batch files

XID

an32

M

ID for all single transactions (authorisation, capture, refund) for one payment assigned by the payment platform

TransID

ans..64

M

Merchant’s transaction number

Status

a..50

M

OK or FAILED

Description

ans..1024

M

Further details in the event that payment is rejected. Please do not use the Description but the Code parameter for the transaction status analysis!

Code

n8

M

Error code according to the payment platform Response Codes Excel file

 

Partial captures are also possible by setting the « Amount » parameter with the partial amount to capture in the payment request, or via the back office by visualizing the transaction details then setting the partial amount to capture.



Cancellation

Cancellation function allows to cancel a transaction before it gets captured.

BNP Paribas manages the cancellation requests by proceeding to 2 verifications:

-              The amount: It’s forbidden to cancel an amount that is superior to the initial amount of the transaction. 

-              Payment capture time: Once a payment is captured, it can’t be cancelled anymore.

To make a cancellation, use the following URL:


Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

Notice: Reverse.aspx does not only reverse authorizations, but any last transaction stage. If the last transaction was a capture, Reverse.aspx initiates the reverse, e.g. a refund. Therefore, the utmost caution is urged. Use is at your own risk. We recommend checking the transaction status with Inquire.aspx before using Reverse.aspx.

(Further information about inquire.aspx you can find within the documentation Status requests.)

The following table describes the encrypted payment request parameters:

Parameter

Format

CND

Description

MerchantID

ans..30

M

MerchantID

PayID

an32

M

the payment platform ID for the identification of a payment

TransID

ans..64

M

TransactionID which should be unique for each payment

Amount

n..10

M

Amount in the smallest currency unit (e.g. EUR Cent).

Please contact the helpdesk, if you want to capture amounts < 100 (smallest currency unit).


The amount should be the same as the authorization. Partial reverse is not available

Currency

a3

M

Currency code, three digits DIN / ISO 4217

MAC

an64

M

Hash Message Authentication Code (HMAC) with SHA-256 algorithm

ReqID

ans..32

O

To avoid double payments, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction is submitted again with the same ReqID, the payment platform will not carry out the payment, but will just return the status of the original transaction. Please note that the payment platform must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly.

 

The following table describes the payment platform response parameters:

ParamaterFormatCNDDescription

MID

ans..30

MC

MerchantID

PayID

an32

M

ID assigned by the payment platform for the payment, e.g. for referencing in batch files

XID

an32

M

ID for all single transactions (authorisation, capture, refund) for one payment assigned by the payment platform

TransID

ans..64

M

Merchant’s transaction number

Status

a..50

M

OK or FAILED

Description

ans..1024

M

Further details in the event that payment is rejected. Please do not use the Description but the Code parameter for the transaction status analysis!

Code

n8

M

Error code according to the payment platform Response Codes Excel file

 


Refunds

Refunds allow to re-credit a customer who was previously debited (product not delivered, product damaged, product sent back…). The customer’s bank account is credited with the exact amount as the debit amount of the merchant. The merchant can refund a customer until 12 months following the purchase.

Refunds are not permitted for unpaid transactions.

Refunds are possible via a Server-to-Server connection. The payment platform permits refunds which relate to a capture previously activated by the payment platform and allows merchants to carry out refunds without a reference transaction. This section describes the processing of refunds with reference transactions. If you refer to a capture for a refund, the amount of the refund is limited to the amount of the previous capture.

To carry out a refund with a reference transaction, please use the following URL:


Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Parameter

Format

CND

Description

RefNran12OC

Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file we cannot add the additional payment data.

Notes:

  • Fixed length of 12 characters (only characters (A..Z, a..z) and digits (0..9) are allowed, no special characters like underscore, minus...)
  • For AMEX : RefNr is mandatory

MerchantID

ans..30

M

Merchant ID, assigned by BNP

PayID

an32

M

ID assigned by the payment platform for the payment

TransID

ans..64

M

TransactionID which should be unique for each payment

MAC

an64

M

Hash Message Authentication Code (HMAC) with SHA-256 algorithm

Amount

n..10

M

Amount in the smallest currency unit (e.g. EUR Cent).

Please contact the helpdesk, if you want to capture amounts < 100 (smallest currency unit).

Currency

a3

M

Currency, three digits DIN / ISO 4217

OrderDesc

ans..768

O

Merchant's reference number

ReqID

ans..32

O

To avoid double payments, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction is submitted again with the same ReqID, the payment platform will not carry out the payment, but will just return the status of the original transaction. Please note that the payment platform must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly.

Textfeld1

ans..30

O

Card holder information: Name

Textfeld2

ans..30

O

Card holder information: City

The following table describes the payment platform response parameters:

ParameterFormatCNDDescription
RefNran12OC

Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file we cannot add the additional payment data.

Notes:

  • Fixed length of 12 characters (only characters (A..Z, a..z) and digits (0..9) are allowed, no special characters like underscore, minus...)
  • For AMEX : RefNr is mandatory

MID

ans..30

M

MerchantID

PayID

an32

M

ID assigned by the payment platform for the payment, e.g. for referencing in batch files

XID

an32

M

ID for all single transactions (authorization, capture, refund) for one payment assigned by the payment platform

TransID

ans..64

M

Merchant’s transaction number

Status

a..50

M

OK or FAILED

Description

ans..1024

M

Further details in the event that payment is rejected. Please do not use the Description but the Code parameter for the transaction status analysis!

Code

n8

M

Error code according to the payment platform Response Codes Excel file



Payment methods listThis page lists the payment methods available on AXEPTA Online and help you to identify those that correspond to your target market.


Understanding

  • Region / Country
    • Geographical area in which the payment method can be subscribed by buyers.
    • This allows you to identify the payment methods of the target market (final customers in a given geographical area) in which the merchant want to develop activity.
    • Ex: Identify the usual payment methods used in Europe and available on AXEPTA.
  • Geographic area of interest
    • Geographic area in which the payment method is considered standard.
    • If a merchant wants to develop the activity in a specific geographical area, he's adviced to accept the payment method(s) whose main market (buyers) corresponds to his target.
    • Ex: A merchant who targets the French market is advised to accept CB.



Role-playing

Example: The merchant is based in Portugal. He wants to sell products online and targets Belgian customers

  • Identify the payment methods that are most commonly used in Belgium, so that the target customers can pay for their purchases with their usual payment methods
  • In the table,  "Region of buyers" column lists the payment methods available in Europe and internationally
  • Then the "Country of buyers" column allows you to identify the payment methods available in Belgium
  • Finally, the column "Unmissable geographic area" indicates the payment methods available in Belgium
  • In conclusion:
    • Belgium: Bancontact
    • International : Visa, Mastercard, Amex, Paypal, Apple Pay, Google Pay...



Payment methods list available with AXEPTA Online


LogoPayment methods Payment typeContractCurrencyRegion of buyersCountry of buyers

Unmissable geographic area

Alipaye-WalletPPROAUD, CAD, EUR, GBP, HKD, SGD, USDAPACChinaChina

Amazon Paymentse-WalletAmazon

EUR, GBP, USD,...

For other currency Check with private scheme

Europe, APACEurope, Switzerland, England, India, JapanFrance, Germany, Belgium, England, Japan

American ExpressPrivate cardAmexEUR,GBP,CHF,USD, AUD,CAD, DKK,JPY,NOK,PLN,SEKInternationalInternationalInternational

Apetiz via Natixise-WalletApetizEUREuropeFranceFrance

Apple Paye-WalletAppleEUR,GBP,CHF,USD, AUD,CAD, DKK,JPY,NOK,PLN,SEK

International

InternationalInternational

BancontactDebit cardPPROEUREuropeBelgiumBelgium

BarzahlenCash-in / BillBarzahlen

EUR

For other currency Check with private scheme

EuropeGermanyGermany

BillpayMixteBillpay

EUR

For other currency Check with private scheme

EuropeAustria, Belgium, Netherlands, United Kingdom, SwitzerlandAustria, Belgium, Netherlands, United Kingdom, Switzerland

 

Boleto Bancario Cash-in / BillPPROBRLSouth AmericaBrazilBrazil

CBCredit card/ Debit/ CommercialBNPPEUREuropeFranceFrance

CetelemPay by instalmentsCetelem EUREuropeFranceFrance

Cetelem PrestoPay by instalmentsCetelem EUREuropeFranceFrance

Chèque Déjeuner via Groupe upMeal voucherChèque Déjeuner EUREuropeFranceFrance

Cheque-Vacances ConnectTravel voucherChèque vacances EUREuropeFranceFrance

Cofidis (Carte 4 Etoiles)Private cardCofidis

EUR

For other currency Check with private scheme

EuropeFranceFrance

Consors FinanzPay by instalmentsConsors FinanzEUREuropeGermanyGermany

DinersPrivate cardBNPPEUR, GBP, CHF, DKK, USD, CAD, JPY, NOK, SEK, PLN, AUDInternationalInternationalInternational

Discover (part of Diners' Group)Private cardPPROEUR, GBP, CHF, DKK, USD, CAD, JPY, NOK, SEK, PLN, AUDInternationalInternationalInternational

EPSBank transferPPROEUREuropeAustriaAustria

Finnish ebankingBank transferPPROEUREuropeFinlandFinland

Floa PayPay by instalmentsFloa PayEurEuropeFrance, Belgium, Italy, Portugal, SpainFrance

FPX MyClearInstant bank transferPPROMYRAPACMalaysiaMalaysia

GiropayBank transfer
PPROEUREuropeGermanyGermany

Availability : in 2023

Google Paye-WalletGoogleEUR,GBP,CHF,USD, AUD,CAD, DKK,JPY,NOK,PLN,SEKInternationalInternationalInternational

iDealBank transfer

PPRO

BNPP (if Netherlands)

EUREuropeNetherlands, PolandNetherlands

Instanea-logo_RVB.png

InstaneaBank transferInstaneaEURFranceFranceFrance

JCB Credit card/ Debit/ CommercialBNPPEUR, GBP, CHF, DKK, USD, CAD, JPY, NOK, SEK, PLN, AUDInternationalInternationalInternational

Klarnae-Wallet

Klarna


Check with private schemeEuropeAustria, Germany, Belgium, Spain, Finland, France, Hungary, Italy, Norway, Netherlands, Poland, Czech Republic, United Kingdom, Slovenia, Sweden, SwitzerlandAustria, Belgium, Denmark, Finland, Sweden

MaestroDebit cardBNPPEUR,GBP,CHF,USD, AUD,CAD, DKK,JPY,NOK,PLN,SEKInternationalInternationalInternational

MasterCardCredit card/ Debit/ CommercialBNPPEUR,GBP,CHF,USD, AUD,CAD, DKK,JPY,NOK,PLN,SEKInternationalInternationalInternational

Mobile Pay (by Danske Bank)e-WalletMobile Pay (by Danske Bank)

EUR

For other currency Check with private scheme

EuropeDenmark, FinlandDenmark

MultibancoBank transfer
PPROEUREuropePortugalPortugal

MyBankInstant bank transferPPROEUREuropeEuropeItaly, Spain

Pass Restaurant via SodexoMeal voucherSodexo EUREurope FranceFrance

PaybyBillBillPaybyBill

EUR

For other currency Check with private scheme

EuropeEuropeNorway, Switzerland, Denmark, Finland, Germany, Netherlands

PaydirektBank transfer
Paydirekt

EUR

For other currency Check with private scheme

EuropeGermanyGermany

PaymorrowDirect debitPaymorrow

EUR

For other currency Check with private scheme

EuropeGermanyGermany

PayPal e-WalletPaypal

EUR, GBP, USD,...

For other currency Check with private scheme

InternationalInternationalInternational

PaysafecardPrepaid cardPPROAUD, CAD, CHF, EUR, GBP, NOK, PLN, RON, SEK, USDNorth America, Peru, Urugay, Argentina, Europe, Australia, 

New Zealand

Europe, North America, Peru, Argentina, Australia, New ZealandPoland, France, Austria, Spain

PostFinance Card Instant bank transferPPRO

EUR

For other currency Check with private scheme

EuropeSwitzerlandSwitzerland

Przelewy24 (P24)Instant bank transferPPROPLNEuropePolandPoland

Ratenkauf / EasyCreditBill/ Pay by instalmentsRatenkauf / EasyCredit

EUR

For other currency Check with private scheme

EuropeGermanyGermany

RatePayDirect debitRatePay

EUR

For other currency Check with private scheme

EuropeGermanyGermany

RHB BankInstant bank transferPPROMYRAPACMalaysiaMalaysia

SEPA Direct Debit (SDD)Direct debit SDDPPROEUREuropeEuropeEurope

SofincoPay by instalmentsSofincoEUREuropeFranceFrance

Trustly Bank transferTrustly

EUR

For other currency Check with private scheme

EuropeAustria, Germany, Belgium, Bulgaria, Croatia, Spain, Estonia, Finland, Hungary, Latvia, Lithuania, Norway, Netherlands, Poland, Czech Republic, Romania, United Kingdom, Slovenia, SwedenSweden

TrustPay Instant bank transferPPROCZK, EUREuropeSlovakia, Czech RepublicSlovakia, Czech Republic

Union Pay International (UPI) / CUPCredit card/ Debit/ CommercialPPROEUR, GBP, USDInternationalInternationalInternational

VisaCredit card/ Debit/ CommercialBNPPEUR,GBP,CHF,USD, AUD,CAD, DKK,JPY,NOK,PLN,SEKInternationalInternationalInternational

Visa Electron/ VPAYDebit cardBNPPEUR,GBP,CHF,USD, AUD,CAD, DKK,JPY,NOK,PLN,SEKInternationalInternationalInternational

WeChate-WalletPPRO

EUR, GBP, USD

APACChinaChina



→ Updated version will be provided end of 2024

Assistance Axepta BNP Paribas


Our support service is available by email and phone from 8:30am to 6pm, Monday to Friday.

You can contact them at bnpparibas@computop.com or +33 825 07 27 47 (Service 0,15€ / min. + call price) by indicating your merchant identifier (MID) and, if necessary, the additional elements indicated below.


If your question is about the Back-Office :

  • User name
  • Functionality used


If your question is about a transaction or transactions:

  • Information to identify your transaction

MID (Having made the transaction)

TransID

PayId

RefNr

Date/Time of the transactionAmount

BNP_DEMO_AXEPTA

TID-20480457802137656

dda7fd92e1f54ac388ded9f55eaftr78

dxmnq0ljk0uu

****
  • The error message
  • A screenshot (optional)



If your integration is under CMS :

  • The CMS and the version used as well as the version of the Axepta plugin
  • A screenshot (optional)



Where is my payID ?

Please check our dedicated section How to find the PayId of a transaction ?

The Time-out error is usually caused by :

  • The structure or the format of the HMAC key
  • The structure or the format of the Blowfish key
  • The structure of your activation key.


HMAC

The HMAC key has 32 characters and is composed of numbers, letters and special characters.

The key must not contain any space, be sure to check the last character of your key.


Blowfish

The blowfish key has 32 characters and is composed of numbers, letters and special characters.

The key must not contain any space, be sure to check the last character of your key.


Test tool

Our test tool allows you to check :

  • Blowfish encyption
  • Blowfish decryption
  • MAC calculation
  • Base64-encoding

 Axepta Platform // Simple Test Tools (paytest.info)


Activation key

All details about the activation key are available in the section : Activation key

  • No labels