Cette documentation fournit des bonnes pratiques pour l'utilisation de certains champs, afin de garantir l'unicité et la cohérence des identifiants tout au long du processus de paiement.
Elle propose aussi des conseils techniques d'implémentation.


Cette section de la documentation en ligne explique comment identifier et gérer les paiements au sein de la plateforme Axepta BNP Paribas Online. Elle détaille les différents champs utilisés pour identifier un paiement, tant du côté du commerçant que du côté de la plateforme de paiement.

Définitions :

  • Paiement : Un paiement est un processus de paiement constitué de plusieurs actions. Chaque action correspond à une étape du paiement (ex : authentification, autorisation, capture, crédit).
  • Action : Une action est une étape spécifique du processus de paiement, identifiée par un xId.


Identification du paiement

Côté Commerçant

Il existe 2 champs coté marchant, servant à identifier le paiement:

  • transId : Transaction Identifiant
  • refNr: Reference Number


Le transId (identifiant de transaction) est propre au system d'information du commerçant. Il doit être unique, et respecter le format 'ans64': 64 charactères alphanumériques et spéciaux

Il n'est échangé qu’entre le commerçant et la plateforme de paiement.


Le refNr (Reference Number) sert à identifier le paiement durant tout son cycle de paiement, jusqu’à l'acquéreur.

Le format de ce champ dépend du moyen de paiement utilisé, et pour assurer son traitement tout au long de la chaine, il doit respecter le format : 'an12' : 12 charactères alphanumériques, pas de caractères spéciaux.

Axepta BNP Paribas Online valorisera cette donnée en garantissant son unicité.



Best Practice:

  • Le transId doit être utiliser pour lier le paiement avec votre system d'information.
    • Si vous n'avez pas de contrainte particulière sur cette donnée, il est conseillé d'utiliser un uuid-v4 pour garantir son unicité.
  • Le refNr est renseigné par Axepta BNP Paribas Online afin de garantir une valeur garantie unique
    • Si vous le souhaitez, vous pouvez envoyer cette donnée mais vous devez respecter le format et garantir son unicité.



Côté Axepta BNP Paribas Online

Il existe 2 paramètres: 

  • payId: identifiant du paiement généré par Axepta BNP Paribas Online
  • xId: Identifiant d'une action


Le champ payId (Payment Id) est utilisé pour identifier le paiement sur Axepta BNP Paribas Online:

  • Cette donnée est générée par Axepta BNP Paribas Online et est garantie unique.
  • Il reste constant tout au long du cycle de vie de la transaction (autorisation, capture, crédit, annulation...)
  • Elle est retournée via les url de feedback (return, cancel et webhook).
  • Le PayId est requis pour toute opération complémentaire sur la transaction, comme par exemple la capture manuelle ou l'annulation.
  • Il est aussi fortement conseillé d'utiliser cette donnée pour récupérer le statut de la transaction. (cf. requêtes: GET /payments/getByPayId/<id> ou  GET /payments/getByTransId/<id>)


Le champ xId identifie lui l'action ou l'opération effectuée sur le paiement, qui va amener à un changement d'état de cette dernière.

  • Un même paiement peut avoir plusieurs actions / opérations, et donc, plusieurs xId.
  • Cette données est générée par Axepta BNP Paribas Online et est garantie unique.


Données métier du marchand

Identifiant de la commande et de la facture

L'identification du paiement est portée par l'objet 'order' et 2 de ses champs sont importants pour le traitement de la transaction :

  • order.merchantReference: cette donnée doit être utilisé pour identifier la commande, elle est définie par le commerçant.
  • order.invoiceId: l'identifiant de la facture associé à ce paiement, elle est définie par le commerçant.


"order": {
      "merchantReference": "112-445-34567",
      "numberOfArticles": 1,
      "creationDate": "2025-03-31T11:58:37Z",
      "invoiceId": "555-333-2222",
      "items": [
        {
          "id": "1",
          "sku": "19-402-DEU",
          "name": "BatteryPowerPack",
          "quantity": 1,
          "quantityUnit": "pcs",
          "taxRate": 0,
          "netPrice": 1000,
          "grossPrice": 1000,
          "taxAmount": 0,
          "discountAmount": 0,
          "description": "BatteryPowerPack",
          "type": "physical",
          "productInfo": {
            "brand": "Intel",
            "categories": [
              "Electronics Store",
              "Computers",
              "Desktops"
            ],
            "globalTradeItemNumber": "EAN",
            "manufacturerPartNumber": "BOXNUC5CPYA",
            "imageUrl": "https://www.exampleobjects.com/logo.png",
            "productUrl": "https://www.estore.com/products/f2a8d7e34"
          }
        }
      ]
    },



  • Ces 2 données sont affichées sur la page de paiement.
  • Au moins une de ces données est nécessaire si vous voulez activer le contrôle des doublons.
  • Elles doivent tous les deux respecter le format ANS30: 30 charactères, alphanumérique ou spéciaux.



Identifiant du client

Les données relatives au client sont transportées dans l'objet 'customerInfo' et les 2 champs suivants sont particulièrement importants:

  • email: indispensable au traitement de la transaction (envoi du mail de confirmation de paiement, réglementation Visa, recherche de transactions)
  • merchantCustomerId: nécessaire pour la fonctionnalité Wallet / Customer Vault


"customerInfo": {
      "merchantCustomerId": "cus_1234567890abcdef",
      "customerType": "individual",
      "firstName": "Max",
      "lastName": "Mustermann",
      "email": "customer@example.com",
      "phone": {
        "countryCode": "+49",
        "number": "1236547890"
      },
      "salutation": "Ms",
      "title": "Dr",
      "gender": "female",
      "maidenName": "Mustermann",
      "middleName": "sam",
      "birthDate": "2001-01-01",
      "birthPlace": "Bamberg",
      "socialSecurityNumber": "123443534"
    },



Données propriétaire du marchant

Il est possible de transmettre des données métier non liées au paiement lors des requêtes initiant le paiement.
(requêtes POST /payments/sessions ou GET /payments ) 

Ces données seront retournées lors de la réponse à la requête de paiement, et lors des demande d'information sur la transaction.
(requêtes: GET /payments/getByPayId/<id> ou  GET /payments/getByTransId/<id> )


Ces données sont transportées dans l'objet 'metadata' et doivent respecter les contraintes suivantes:

  • Doit respecter le format JSON.
    Le champs metadata doit être un object JSON valide, sinon, l'ensemble de la requête de paiement sera refusée.
  • Ne doit contenir que des paires "cle":"valeur" de type string
    Pas d'entier, pas de sous objet...
  • Ne doit pas comporter de données propre au paiement.
    Ce champ n'est pas protégé au sens des règlementations pci / gdpr.
    Il est de la responsabilité du marchant de ne pas mettre de données sensibles dans ce champs, comme des données d'identification du client (noms, adresse...), ou des données relatives au moyen de paiement utilisé.
    (les données nécessaires au paiement doivent être portées par les champs dédiées de la requête).



"metadata": {
    "userData": "my user data",
    "plain": "some plain text",
    "key1": "value1",
    "key2": "value2"
  }



Conseils d'implémentation


Idempotence

Le serveur REST API v2 d'Axepta BNP Paribas Online est idempotent: il ne traite la même requête qu'une seule fois.
Si de multiples requêtes identiques sont reçues, la même réponse sera renvoyée sans générer une nouvelle opération coté serveur.
Cette fonctionnalité permet d'éviter les doublons en cas de répétition du message de paiement.

Pour les messages POST et PATCH,  l'idempotence est garantie par l'utilisation du header http 'Idempotency-Key'

Sa valeur doit être unique par requête http émise vers le serveur, et il est de la responsabilité du client la générer.
Il est conseillé d'utiliser un uuid-v4 pour ce header http.


Authentification


Toutes les requêtes au serveur Axepta BNP Paribas Online doivent être authentifiées.

L'authentification doit se faire en utilisant le protocole OAuth-V2.
Le token d'accès retourné par la plateforme Axepta est valable 1 heure.
Passé ce délai, vous devez refaire une authentification pour avoir un token valide.

La connexion à l'API rest de Axepta doit être faite en TLS 1.2

Si vous avez une impossibilité technique à mettre en œuvre le protocole OAuth-V2, il est possible d'utiliser l'authentification basic.
Cette solution est néanmoins déconseillée, car moins sécurisée, et moins évolutive.