Description

Un

Description

Suite au changement de la règlementation en vigeur, pour tous clients ayant un abonnement en cours avec vous, vous devrez chaîner les transactions.

Nous allons donc chaîner les transactions futur afin que vous puissiez continuer votre abonnement avec le client, tout en gardant la même expérience cliente pour lui.

Nous avons deux actions à effectuer de figure :

vigueur, associé à la DSP2, impose désormais que les transactions relatives à un abonnement / paiement récurrent soient rattachées à une transaction d'initialisation du chaînage (cf. schéma). On parlera alors de chaînage des transactions.

Cette section aborde la mise en place du chaînage sur des abonnements Axepta Online initialisés en 3DSV1 avant le 01/01/2022.

La mise en place de ce chaînage passe par la gestion d'un paramètre supplémentaire dans les requêtes de paiement, le schemeReferenceID, qui contiendra la valeur permettant de chaîner les transactions.

La mise à jour des abonnements passe par 2 étapes :

1. Initialisation du chaînage (par exemple en janvier) : Envoi d'une requête de paiement contenant une valeur de chaînage définie Vous allez envoyé une requête avec une valeur de chaînage défini par la marque de la carte du client (CB, VISA, MC)
   1. Réponse :
      1. Vous récupérer la nouvelle valeur de chaînage qui sera unique pour chaque client
2. Pour les prochaines transactions, il faudra utiliser cette valeur de chaînage reçus en réponse ( i ) afin de lier les transactions.
3. cf. section implémentation de cette page) et récupération de la valeur de chaînage envoyée par la banque du porteur qui sera conservée par le marchand
   
4. Envoi de transactions chaînées (par exemple en février, en mars...) : Envoi d'une requête de paiement contenant la valeur de chaînage reçue en réponse de la transaction d'initialisation du chaînage.
   

Principe

• Un client réalise une souscription chez un marchand via un abbonement avant la mise en place du 3DSV2, et il veut continuer son abbonement avec vous.
• Le nouvelle reglementation rentre en vigeur ( 01/01/2022 )
• Le marchand envoi une transaction avec une valeur de chaînage défini par la marque de carte du client (CB, VISA, MC)
• Réponse :
  • La valeur retour de la valeur de chaînage est différent de la valeur initiale → C'est cette nouvelle valeurqu'il faudra utiliser pour les prochaines transactions d'abbonement.

Schéma

Image Removed

Schéma

Image Added

Chaînage des transactions initiées en 3DSV1

Prérequis

• Vous proposez l'abonnement / paiement récurrent par carte
• Des clients ont réalisés leur souscription initiale avant le 01/01/2022
• Vous

Prérequis

• Vous proposez le paiement par carte de crédit
• Des clients ont réalisés leurs souscriptions avant le changement de réglementation
• Vous êtes en possibilité de stockez le pseudo card number (Le marchand doit être PCI DSS compliant pour stocker le pseudo card numberPCNr)
• Vous êtes en possibilité de stockez le schemeReferenceID  (nom du champ pour la valeur de chaînage défini par la marque de la carte du client) que vous allez recevoir en réponse dans les prochaines transactions chaînés.

Implementation

Etape 1 (3DSV1) :

Axepta Online endpoint

Le paiement peut être effectué par le commerçant avec les endpoint suivants :

• Server-to-server - direct.aspx

• Batch - Batch integration

Requête

Le tableau suivant décrit les paramètres supplémentaires de requête de paiement chiffré qui doivent être ajoutés :

PCNr

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.

Le PCNr est une valeure reçu en réponse par la plateforme, il remplacera le CCNr dans la requête ou dans la partie card-JSON.

CCNr

Numéro de la carte (minimum 12 chiffres) sans espaces

CCBrand

a..22

M

CCExpiry

n6

M

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

RTF

a1

M

Pour un paiement récurrent (abonnement) :

I = paiement initial pour le nouvel abonnement

R = paiement récurrent

→ Pour ce cas, utilisez "R"

schemeReferenceID

• allez stocker le schemeReferenceID reçu en réponse de la transaction d'initialisation du chaînage

Implémentation du chaînage

Objectif

Mettre en place le chaînage sur des abonnements Axepta Online initialisés en 3DSV1 avant le 01/01/2022.

Exemple

• Echéance Janvier → Initialisation du chaînage avec valeur de chaînage standard définie par la marque de la carte du porteur et récupération du schemeReferenceID en réponse (Implémentation : cf. Etape 1)
• Echéance Février → Transaction chaînée c'est-à-dire qui contient en paramètre le schemeReferenceID récupérée de la réponse de la transaction d'initialisation du chaînage (Implémentation : cf. Etape 2)
• Echéances Mars et suivantes  → Transaction chaînée c'est-à-dire qui contient en paramètre le schemeReferenceID récupérée de la réponse de la transaction d'initialisation du chaînage (Implémentation : cf. Etape 2)

Etape 1 : Initialisation du chaînage

La création d'une nouvelle échéance d'un abonnement (paiement récurrent) peut être effectuée via

Pour la première transaction, le marchand doit utiliser les valeurs définis par les schemes.

CB : 9999999999999 - 13 chiffres

VISA: 887001863998888 - 15 chiffres

MasterCard: 1231_MCC999999 - 13 chiffres 

Réponse :

• Nous recevrons la nouvelle valeure pour le schemeReferenceID dans la réponse de cette transaction
• Cette valeur sera utilisée dans toutes les transactions MIT suivantes (Step 2)

Etape 2 (3DSV1) :

Axepta Online endpoint

Le paiement peut être effectué par le commerçant avec les endpoint suivants :

• Server-to-server - direct.aspx

• Batch - Batch integration

Requête

Le tableau suivant décrit les paramètres supplémentaires de requête de paiement chiffré qui doivent être ajoutés :

CNr

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.

Le PCNr est une valeure reçu en réponse par la plateforme, il remplacera le CCNr dans la requête ou dans la partie card-JSON.

CCNr

Numéro de la carte (minimum 12 chiffres) sans espaces

CCBrand

a..22

M

CCExpiry

n6

M

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

RTF

a1

M

Pour un paiement récurrent (abonnement) :

I = paiement initial pour le nouvel abonnement

R = paiement récurrent

→ Pour ce cas, utilisez "R"

schemeReferenceID

On récupère la valeur dans la réponse de paiement de "Etape 1" afin que les systèmes en aval puissent chaîner les deux transactions en conséquence.

Etape 1 (3DSV2) :

Axepta Online endpoint

Le paiement peut être effectué par le commerçant avec les endpoint suivants :

• Server-to-server - direct.aspx

• Batch - Batch integration

Requête

Le tableau suivant décrit les paramètres supplémentaires de requête de paiement chiffré qui doivent être ajoutés : le paramètre supplémentaire chiffré à ajouter aux requêtes de paiement :

Réponse

credentialOnFile

Objet précisant le type et la série de transactions à l’aide des identifiants de compte de paiement (ex : numéro de compte ou TOKEN) qui sont stockés par un commerçant pour traiter les achats futurs d’un client.

{

"type": {

"unscheduled": "MIT"

},

"initialPayment": false

}

Réponse :

Etape 2

Axepta Online endpoint

: Création de transactions chaînées

La création d'une nouvelle échéance d'un abonnement (paiement récurrent) peut être effectuée via Le paiement peut être effectué par le commerçant avec les endpoint suivants :

• Server-to-server - direct.aspx

• Batch - Batch integration

Requête

Le tableau suivant décrit les paramètres supplémentaires de requête de paiement chiffré qui doivent être ajoutés : le paramètre supplémentaire chiffré à ajouter aux requêtes de paiement :

Réponse

Le champ schemeReferenceID peut être valorisé dans la réponse d'un paiement récurrent, mais cette valeur ne doit pas être réutilisée.

Seule la valeur reçue dans la réponse de la requête d'initialisation du chaînage doit être stockée et réutilisée dans toutes les échéances suivantes de l'abonnement (paiement récurrent).