Description
Un changement de la règlementation en vigeur, impose désormais que les transactions relatives à un abonnement soient rattachées à une transaction existante. On parlera alors de chaînage des transactions.
Cette section aborde la mise en place du chaînage sur des abonnements déjà en cours au 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 a jour des abonnements passe par 2 étapes :
- Initialisation du chaînage (ex: Janvier) : Envoi d'une requête de paiement contenant une valeur de chaînage définie par la marque de la carte du client (CB, VISA, MC) et récupération de la valeur de chaînage à conserver
- Envoi de transactions chaînées (ex : Février, 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.
| Info | ||
|---|---|---|
| ||
Le chaînage des transactions est également à mettre en place pour les abonnements souscrits à partir du 01/01/2022. Pour la mise en place d'un nouvel abonnement se référer à la page suivante : Paiement récurrent (Abonnement) / One click |
Schéma
Prérequis
Vous avez réalisé l'implémentation d'Axepta sans gérer le paramère "- Vous proposez le paiement par carte
- Des clients ont réalisés leurs souscriptions avant le changement de réglementation
- Vous stockez le pseudo card number
- Vous allez stocker le schemeReferenceID reçu en réponse de la transaction d'initialisation du chaînage
Implémentation
- Disponible pour les implémentations réalisées avec ou sans le paramètre 'msgVer=2.0
- ' (3DSV2)
Implémentation
Initialisation du chaînage
La requête de paiement peut être effectuée via :
Server-to-server - direct.aspx
Batch - Batch integration
Requête
Le tableau suivant décrit le paramètre supplémentaire chiffré à ajouter aux requêtes de paiement :
| Parameter | Format | CND | Description |
|---|---|---|---|
| ans..64 | M | Donnée de chaînage des transactions dnans le cadre des abonnements effectués par carte Lors de l'initialisation du chaînage, il est nécessaire d'utiliser les valeurs définis par les réseaux CB, Visa, Mastercard. CB : 9999999999999 - 13 chiffres VISA: 887001863998888 - 15 chiffres MasterCard: 1231_MCC999999 - 13 chiffres |
Réponse :
- Un nouveau schemeReferenceID sera présent dans la réponse de la transaction
- Cette valeur est à stocker et sera utilisée dans toutes les transactions suivantes de cet abonnement
Création de transactions chaînées
Axepta Online endpoint
Le La requête de paiement peut être effectué par le commerçant avec les endpoint suivants effectuée via :
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 :
n16
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
| Note |
|---|
| Le marchand doit être PCI DSS compliant pour stocker le CCNr |
le paramètre supplémentaire chiffré à ajouter aux requêtes de paiement :
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"
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 :
| Parameter |
|---|
| Format | CND | Description |
|---|
{
"type": {
"unscheduled": "MIT"
},
"initialPayment": false
}| ans..64 | M |
Extrait du paiement initial et utilisé dans la transaction suivante afin que les systèmes en aval puissent chaîner les deux transactions en conséquence.
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
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 :
- 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 (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 :
Donnée de chaînage des transactions dnans le cadre des abonnements effectués par carte |