Description
Suite au changement de la règlementation en vigeur, pour tous clients ayant un abbonement, vous devrez chaîner les transactions.
Nous allons donc chaîner les transactions initialisés en 3DS V1.0, on verra deux cas d'usages différents :
futur afin que vous puissiez continuer votre abbonement avec le client, tout en gardant la même expérience cliente pour lui.
Nous avons deux actions à effectuer de figure :
- 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)
- Réponse :
- Vous récupérer la nouvelle valeur de chaînage qui sera unique pour chaque client
- Réponse :
- Pour les prochaines transactions, il faudra utiliser cette valeur de chaînage reçus en réponse ( i ) afin de lier les transactions.
| Info |
|---|
Pour la mise en place d'un nouvel abbonement se référer à la page suivante : Paiement récurrent (Abonnement) / One click |
Principe
- Un client réalise une souscription chez un marchand avec une transaction MIT via un abbonement avant la mise en place du 3DSV2, et il veut continuer son abbonement avec vous.
- Le 3DS V2.0 nouvelle reglementation rentre en vigeur ( 01/01/2022 )
- Le marchand envoi une transaction MIT avec une valeur de chaînage (schemeReferenceId) défini par le scheme.défini par la marque de carte du client (CB, VISA, MC)
- Réponse :
- La valeur retour du schemeReferenceId de la valeur de chaînage est différent de la valeur initiale → C'est cette nouvelle valeur pour le schemeReferenceId quvaleurqu'il faudra utiliser pour les prochaines transactions MITd'abbonement.
Schéma
Prérequis
- Vous proposez le paiement par carte de crédit
- Des clients ont réalisés leurs souscriptions avant l'implémentation 3DSV2.
- Vous utilisez et stockez le pseudo card number
- Vous utilisez et stockez le schemeReferenceID 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 :
| Parameter | Format | CND | Description | ||
|---|---|---|---|---|---|
| CCNr or PCNr | n16 | M | 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 | Désignation de la marque de carte | ||
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" | ||
| ans..64 | M | Identification de transaction spécifique au scheme de carte requise pour les paiements chaînés ultérieurement, les autorisations retardées et les remises 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 :
| Parameter | Format | CND | Description | ||
|---|---|---|---|---|---|
| CCNr or PCNr | n16 | M | 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 | Désignation de la marque de carte | ||
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" | ||
| ans..64 | M | 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 :
| Key | Format | CND | Description | Exemple |
|---|---|---|---|---|
| card | JSON | M | Données de la carte | -- |
| ans..64 | M | Identification de transaction spécifique au scheme de carte requise pour les paiements chaînés ultérieurement, les autorisations retardées et les remises 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 | -- | |
| JSON | M | 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 :
| Key | Format | CND | Description | Example |
|---|---|---|---|---|
| card | JSON | M | Données de la carte | -- |
| ans..64 | M | 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. | -- | |
| JSON | M | 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 } |