Page History

Introduction

Le Contrôle des doublons dans Duplication check in Axepta BNP Paribas Online est conçu pour détecter et gérer les tentatives de paiement en double sur plusieurs canaux is designed to detect and manage duplicate payment attempts across multiple channels (API, HPP, etc.).

Elle garantit que les utilisateurs et les commerçants ne déclenchent pas accidentellement plusieurs paiements avec des paramètres identiques, y compris les cas où un paiement est déjà en cours.

Objectifs du Contrôle de Duplication

Les doublons peuvent provenir de plusieurs causes :

• Erreurs d'interaction utilisateur (par exemple, rafraîchissement, double-clic, fermeture de l'onglet)
• Problèmes de logique côté commerçant (par exemple, boucles de réessai)
• Latence du réseau ou délais d'attente entraînant une incertitude sur le statut du paiement
• Tentatives de paiement encore en cours lorsque une nouvelle demande est soumise

Configuration 

Le marchand doit choisir les éléments suivants qui seront configurés côté Axepta BNP Paribas Online : 

• Profondeur de l'historique dans laquelle on vérifie qu'il y a un doublon : 1 heure à 4 jours (en heures)
  • La profondeur de l'historique fait référence à la période de temps pendant laquelle le système conserve et analyse les données des transactions passées pour détecter les tentatives de paiement en double. Cette profondeur est paramétrable et peut varier de 1 heure à 4 jours, selon les besoins et les configurations spécifiques du commerçant. Elle permet de comparer les nouvelles transactions avec celles enregistrées dans cet intervalle de temps pour éviter les paiements redondants.
• Périmètre : 1 ou plusieurs MID
• Prise en compte des paiements "en cours" : oui/non

Fonctionnement

1. Vérification

Les vérifications de duplication sont déclenchées avant l'affichage de la page de paiement et entre les pages de paiement :

• Si une duplication est détectée, l'utilisateur est redirigé sur l'url Failure
• Aucun paiement n'est soumis si la demande correspond à une transaction existante ou en cours

Une transaction échouée ne déclenchera pas de détection de doublons.

2. Mise en œuvre

Option 1 : Paiement réalisé via la Page de choix du moyen de paiement (HPP) ou le formulaire de paiement par carte (payssl)

Il est nécessaire d'ajouter au moins un des paramètres suivants dans l'appel aux API /payments/sessions et /payments :

• order.​merchantReference
• order.​invoiceId

Option 2 : Vérification de Duplication via API – à venir

L'API Axepta Online fournit un endpoint permettant aux commerçants de vérifier si une transaction est une duplication avant de la soumettre :

• Endpoint: à venir 
• Paramètre :  `merchantReference` ou `invoiceId` (obligatoire), `Amount`, `Currency`.

3. Format de Réponse

L'API retourne un statut indiquant si une transaction est une duplication :

It ensures that users and merchants do not accidentally trigger multiple payments with identical parameters, including cases where a payment is already in progress.

Objectives of Duplication check

Duplicates can originate from several causes :

• User interaction errors (e.g., refresh, double-click, tab closure)

• Merchant-side logic issues (e.g., retry loops)

• Network latency or waiting times causing uncertainty about the payment status

• Payment attempts still in progress when a new request is submitted

Configuration

The merchant must choose the following elements, which will be configured on the Axepta BNP Paribas Online side :

• Historical depth in which duplicates are checked: 1 hour to 4 days (in hours)

  • Historical depth refers to the period during which the system retains and analyzes past transaction data to detect duplicate payment attempts. This depth is configurable and can range from 1 hour to 4 days, depending on the merchant's needs and specific configurations. It allows comparing new transactions with those recorded within this timeframe to avoid redundant payments.

• Scope: 1 or multiple MID

• Consideration of "in progress" payments: yes/no

Operation

1. Verification

Duplicate checks are triggered before the payment page is displayed and between payment pages:

• If a duplicate is detected, the user is redirected to the Failure URL

• No payment is submitted if the request matches an existing or in-progress transaction

A failed transaction will not trigger duplicate detection.

2. Implementation

Option 1: Payment made via the Payment Method Selection Page (HPP) or Card Payment Form (payssl) It is necessary to add at least one of the following parameters in the API calls to /payments/sessions and /payments:

• order.merchantReference

• order.invoiceId

Option 2: Duplicate Verification via API – Coming Soon The Axepta Online API provides an endpoint allowing merchants to verify if a transaction is a duplicate before submitting it:

• Endpoint: coming soon

• Parameter: merchantReference or invoiceId (required), Amount, Currency.

3. Response Format

The API returns a status indicating whether a transaction is a duplicate :

 If a duplicate is detected, the response also includes details of the existing transaction  Si une duplication est détectée, la réponse inclut également les détails de la transaction existante (PayID, TransactionID, Date, etc.).