Versions Compared

Old Version 2

changes.mady.by.user writer

Saved on

compared with

New Version 3

changes.mady.by.user writer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

1.    Signature de contrat et préparation de la phase d’onboarding.

La phase d’onboarding permet à BNP Paribas de récupérer un ensemble d’informations administratives et techniques pour vous ouvrir un contrat monétique, vous fournir un identifiant (MID) et des données d’accès techniques (clé HMAC, clé Blowfish) permettant d’intégrer notre solution de paiement en toute sécurité.

Parmi les informations qui doivent être partagées entre le commerçant et BNP Paribas :

  • Informations administratives sur le commerçant (raison sociale, adresse, Numéro de SIRET…)
  • Règles anti-fraude
  • Coordonnées des contacts (Contact technique/ administrateur du backoffice)
  • Type d’intégration (Plugin / Paytweak / Intégration directe)
  • RIB (pour le Fichier de réconciliation et la facturation)

2.    Réception des données d’accès 

Lorsque le chargé d’affaire finalise la phase d’onboarding, vous recevrez vos données d’accès techniques (MID, Clé HMAC, Clé Blowfish) qui vous permettent d’entamer la phase d’intégration. La réception de ces données est expliquée dans la documentation suivante :

https://docs.axepta.bnpparibas/display/DOCBNP/Premiers+pas+avec+AXEPTA+BNP+Paribas#PremierspasavecAXEPTABNPParibas-VousutilisezunmoduledepaiementAXEPTA

3.     Concepts / Workflow

3.1.  Solution Axepta

La solution de paiement AXEPTA est basée sur une API permettant

  • d’interroger le serveur Axepta grâce à des requêtes de paiement,
  • de proposer ensuite aux acheteurs une interface de paiement ergonomique et sécurisée
  • de rediriger les clients vers une page pour visualiser le résultat de la transaction (sur le site commerçant)

3.2.  Interfaces disponibles

Axepta propose 4 options d’intégration :

  • Page de paiement
  • Connexion server-to-server
  • Batch
  • In-App (SDK Mobile)

Page de paiement : 3 EndPoints disponibles

  • aspx :
    • Page contenant la liste de moyens de paiement disponibles
    • Cette page est hébergée par Axepta, elle peut également être créée et hébergée par le commerçant
    • Lien : Payment page - Documentation BNP - Axepta
  • aspx
  • aspx: 
    • Spécificités
      • Le commerçant créé et héberge un formulaire de paiement. Les données du formulaire sont directement envoyées à Axepta grâce au paramètre « action » du formulaire HTML qui contient l’URL du serveur Axepta.
      • Ainsi, les données sensibles saisies sur le site du commerçant sont transmises directement au serveur Axepta et ne sont pas transmises au serveur du commerçant (requête POST silencieuse).
    • Usages
      • Saisie des informations carte : Le commerçant doit avoir la certification PCI
      • One-click avec utilisation d’un token / Pseudo PAN number (récupéré via l’objet JSON Card) et saisie du CVV
        • @Helpdesk à Comment est géré l’authentification 3DS ? Directement par Axepta ou le marchand a quelque chose à faire ?
      • Lien : Silent Order Post (PayNow) - Documentation BNP - Axepta

Connexion server-to-server

L’API Axepta permet de réaliser des paiements (direct.aspx - Server-2-Server Integration - Documentation BNP - Axepta) ou toutes les opérations de gestion (remboursement, capture, annulation, demande de statut…).

Exemple pour les paiements carte : Cards payments Integration - Documentation BNP - Axepta

Pour les autres moyens de paiement, les opérations disponibles sont indiquées dans la page du moyen de paiement.

Axepta propose une API pour chaque moyen de paiement, se référer à la documentation : https://docs.axepta.bnpparibas/display/DOCBNP/Alternative+payment+methods+Integration

 

Batch

Axepta peut réaliser des paiements ou des opérations en masse via l’intégration d’un fichier dont le format est précisé dans la documentation.

Cette méthode d’intégration est disponible pour les paiements carte oneshot et récurrents ainsi que les opérations sur les cartes (remboursement, annulation…).

https://docs.axepta.bnpparibas/pages/viewpage.action?pageId=6914803#Guided'int%C3%A9grationtechniqueg%C3%A9n%C3%A9ral-FichiersBatch

https://docs.axepta.bnpparibas/pages/viewpage.action?pageId=6914788#Int%C3%A9grationdupaiementparcartes-Paiementparbatch 

Paiement via mobile application (Mobile SDK)

Le processus d’intégration d’une SDK Mobile est décrit dans cette documentation : https://docs.axepta.bnpparibas/pages/viewpage.action?pageId=6914803#Guided'int%C3%A9grationtechniqueg%C3%A9n%C3%A9ral-In-App(MobileSDK)

3.3.  Expériences clients proposes par Axepta

Le choix d’afficher la page de paiement en redirection ou en iFrame revient au commerçant.

  • Page de paiement en redirection: L’acheteur est redirigé, hors du site commerçant, vers la page de paiement sécurisée. Il s’agit d’une option simple et sécurisée. La page est responsive et peut être personnalisée.  L’ajout du logo du site, les couleurs et les polices donnent à l’acheteur l’impression de rester sur le même environnement.

3.4.  Données clés

3.4.1.      Le MID

En souscrivant à Axepta, vous aurez accès à un ou plusieurs MID. Un MID ou Merchant ID permet d’identifier une boutique en ligne.

Il existe 3 types de MIDs :

  • MasterMID: Permet d’avoir une vue globale de l’activité du commerçant sur les différentes boutiques qu’il possède. Le masterMID ne peut pas être utilisé pour réaliser des transactions mais est principalement utilisé pour se connecter au backoffice et visualiser l’ensemble de son activité.
  • MID de test: Permet d’effectuer des transactions de test (sans remise en banque).
  • MID de production: Permet d’effectuer des transactions dans un environnement de production (environnement LIVE, avec remise en banque).
  • Le passage en production se fait tout simplement à la main du commerçant, en changeant de MIDs (du MID de test au MID de production).

3.4.2.      Les URLs

Redirection du client : URLSucess & URLFailure

Axepta redirige l’acheteur vers l’une de ces pages en fonction du résultat du paiement :

  • URLSuccess si le paiement est réussi
  • URLFailure si le paiement est échoué.

Lorsque le paiement est effectué, le client est redirigé via HTTP GET vers la boutique du commerçant.

Axepta retourne ensuite un statut HTTP 302 (objet déplacé) et joint le statut du paiement en tant que paramètre avec chiffrement Blowfish à URLSuccess ou URLFailure. Les URLs (Success et Failure) sont des pages spécifiées par le commerçant.

Notification envoyée au Système d’information du commerçant : URLNotify

Après l’exécution du paiement, la solution de paiement notifie la boutique du résultat du paiement. Pour ce faire, la solution de paiement appelle URLNotify via HTTP POST. Il s’agit d’une communication entièrement distincte de la connexion d’origine entre la boutique, l’acheteur et la solution de paiement.

L’appel Notify est autorisé uniquement via le Port 443 (TLS) pour des raisons de sécurité.

Si l’URLNotify de la boutique n’est pas accessible (p. ex. statut HTTP 500/404), la notification est répétée 8 fois en 24h.

3.4.3.      Les données de réconciliation

Certaines données permettent au commerçant de faire le lien entre l’initialisation d’un paiement et le paiement effectif :

Reference number (RefNr) ou référence d’archivage :

La référence d’archivage ou « RefNr » est un champ qui doit être véhiculé dans toutes vos requêtes. Elle est présente dans tous les reportings Axepta.

Il s’agit d’un paramètre obligatoire de 12 caractères alpha-numériques (uniquement chiffres & lettres).

Transaction ID (TransID)

Ce champ représente la référence de la transaction unique sous la forme d’un paramètre obligatoire de 64 caractères alpha-numériques et pouvant comporter des caractères spéciaux.

Cette donnée est présente dans tous les reportings Axepta.

Description du panier (orderDesc)

Ce champ permet de passer en paramètre des données (descriptions des articles/produits achetés) qui seront retournées en l’état au commerçant.

Il peut également être affiché dans la page de paiement (customField) et est transmis de la requête de paiement au fichier de rapprochement.

Cette donnée est présente dans tous les reportings Axepta.

3.4.4.      Les codes retours

Les codes retours se présentent sous la forme d’un code de 8 caractères répartis en 3 blocs : N8, ( N NNNNNNN)

  • N (status)
  • NNN (Catégorie)
  • NNNN (détails)

Exemple d’un code retour :

2 206 0203

  • 2 Error
  • 206 3DS credit card adapater for authorization protocol GICC
  • 0203 Card brand does not support 3DS

Lien vers la liste complète des codes retours : https://docs.axepta.bnpparibas/display/DOCBNP/Codes+retour

Lien vers la liste des codes retours 3DSv2 : https://docs.axepta.bnpparibas/display/DOCBNP/3DS+Response+Codes

4.    Intégration technique de la solution

4.1.  Concepts techniques et création d’une requête

Concepts

L’intégration de la solution de paiement Axepta se base principalement sur un concept de construction de requête de paiement dont les principes sont les suivants :

  • Gestion des paramètres en méthode NVP (Name-Value-Pairs)
  • Une chaîne de caractères correcte contient trois paramètres de base : MerchantID (Identifiant du commerçant), Len (Longueur) et Data (Données). Les paramètres MerchantID et Len ne sont pas chiffrés. Seul le paramètre Data est chiffré avec la méthode Blowfish

Paramètres

  • Le paramètre Data (Données) comprend les détails de paiement essentiels comme le montant et la devise.
  • Le paramètre Len (Longueur) est très important pour le chiffrement, car il contient la longueur de la chaîne de caractères non chiffrée dans le paramètre Data. La quantité de données à chiffrer étant multipliée par 8 dans le cas du chiffrement Blowfish, la longueur correcte de la chaîne de caractères doit être connue pour le déchiffrement, sans quoi d’autres caractères non prévus apparaissent à la fin de la chaîne de caractères.

Les paramètres sont transmis via HTTPS POST ou HTTPS GET.

La méthode de transmission recommandée est HTTPS POST, car la chaîne de caractères du paramètre dans le cas de GET, jointe à l’URL, est limitée à 2 048 octets selon le navigateur, contrairement à la méthode POST qui n’est pas limitée par la taille de l’URL.

Création d’une requête

Les étapes de création d’une requête sont :

  • Calcul MAC pour sécuriser le montant et la devise
  • Assembler les paramètres de l’API - non chiffré
  • Chiffrer tous les paramètres de l’API : cela permettra d’obtenir les paramètres Data et Len
  • Si besoin, ajouter des paramètres simples pour personnaliser la page de paiement hébergée par (par exemple language="en » pour utiliser la langue anglaise)
  • Envoyer la demande d’API au endpoint choisi

 

Documentation en ligne associée

Technical Integration Guide - Documentation BNP - Axepta

https://docs.axepta.bnpparibas/display/DOCBNP/Create+an+API+call+and+samples+to+play

4.2.  Authentification HMAC

La première étape dans la phase d’intégration directe de la solution AXEPTA consiste à vérifier l’authenticité de la requête de paiement via l’authentification HMAC.  Cette méthode est expliquée dans la documentation suivante :

https://docs.axepta.bnpparibas/display/DOCBNP/Authentification+HMAC

4.3.  Page de choix des moyens de paiement

Si un commerçant a plusieurs moyens de paiement, cette page permet à l’acheteur de choisir son moyen de paiement favori.

La page de choix des moyens de paiement peut être :

La page de choix des moyens de paiement peut comporter l’ensemble des moyens de paiement souscrits par le commerçant. Le commerçant peut proposer des moyens de paiement spécifique en fonction d’un pays ou un type de client.

Question pour le helpdesk :

  • Commerçant qui veut paymentPage avec cartes + Paypal à Quelles sont les données à ajouter en paramètres de la requête pour faire un paiement carte 3DS + les éventuels paramètres spécifiques Paypal ?

4.4.  Paiement carte via la page de paiement Axepta

Etape 1 : Implémentation de l’appel à l’interface souhaitée

PaySSL : Hosted Payment Pages (paySSL) - new - Documentation BNP - Axepta

Important :

  • Les appels peuvent être effectués en GET ou en POST. Nous préconisons un appel en POST pour les raisons suivantes :
    • Aucun paramètre visible dans l’URL
    • La taille de l’URL est limitée à 2048 bytes
  • Renseigner la référence unique de transaction, RefNr, est fortement conseillé.

Etape 2 : Implémentation des paramètres spécifiques au paiement par carte AMEX

Cas : AMEX

Les champs RefNr et AmountAuth sont obligatoires pour les transactions AMEX.

Le guide du paiement par carte (dont AMEX) est disponible via ce lien :

Cards payments Integration - new - Documentation BNP - Axepta

Important :

  • Les URLSuccess, URLFailure et URLNotify ne doivent pas contenir de paramètres car la solution Axepta ajoute des paramètres lors de l’appel de l’URL.
  • Si le commerçant a besoin de spécifier certains paramètres, il peut utiliser le champ « Plain » dont le contenu est crypté dans la requête et renvoyé en réponse en clair (URL Notify / Success / Failure).

Etape 3 : Template de la page de paiement

Axepta propose plusieurs niveaux de personnalisation de la page de paiement

  • Utilisation du template Axepta
  • Activation d’un ou plusieurs champs personnalisés
    • CustomField1 : Montant et devise du paiement
    • CustomField2 : Numéro de commande
    • CustomField3 : Logo du commerçant
    • CustomField4 : Panier / description de la commande
    • CustomField5 : Détails de l'acheteur
    • CustomField6 : Détails de l'envoi
    • CustomField7 : Détails de facturation
    • CustomField8 : Nom du champ personnalisé propre au commerçant
    • CustomField9 : Texte du champ personnalisé propre au commerçant
  • Création d’un template commerçant hébergé par Axepta

 

Etape 4 : Gestion de la réponse et redirection du porteur

La plateforme notifie le serveur du commerçant via une requête en POST sur l’URL Notify.

Important

  • L’authentification 3DS V2 peut être effectuée en 3DS V1 sur demande de la banque émettrice (en cas de problème par exemple) on parlera alors de Fallback 3DSV1.
  • Dans ce cas, la plateforme envoie une réponse en GET. Il est ainsi nécessaire de pouvoir recevoir aussi ce type de réponse.
  • La réponse GET contient à la fois l’objet JSON Card, les données cartes ‘3DSV1’ (PCNr, CCExpiry…) ainsi que le schemeReferenceId (utilisé pour le chaînage des transactions récurrentes).

En fonction du statut du paiement (réussi ou échoué), Axepta redirige le porteur sur l’URL Success ou URL Failure définie par le commerçant.

4.5.  PayPal

Type d’intégration

En cas d’utilisation de paymentPage, l’appel à Paypal est géré par la plateforme Axepta.

Si la page de choix des moyens de paiement est géré par le marchant, le commerçant doit implémenter l’appel à la méthode Paypal disponible dans l’API Axepta (PayPal direct integration - Documentation BNP - Axepta).

Onboarding Paypal

Le commerçant doit souscrire auprès de Paypal et communiquer à son chargé d’affaires ou au support l’adresse mail relative au compte PayPal.

Ensuite, il faudra configurer son API PayPal en suivant les étapes suivantes :

Expérience du porteur

Lorsque le porteur choisi « Paypal », il est redirigé sur la page PayPal et effectuera son paiement (saisie des données, authentification…).

Une fois le paiement effectué (succès ou échec), le porteur est redirigé vers le site du commerçant.

Opérations et réconciliation

Le commerçant peut retrouver l’ensemble des transactions PayPal sur le backoffice AXEPTA, dans le fichier de réconciliation ou dans le Smartdata (cf. sections dédiées) .

Les différentes opérations possibles (capture, remboursement, annulation...) sont également décrites dans la documentation.

Remise des fonds

Le versement PayPal sera effectué directement sur le compte du commerçant.

4.6.  Paiement avec tout autre moyen de paiement

Se référer à la documentation du moyen de paiement demandé :  https://docs.axepta.bnpparibas/pages/viewpage.action?pageId=6914326

5.    Fonctionnalités

5.1.  Opérations disponibles

Les opérations peuvent être effectuées via le Back-Office ou via API.

Opérations

  • Capture : Envoi d’un paiement en banque – capture.aspx
    • La capture est soit automatique c’est-à-dire gérée par la plateforme le soir ou entre 1 à 696 heures après l’autorisation (on parle de capture différée), soit manuelle (à la main du commerçant)
  • Annulation – reverse.aspx
    • L’annulation d’une transaction peut uniquement être effectuée avant la capture.
    • Le montant de l’annulation ne peut pas être supérieur au montant de l’autorisation
    • A noter: Avant d'exécuter des annulations via l'interface reverse.aspx, il est recommandé de vérifier le statut de la transaction avec inquire.aspx, car Reverse.aspx annule non seulement les autorisations, mais également la dernière étape de la transaction.
  • Remboursement (avec référence de la transaction) – credit.aspx
    • 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.
  • Remboursement (sans référence de la transaction) – creditx.aspx
    • Dans ce cas, le remboursement doit être transféré à plateforme de paiement comme une nouvelle transaction de paiement.

Exemples pour les cartes

https://docs.axepta.bnpparibas/pages/viewpage.action?pageId=6914788#Int%C3%A9grationdupaiementparcartes-Gestiondespaiementsparcarte

  1. Se reporter à la page dédiée à chaque moyen de paiement pour accéder aux opérations disponibles.

5.2.  Consulter le statut d’une transaction

La fonctionnalité « inquire.aspx » fournit des informations détaillées sur les montants autorisés, capturés ou remboursés.

Plus de détails dans cette documentation : Status inquiries - Documentation BNP - Axepta

5.3.  Récupération du Pseudo PAN du porteur / Token

L’objet JSON Card, renvoyé en réponse d’une requête de paiement, contient le numéro de carte du porteur tokenisé.

Détail de l’objet : card:response EN - Documentation BNP - Axepta

Ces informations sont stockées par le commerçant afin d’être réutilisées lors du prochain paiement (one-click ou paiement récurrent).

Il n’est pas nécessaire d’être PCI DSS pour stocker cette donnée.

6.    Use-cases

6.1.  Liste des objets Json et champs nécessaires

Les paramètres / objets JSON suivants sont utilisés pour les cas d’usage expliqués ci-dessous :

...

6.2.  Demande de renseignement

Cette fonctionnalité permet de vérifier la validité d’une carte en effectuant une autorisation à 0 euro.

La réponse d’une demande de renseignement contient l’objet Card.

Paramètre à utiliser : ACCVerify

Account Verification - Documentation BNP - Axepta

Non-payment authentications for Card Add - Documentation BNP - Axepta

6.3.  Paiement one-Click

Description

  • Etape 1: Paiement initial et Enregistrement de la carte
    • Un client réalise un achat de 20,00 € sur le site du commerçant. Il saisit toutes les données nécessaires au paiement (numéro de la carte, date d’expiration, CVV…).
    • Le commerçant propose à son client d’enregistrer sa carte.
  • Etape 2: Proposer un paiement One-click
    • Lors de son prochain achat, le commerçant propose au client de réutiliser sa carte.
    • Le client saisit uniquement son CVV pour effectuer un paiement de 50,00€.

Mise en œuvre

La mise en œuvre précise les objets ou champs supplémentaires à utiliser.

Etape 1 : Paiement initial avec authentification forte et enregistrement de la carte via PaySSL.aspx

  • Requête
    • Enregistrement de la carte : Objet JSON credentialOnFile
      • "unscheduled": "CIT"
      • "initialPayment": true
    • Authentification forte : Objet JSON threeDSPolicy
      • challengePreference : mandateChallenge
    • Réponse
      • Récupération de l'objet JSON Card
        • Le commerçant stock l’objet JSON Card afin qu’il soit réutilisé lors du prochain paiement

Information : Lorsqu’un commerçant souhaite enregistrer une carte pour, à la fois, proposer la fonctionnalité one-click et effectuer des transactions récurrentes (MIT), il est impératif que la première transaction soit authentifiée et sans demande d’exemption. Dans ce cas, le commerçant devra effectuer une authentification forte (Objet JSON threeDSPolicy - challengePreference : mandateChallenge).

Etape 2 : Proposer un paiement One-click via PayNow.aspx

Le commerçant créé un formulaire permettant de récupérer uniquement le CVV du client.

  • Requête
    • Utilisation de la carte : Objet JSON credentialOnFile
      • "unscheduled": "CIT"
      • "initialPayment": false
    • Utiliser les données de l’objet JSON Card et le CVV saisi par l’acheteur
      • Number - Champ caché à l’utilisateur
      • securityCode - CVV saisi par l’acheteur – Seul champ « visible » du formulaire
      • expiryDate – Champ visible ou caché à l’utilisateur
      • brand – Champ visible ou caché à l’utilisateur
      • cardholder – Champ visible ou caché à l’utilisateur
    • Utiliser le paramètre browserInfo

@Helpdesk : S’il y a authentification 3DS, est-ce que l’appel est géré par Axepta ou le marchand doit effectuer quelque chose de supplémentaire ?

6.4.  Paiement récurrent ou MIT – en ecommerce / VADS

6.4.1.      Principes

La première transaction d’un paiement récurrent doit faire l’objet d’une authentification forte, donc sans exemption.

Les transactions suivantes (MIT) sont chainées / reliées à la 1ère transaction grâce au paramètre schemeReferenceId.

Note : Cohérence des montants – En attente réponse équipe Fraude

6.4.2.      Cas 1 : Paiement récurrent avec durée fixe et montant fixe – Abonnement

Exemple

Le client souscrit à une salle de sport pendant 1 an au prix de 34,99€ par mois.

  • Etape 1 : L’acheteur réalise le paiement du premier mois en ligne.
  • Etape 2-n : Les mois suivants, le commerçant initie les transactions à 34,99€.

Mise en œuvre

Etape 1 : Réalisation d’un paiement avec authentification forte et enregistrement de la carte

Utilisation de PaySSL.aspx

  • Requête
    • Authentification forte : Objet JSON threeDSPolicy
      • challengePreference : mandateChallenge
    • Enregistrement de la carte : Objet JSON credentialOnFile
      • Recurring :
        • "recurringFrequency": 28,
        • "recurringStartDate": "2021-01-02",
        • "recurringExpiryDate": "2021-12-02"
      • "initialPayment": true
    • Réponse
      • Récupération de l'objet JSON Card et du paramètre schemeReferenceId

Utilisation de PayNow.aspx à @Chrisitian / Helpdesk CT : Est-ce que cette implémentation est OK pour vous ?

Ex : Le commerçant a déjà enregistré la carte de l’acheteur. Le commerçant développe un formulaire permettant à l’acheteur de saisir uniquement son CVV.

  • Requête
    • Authentification forte : Objet JSON threeDSPolicy
      • challengePreference : mandateChallenge
    • Enregistrement de la carte : Objet JSON credentialOnFile
      • Recurring :
        • "recurringFrequency": 28,
        • "recurringStartDate": "2021-01-02",
        • "recurringExpiryDate": "2021-12-02"
      • "initialPayment": true
    • Utiliser les données de l’objet JSON Card et le CVV saisi par l’acheteur
      • Number - Champ caché à l’utilisateur
      • securityCode - CVV saisi par l’acheteur – Seul champ « visible » du formulaire
      • expiryDate – Champ visible ou caché à l’utilisateur
      • brand – Champ visible ou caché à l’utilisateur
      • cardholder – Champ visible ou caché à l’utilisateur
    • le paramètre browserInfo
  • Réponse
    • Récupération de l'objet JSON Card et du paramètre schemeReferenceId

 

Etape 2 – n : Transactions suivantes

  • Requête
    • Utilisation de la carte : Objet JSON credentialOnFile
      • Recurring :
        • "recurringFrequency": 28,
        • "recurringStartDate": "2021-01-02",
        • "recurringExpiryDate": "2021-12-02"
      • "initialPayment": false
    • Carte : Objet JSON Card
    • Paramètre schemeReferenceId – issue de la transaction initiale

Les transactions peuvent être effectuées via API (Server-to-Server – direct.aspx) ou via Batch.

6.4.3.      Cas 2 :  Abonnement de montant variable ou date de fin inconnue

Description

Exemples

  • Un client souscrit à un service dont le paiement mensuel est composé comme suit : forfait de base + consommation : abonnement téléphonique, abonnement à un contrat énergétique…
  • Abonnement à un service, sans date de fin, avec tacite reconduction et évolution annuelle du prix

Points d’attention

  • Le montant de la 1ère transaction doit être cohérent avec les transactions suivantes
    • Ex : un client souscrit à un service dont le forfait mensuel est de 30 euros et dont la consommation estimée est de 15 euros en moyenne à La première transaction devrait être de 45 euros.
    • Le commerçant peut capturer partiellement la 1ère transaction si nécessaire.
  • Les montants des transactions suivantes peuvent correspondre à une évolution de X% du montant de la transaction initiale

Mise en œuvre

Etape 1 : Réalisation d’un paiement avec authentification forte et enregistrement de la carte

Utilisation de PaySSL.aspx

  • Requête
    • Authentification forte : Objet JSON threeDSPolicy
      • challengePreference : mandateChallenge
    • Enregistrement de la carte : Objet JSON credentialOnFile
      • "unscheduled": "CIT"
      • "initialPayment": true
    • Réponse
      • Récupération de l'objet JSON Card et du paramètre schemeReferenceId

Utilisation de PayNow.aspx à @Chrisitian / Helpdesk CT : Est-ce que cette implémentation est OK pour vous ?

Ex : Le commerçant a déjà enregistré la carte de l’acheteur. Le commerçant développe un formulaire permettant à l’acheteur de saisir uniquement son CVV.

  • Requête
    • Authentification forte : Objet JSN threeDSPolicy
      • challengePreference : mandateChallenge
    • Enregistrement de la carte : Objet JSON credentialOnFile
      • "unscheduled": "CIT"
      • "initialPayment": true
    • Utiliser les données de l’objet JSON Card et le CVV saisi par l’acheteur
      • Number - Champ caché à l’utilisateur
      • securityCode - CVV saisi par l’acheteur – Seul champ « visible » du formulaire
      • expiryDate – Champ visible ou caché à l’utilisateur
      • brand – Champ visible ou caché à l’utilisateur
      • cardholder – Champ visible ou caché à l’utilisateur
    • le paramètre browserInfo
  • Réponse
    • Récupération de l'objet JSON Card et du paramètre schemeReferenceId

Etape 2 – n : Transactions suivantes effectuées en Server-to-server – direct.aspx

  • Requête
    • Utilisation de la carte : Objet JSON credentialOnFile
      • "unscheduled": "MIT"
      • "initialPayment": false
    • Carte : Objet JSON Card
    • Paramètre schemeReferenceId – issue de la transaction initiale

Les transactions peuvent être effectuées via API (Server-to-Server – direct.aspx) ou via Batch.

6.5.  Paiement récurrent ou MIT – en MOTO

6.5.1.      Principes

Les transactions MOTO / VAD sont hors du périmètre des RTS car elles ne sont pas authentifiées.

Cela signifie que les transactions initiées par le marchand n’ont pas besoin d’être chainées.

Note : Cohérence des montants – En attente réponse équipe Fraude

6.5.2.      Cas 1 : Paiement récurrent avec durée fixe et montant fixe – Abonnement

Exemple

Un client souhaite souscrire à un abonnement lui permettant de recevoir mensuellement plusieurs journaux (10,49€ par mois).

  • Etape 1 : L’acheteur contacte le centre d’appel, et transmet les informations de sa carte à un opérateur.
  • Etape 2-n : Les mois suivants, le commerçant initie les transactions à 10,49€.

Mise en œuvre

Etape 1 : Réalisation d’un paiement et enregistrement de la carte

Utilisation du backoffice

L’opérateur saisie les informations de carte dans le back-office.

Utilisation de PaySSL.aspx – non recommandé mais disponible

  • Requête
    • Enregistrement de la carte : Objet JSON credentialOnFile
      • Recurring :
        • "recurringFrequency": 28,
        • "recurringStartDate": "2021-01-02",
        • "recurringExpiryDate": "2021-12-02"
      • "initialPayment": true
    • Réponse
      • Récupération de l'objet JSON Card

 

Etape 2 – n : Transactions suivantes

  • Requête
    • Utilisation de la carte : Objet JSON credentialOnFile
      • Recurring :
        • "recurringFrequency": 28,
        • "recurringStartDate": "2021-01-02",
        • "recurringExpiryDate": "2021-12-02"
      • "initialPayment": false
    • Carte : Objet JSON Card

Les transactions peuvent être effectuées via API (Server-to-Server – direct.aspx) ou via Batch.

6.5.3.      Cas 2 :  Abonnement de montant variable ou date de fin inconnue

Description

Exemples

  • Un client souscrit à un service dont le paiement mensuel est composé comme suit : forfait de base + consommation : abonnement téléphonique, abonnement à un contrat énergétique…
  • Abonnement à un service, sans date de fin, avec tacite reconduction et évolution annuelle du prix

Points d’attention

  • Le montant de la 1ère transaction doit être cohérent avec les transactions suivantes
    • Ex : un client souscrit à un service dont le forfait mensuel est de 30 euros et dont la consommation estimée est de 15 euros en moyenne à La première transaction devrait être de 45 euros.
    • Le commerçant peut capturer partiellement la 1ère transaction si nécessaire.
  • Les montants des transactions suivantes peuvent correspondre à une évolution de X% du montant de la transaction initiale

Mise en œuvre

Etape 1 : Réalisation d’un paiement avec authentification forte et enregistrement de la carte

Utilisation du backoffice

L’opérateur saisie les informations de carte dans le back-office.

Utilisation de PaySSL.aspx – non recommandé mais disponible

  • Requête
    • Enregistrement de la carte : Objet JSON credentialOnFile
      • "unscheduled": "CIT"
      • "initialPayment": true
    • Réponse
      • Récupération de l'objet JSON Card

Etape 2 – n : Transactions suivantes effectuées en Server-to-server – direct.aspx

  • Requête
    • Utilisation de la carte : Objet JSON credentialOnFile
      • "unscheduled": "MIT"
      • "initialPayment": false
    • Carte : Objet JSON Card

Les transactions peuvent être effectuées via API (Server-to-Server – direct.aspx) ou via Batch.

7.    Le 3DS V2

La réglementation RTS (Standards Réglementaires et Techniques) liée à la DSP2 (Directive sur les services de paiement) impose l’utilisation du processus d’authentification pour l’ensemble des paiements e-commerce initiés par le porteur de carte.

L’objectif est de répondre aux exigences de l'authentification forte du client (Strong Customer Authentication) pour minimiser le risque pour le commerçant tout en veillant à simplifier et fluidifier le parcours des utilisateurs.

Si besoin, vous pouvez consulter notre documentation dédiée au 3DS V2 : https://docs.axepta.bnpparibas/display/DOCBNP/3D+SECURE

7.1.  Informations générales

7.1.1.      Les exemptions (« Frictionless ») pour le commerçant

Dans le cadre de cette nouvelle réglementation, certains cas de paiements peuvent bénéficier d’exemption à l’authentification forte du client tels que :

  • Les paiements récurrents : Le paiement initial nécessite une authentification forte cependant les paiements suivants seront exemptés. Dans le cas d’un changement de montant de l’abonnement, l’acheteur devra de nouveau passer par une procédure d’authentification forte.
  • Les transactions MoTo (Mail Orders and Telephone Orders): ce type de transaction n’est pas considéré comme un paiement électronique.

 

  • Les transactions à faible montant(inférieur à 30€) : Les banques doivent toutefois demander une authentification si l’exemption a été utilisée cinq fois depuis la dernière authentification réussie du titulaire de la carte ou si la somme des paiements exemptés précédemment dépasse 100 €.

 

  • Les listes blanches (whitelist): Un porteur de carte peut désigner un commerçant comme un bénéficiaire de confiance pour lequel il ne souhaite pas réaliser une authentification forte lors de l’exécution de transactions à distance. Il pourra également retirer le commerçant à tout moment. Cette exemption nécessite d’être déployée par l’émetteur de la carte du client (via l’appli bancaire du porteur par exemple).

 

  • Les paiements par carte d’affaires: les paiements initiés par les entreprises avec débit du compte de l’entreprise (par exemple, cartes logées, comptes centralisés et cartes virtuelles) seront exemptés.

 

  • Les transactions à faible risque (TRA : Transaction Risk Analysis) : une dérogation à l’obligation d’authentification forte peut être accordée. Pour cela, il faut l'accord préalable de l'acquéreur (sur la base d’une analyse de risque en temps réel de chaque opération).

7.1.2.      Quels choix pour le commerçant ?

Le commerçant peut solliciter l’émetteur pour demander ou non une exemption d’authentification forte. Plusieurs choix se présentent à lui :

...

7.1.3.      Gestion des exemptions (du « Frictionless »)

Dans le cas d’une demande d’exemption, le commerçant doit initier cette demande via sa solution Axepta BNP Paribas. Un flag doit être positionné dans la demande 3D Secure afin d’informer l’émetteur que le commerçant souhaite bénéficier de cette exemption. Et en plus de ce flag, le commerçant devra fournir des données additionnelles.

Le protocole 3DS V2 supporte 150 points de données véhiculées à l'émetteur. Cependant, le traitement des données par les émetteurs va prendre du temps, il est donc recommandé de partager les données essentielles, les plus efficaces, pour l’émetteur.

Données obligatoires

Le commerçant devra obligatoirement transmettre les données suivantes :

  • Les données cartes en respectant les exigences PCI DSS
  • Les données sur les transactions : les numéros d’identification, la devise et le montant.
  • Les données sur le navigateur : Localisation et système de connexion de l’utilisateur (langue, taille de l’écran, adresse IP…)
  • Les données sur le porteur : Nom et prénom de l’utilisateur
  • Les données sur les paiements récurrents (si utilisation de paiements récurrents)

Données facultatives

Certaines données complémentaires sont fortement recommandées pour améliorer l’analyse de risque de la transaction par l’émetteur :

  • Les données sur l’adresse de livraison : ville, code postal, pays…
  • Les données sur les détails de la livraison (date de livraison)
  • Les données sur le compte de l’utilisateur (date de création du compte chez le commerçant, date de réinitialisation du mot de passe, etc)
  • Les données panier (Nombre d’articles dans le panier)
  • Le scoring commerçant

Les données essentielles, que BNP recommande de transmettre, sont les suivantes :

Information du porteur de la carte :

  • Nom et prénom
  • Adresse email
  • Numéro de téléphone fixe
  • Numéro de téléphone portable
  • Adresse de facturation
  • Adresse de livraison

Information sur le navigateur/ Browser (dépend de l’intégration)

  • Adresse IP

La liste complètes des données à transférer se trouve dans la documentation technique via ce lien :  https://docs.axepta.bnpparibas/display/DOCBNP/JSON+Objectbs.

 

A noter : Toutes ces données seront utilisées à des fins de sécurisation du parcours en ligne dans un objectif de lutte contre la fraude. Les banques émettrices sont régulées sur la gestion de ces données confidentielles.

 

7.1.4.      Les garanties pour le commerçant (liability shift)

Dans le cas où l'émetteur accède à la demande d’exemption (frictionless) et n'applique pas l'authentification forte du paiement, le commerçant ne bénéficie plus du transfert de responsabilité (liability Shift).

Dans tous les cas, l’émetteur a systématiquement le dernier mot sur l’application ou non d’une exemption (seules les transactions à faible risque (TRA) nécessitent l’accord préalable de l’acquéreur).

Pour rappel, aucune exemption n’est donc garantie pour le commerçant.

 

 

 

 

7.1.5.      Quelle information 3DS V2 disponible pour le commerçant ?

Le commerçant pourra depuis son Back-Office Axepta, dans le détail de ses opérations, voir le transfert de responsabilité « liability shift » grâce au code ECI. La table qui permet de comprendre ses codes est disponible depuis la documentation technique via ce lien :

 https://docs.axepta.bnpparibas/display/DOCBNP/ECI+Codes

Le code ECI est transmis par la banque émettrice, il indique le niveau d’authentification qui a été mis en place sur la transaction et détermine si la transaction est garantie ou non.

 

7.2.  Implémentation technique

L’objet JSON threeDSPolicy (threeDSPolicy EN - Documentation BNP - Axepta) permet au commerçant de demander une exemption afin d’offrir un parcours frictionless à son acheteur.

Paramètres

  • challengePreference: Indiquer la préférence du commerçant vis à vie de l’authentification
    • noPreference : Le commerçant laisse le choix à l’émetteur d’authentifier l’acheteur.
    • noChallenge : Le commerçant souhaite que l’acheteur ne soit pas authentifier (demande d’exemption, frictionless)
    • requestChallenge : Le commerçant souhaite authentifier l’acheteur. Le choix final reste à l’émetteur.
    • mandateChallenge : Le commerçant demande à l’émetteur d’authentifier l’acheteur (par exemple pour la première transaction d’un abonnement)
  • threeDSExemption – exemptionReason
    • lowValue : Les transactions à faible montant (inférieur à 30 €)
      • Les banques doivent toutefois demander une authentification si l’exemption a été utilisée cinq fois depuis la dernière authentification réussie du titulaire de la carte ou si la somme des paiements exemptés précédemment dépasse 100 €.
    • Les transactions à faible risque (TRA : Transaction Risk Analysis) : une dérogation à l’obligation d’authentification forte peut être accordée. Pour cela, il faut l'accord préalable de l'acquéreur (sur la base d’une analyse de risque en temps réel de chaque opération).
      • Pour bénéficier de cette exemption, le commerçant doit contacter son chargé d’affaires.

8.    Tests

Lors de la souscription à la solution de paiement AXEPTA, le commerçant reçoit un identifiant de test (test MID) lui permettant d’effectuer des transactions dans un environnement de test (sans remise en banque).

Toutes les informations sont disponibles via les liens suivants :

Afin d’effectuer des transactions en production (autorisation, remise en banque, prélèvement des fonds sur le compte de l’acheteur), le commerçant doit utiliser son MID de production fourni lors de l’onboarding.

9.    Reporting

9.1.  Backoffice AXEPTA ONLINE

Le backoffice Axepta est une application web qui offre une vue d'ensemble et un contrôle sur toutes les transactions d’un commerçant. Pour y accéder, le commerçant devra utiliser ses données d’accès (login, mot de passe) reçues dans un mail chiffré.

Les fonctionnalités majeures du backoffice :

  • Visualiser l’ensemble des transactions en détails (date et heure, statut, montant, devise…) et les exporter en CSV
  • Rembourser, annuler, capture des transactions
  • Créer des transactions en Mo/To (transfert batch également possible)
  • Consulter le fichier de réconciliation et l’exporter en CSV
  • Consulter des KPIs dans des graphiques dynamiques
  • Gérer ses listes noires et listes blanches
  • Créer des utilisateurs et leur attribuer des droits

Le backoffice Axepta est disponible via ce lien : https://backoffice.axepta.bnpparibas/

La doc technique du backoffice est disponible via ce lien : https://docs.axepta.bnpparibas/display/DOCBNP/Backoffice+Axepta

Des informations supplémentaires relatives aux transactions 3DS sont décrites dans la documentation suivante : 3DS Back office details - Documentation BNP - Axepta

9.2.  Settlement File - CTSF

9.2.1.      A quoi ça sert ?

Le fichier de réconciliation (Settlement File) regroupe l'ensemble des données des différents moyens de paiement utilisés par le commerçant afin de répondre à ses besoins en matière de rapprochement et de reporting. Les informations de compensation (clearing) et de règlement (settlement) sont récupérées auprès des différents prestataires de services de paiement et acquéreurs.

9.2.2.      Comment l’obtenir ? (Conditions/ Configurations techniques)

Le fichier de réconciliation peut être demandé dès la phase de souscription. Il est disponible tous les jours à 15h :

  • Depuis le backoffice AXEPTA BNP Paribas dans la section « fichier de réconciliation » (le fichier est disponible jusqu’à 60 jours sur le Backofice).
  • Via une connexion SFTP en mode pull (pour la configuration et les informations d'identification de compte comme la clé SSH et la clé PGP, vous serez contacté par le service d'assistance BNP Paribas).
  • Par email (non recommandée car la taille est souvent limitée en cas de large volume de transaction).

9.2.3.      Quels sont les moyens de paiement disponibles.

Les cartes (CB/VISA/MASTERCARD/AMEX), PayPal et tous les moyens de paiement disponibles via PPRO. La liste complète est disponible via ce lien : https://docs.axepta.bnpparibas/pages/viewpage.action?pageId=4653275

9.2.4.      Comment exploiter le fichier ?

Le fichier se présente dans un format CSV (Comma Separated Values – valeurs séparées par des virgules). La structure et le contenu du fichier sont décrits dans la documentation suivante : https://docs.axepta.bnpparibas/pages/viewpage.action?pageId=4653275

9.3.  Smart Data

9.3.1.      A quoi ça sert ?

Il s’agit d’un journal des transactions au format CSV qui regroupe 41 champs de données issues de l’acceptation du paiement.

Le commerçant peut l’utiliser à différentes fins, pour analyser ses paiements, alimenter son dispositif interne (ERP, CRM), réaliser des reportings, etc.

9.3.2.      Comment l’obtenir ? (Conditions/ Configurations techniques)

Le fichier est mis à disposition sur le compte SFTP du commerçant. Pour des raisons de sécurité, il est chiffré (chiffrement en PGP).

Le commerçant contactera le support bnpparibas@computop.com et indiquera ses options concernant la fréquence et la personnalisation des champs (s’il souhaite restreindre le nombre de données du fichier).

  1. Fréquence

Le commerçant peut programmer une mise à disposition du fichier :

  • Quotidienne
  • Hebdomadaire (jour d’envoi choisi par le commerçant)
  • Mensuelle (jour d’envoi choisi par le commerçant)
  1. b) Personnalisation des champs

Le commerçant peut demander à recevoir un fichier personnalisé, ne comportant qu’une partie des champs, à préciser lors de l’inscription.

NB : certains champs ne sont toutefois pas complétés quand la donnée n’est pas disponible (par exemple pour certaines méthodes de paiements).

9.3.3.      Quels sont les moyens de paiement disponibles.

Les informations sont remontées pour tous les moyens de paiements acceptés dans l’offre AXEPTA ONLINE.

9.3.4.      Comment exploiter le fichier ?

Lien vers la documentation technique en ligne :  https://docs.axepta.bnpparibas/display/DOCBNP/Smart+Data

10.           Prévention contre la fraude

10.1.                  Règles anti-fraude

La solution Axepta propose 8 règles de lutte contre la fraude

Règles de vélocité liées aux nombres de transactions/cartes

  • Nombre de transactions par adresse IP : Nombre de transactions effectuées en 24h via une même adresse IP
  • Nombre de transactions par carte: Nombre de transactions effectuées en 24h via la même carte.
  • Nombre de cartes par adresse IP : Nombre de cartes utilisées depuis a même adresse IP en 24h.
  • Paramètres (ID de transaction, numéro de référence de la transaction, adresse mail) : Par défaut, un client ne peut pas utiliser la même adresse email plus de X fois en 24h.

Règles de Géolocalisation

  • Origine de la carte : Liste des codes pays bloqués. Si l’acheteur essaye d’utiliser une carte émise par un pays référencé dans ce filtre, la transaction sera bloquée.
  • Origine de l’adresse IP: Liste des adresses IP bloquées. Si l’acheteur essaye d’effectuer une transaction depuis une adresse IP référencée dans ce filtre, la transaction sera bloquée.

Règles liées aux montants des transaction

  • Adresse IP et Montant : Montant (1 ou plusieurs transactions) qu’un client ne peut pas dépasser depuis la même IP en 24h. Par défaut, un client ne peut pas dépasser 3000 euros de transactions depuis la même adresse IP en 24h.
  • Nombre de carte et Montant : Montant (1 ou plusieurs transactions) qu’un client ne peut pas dépasser via la même carte en 24h.

Ces règles peuvent être modifiées sur demande à votre chargé d’affaires.

10.2.                  Black / White lists

Le commerçant peut se rendre dans la rubrique « Lutte contre la fraude » dans le back-office pour gérer manuellement les listes noires et les listes blanches C’est-à-dire que la solution permet de bloquer les clients suspicieux (dans une liste noire) et de répertorier les clients de confiance (liste blanche).

Nous distinguons les listes dont les données sont alimentées manuellement par le commerçant et les listes générées automatiquement par la solution de paiement (appelées securePay dans le backoffice) selon les critères définis par le commerçant (règles anti-fraude).

...

Liste noire/blanche

...

Liste noire/blanche SecurePay

...

Alimentation de la liste

...

·       Manuelle par le commerçant.

...

·       Automatique par la solution Axepta selon les critères prédéfinis par le commerçant (règles anti-fraude).

...

Action par le commerçant

...

·       Ajout de numéro de carte, token (pseudo numéro de carte), IBAN, ID appareil…

·       Ajout d’un fichier CSV

·       Suppression d’une entrée de la liste

·       Consultation

...

·       Consultation

·       Désactivation/Activation d’un blocage

10.3.                  Techniquement

Il existe des paramètres additionnels permettant de renforcer la lutte contre la fraude en faisant appel à la plateforme de paiement. Les paramètres sont décrits dans la documentation suivante :

https://docs.axepta.bnpparibas/pages/viewpage.action?pageId=4653280