| Tip | ||
|---|---|---|
| ||
AXEPTA est une solution de paiement basée sur une API HTTPS POST / GET utilisant des paramètres en méthode NVP (Name-Value-Pairs) et des objets JSON . La sécurisation des échanges est effectuée via l'usage d'authentification HMAC et l'utilisation de cryptage blowfish. |
| Table of Contents |
|---|
Ressources pour développeurs
La section Ressources pour développeurs regroupent les éléments vous permettant de réaliser l'intégration technique d'Axepta Online.
| Info | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
La section Liste des données Axepta regroupe les données utilisées par la plateforme : codes retours, données 3DS, objets JSON
| Info | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Sécurisation
Authentification HMAC
Pour vous protéger contre toute manipulation non autorisée de vos transactions de paiement, la plate-forme Axepta vérifie à l'aide d'un code d'authentification de message haché (HMAC) si votre demande de paiement est authentique et n'a pas été modifiée.Pour cela, vous transférez une valeur HMAC à la Plateforme à chaque transaction dans le paramètre MAC.
La plateforme Axepta utilise un Hash Message Authentication Code (HMAC) pour vérifier l'authenticité de vos paiements. L'algorithme MAC SHA-256 est utilisé avec une longueur de clé à 32 chiffres (256 bits).
Pour plus de détails : HMAC Authentication (Request) et HMAC Authentication (Notify)
Blowfish ECB
Blowfish est un algorithme de chiffrement symétrique (c'est-à-dire « à clef secrète »).
Pour faciliter votre intégration, vous trouverez ci-dessous quelques exemples de librairies Blowfish ECB
| Techno | Exemples |
|---|---|
| ASP | txmsCrypto.dll // txmsCrypto.BlowFish |
| ASP.NET | Computop.Core.Crypto.dll // Axepta.Core.Crypto.BlowFish |
| Java | Blowfish.java |
| PHP | function.inc.php
|
Construire une requête de paiement
Concepts techniques et création d’une requêteConcepts
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)
- Utilisation d'objets JSON
- Le calcul d'un HMAC
- 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.
Etapes de création d’une requête de paiement
Les étapes de création d’une requête sont :
- Calcul du HMAC pour sécuriser le montant et la devise
- Chaîne de caractère à chiffer avec la clé HMAC : PayID*TransID*MerchantID*Status*Code Certaines valeurs peuvent être laisser vide- cf. HMAC Authentication (Request)
- Construire les objets JSON et les encoder en Base64 avec padding - cf. Fonctionnalités de paiement
- Assembler les paramètres (clé / valeur, objets JSON) de l'API
- Chiffrer tous les paramètres de l’API avec la clé Blowfish : 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, les customFields)
- Envoyer la demande d’API au endpoint choisi
Documentation en ligne associée
Technical Integration Guide - Documentation BNP Paribas - Axepta
https://docs.axepta.bnpparibas/display/DOCBNP/Create+an+API+call+and+samples+to+play
Intégration de la 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 :
- Hébergée par Axepta, dans ce cas le commerçant utilise la paymentPage : Hosted Payment Page (HPP) - paymentpage.aspx)
- Créée et hébergée par le commerçant
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.
| Info |
|---|
Le commerçant doit ajouter, le cas échéant, les paramètres spécifiques des moyens de paiement alternatifs qu'il souhaite proposer. |
Intégration du paiement par carte uniquement
Réponse
Axepta Online utilise les méthodes POST et GET pour rediriger l'utilisateur vers le site e-commerce du marchand ou envoyer la notification du résultat du paiement
Moyen de paiement choisi par l'acheteur | Format des réponses |
|---|---|
Paiements carte | Méthode POST pour l’URLFailure / URLSuccess / URLNotify Méthode GET pour l’URLFailure / URLSuccess / URLNotify en cas de fallback 3DSV1 |
Moyens de paiement alternatifs | Méthode GET pour l’URLFailure / URLSuccess / URLNotify |
Exemple pas à pas
| Tip |
|---|
La page Créer une requête de paiement pas à pas permet de réaliser un premier paiement via la boutique de démo BNP_DEMO_AXEPTA. Cela peut être une première étape avant d'utiliser votre MID. |
Etape 1 : Implémentation de l’appel à l’interface souhaitée
PaySSL : Credit Card Form (payssl.aspx)
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 :
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
Le commerçant accède au template XLST Axepta et procède aux modifications qu’il souhaite.
Ce template est ensuite fourni au helpdesk afin qu’il soit hébergé sur Axepta
Tous ces éléments sont précisés dans la section : Customize checkout experience
Etape 4 : Gestion de la réponse et redirection du porteur
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.
La plateforme notifie le serveur du commerçant via une requête en POST sur l’URL Notify.
| Info | ||
|---|---|---|
| ||
|
Intégration des moyens de paiement alternatif - Exemple : 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 Paribas - 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 :
- Pour un compte de production : PayPal - Documentation BNP Paribas - Axepta
- Pour un compte de test (sandbox) : PayPal - Documentation BNP Paribas - Axepta
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.