Introduction
Sherlock's est une solution de paiement de commerce électronique multicanale sécurisée conforme à la norme PCI DSS. Elle vous permet d’accepter et de gérer des transactions de paiement en prenant en compte les règles métier liées à votre activité (paiement à la livraison, paiement différé, paiement récurrent, paiement en plusieurs fois…).
L'objectif de ce document est d'expliquer la mise en œuvre de 3-D Secure pour les moyens de paiement CB, VISA, MASTERCARD, Bancontact et AMEX jusqu'au démarrage en production.
A qui s’adresse ce document
Ce document s’adresse aux commerçants et à leurs équipes techniques qui souhaitent mettre en place 3-D Secure sur leur site de commerce électronique, pour les moyens de paiement CB, VISA, MASTERCARD, Bancontact et AMEX.
Pour avoir une vue d’ensemble de la solution Sherlock's, nous vous conseillons de consulter les documents suivants :
Généralités
Principe
3-D Secure est un protocole d’authentification destiné à réduire les risques de fraude liés au paiement sur Internet. Il a pour but de s’assurer que la carte est bien utilisée par son véritable porteur.
Lors d’un paiement 3-D Secure, il y a une étape supplémentaire qui consiste à authentifier le porteur de la carte.
Transfert de responsabilité
Outre le renforcement de la sécurité, 3-D Secure vous permet de bénéficier du transfert de responsabilité vers la banque émettrice de la carte. En cas de paiement frauduleux, vous êtes garanti de percevoir les fonds, c’est la banque du porteur de la carte qui supporte cette responsabilité. Dans de rares cas, la banque du porteur de la carte peut accepter une demande d’autorisation mais refuser ce transfert de responsabilité, dans ce cas précis le paiement n’est donc plus garanti, et le champ holderAuthentRelegationCode est valorisé à Y.
Ces règles de transfert de responsabilité sont édictées par les réseaux CB, VISA, MASTERCARD et Bancontact. Lorsque le paiement est garanti, le champ guaranteeIndicator est valorisé à Y.
Pour plus de détails sur les cas d’éligibilité au transfert de responsabilité, veuillez vous référer au paragraphe Calcul du transfert de responsabilité.
Champs d'application
Le 3-D Secure s'applique dans les cas suivants :
- Paiement simple (décrit dans cette documentation)
- Paiement en plusieurs fois
- Paiement multiple à l'expédition
- Paiement par abonnement (via wallet ou via duplication)
Nouvelle version 3-D Secure 2.0
Les améliorations apportées
Pour améliorer l’expérience utilisateur par rapport à 3-D Secure v1 (arrêté depuis octobre 2022), les réseaux CB, VISA, MASTERCARD et AMEX proposent maintenant 3-D Secure 2.0 qui apporte un système d’authentification plus optimal basé sur l’évaluation du risque et plus adapté à l’usage des smartphones.
En fonction du niveau de risque, les banques émettrices décideront d’exécuter ou non l’authentification forte du client, il s’agit d’un mode de fonctionnement appelé « frictionless ». Plus le risque est faible, plus la probabilité d’obtenir une transaction « frictionless » est forte.
Montant de l'authentification
En 3-D Secure V2 et pour être conforme à la DSP2 :
- les paiements en plusieurs fois doivent être authentifiés du montant total de l'échéancier.
- le paiement qui permet la mise en place d'un abonnement doit être authentifié du montant moyen des échéances.
authenticationData.authentAmount
.Activation par défaut de l’option 3-D Secure
La Directive des Services de Paiement 2 (DSP2), rendant obligatoire la réalisation d’une authentification forte pour les paiements initiés par le client sur Internet ou via une application mobile. 3-D Secure permet d’être en conformité pour les paiements par cartes avec cette nouvelle réglementation. Sans activation du 3-D Secure, vous vous exposez à des refus d’autorisation pour le motif de transactions non authentifiées.
Par conséquent, sauf avis contraire de votre part, toute nouvelle boutique e-commerce est inscrite sur Sherlock's avec l’option 3-D Secure activée par défaut.
Si l’option 3-D Secure n’est pas activée sur votre boutique, veuillez contacter l'assistance technique de Sherlock's pour activer cette option.
L’activation de l’option 3-D Secure se fait en 2 temps :
- étape 1 = enrôlement de votre boutique sur les Directory Servers
(CB, VISA, MASTERCARD, AMEX, Bancontact) ;
- Pour CB, Visa et Bancontact, l'enrôlement est quasiment immédiat
- Pour MASTERCARD, l'enrôlement est réalisé en 7 jours
- Pour AMEX, l'enrôlement est réalisé en 3 semaines
- étape 2 = activation de 3-D Secure lorsque l’enrôlement sur le Directory Server est réalisé :
Options complémentaires
Refuser les transactions en erreur 3-D Secure
Afin de réduire le risque d’impayé, vous avez la possibilité de refuser toutes les transactions pour lesquelles une erreur technique a empêché le bon déroulement du processus d’authentification 3-D Secure car ces transactions ne bénéficient pas du transfert de responsabilité.
Si vous activez cette option et qu’une erreur 3-D Secure survient lors de l’authentification 3-D Secure, la transaction est refusée, avec en retour un code réponse 05 (champ responseCode = 05) et le champ holderAuthentStatus valorisé à ERROR.
N’accepter que les transactions garanties
Afin d’être certain de collecter tous les fonds de vos ventes et d’éviter les impayés, vous avez la possibilité de refuser des transactions éligibles au transfert de responsabilité mais qui n’en bénéficient pas.
En activant cette option, les transactions non garanties (champ guaranteeIndicator = N ou U ou "vide") se verront donc refusées avec un complementaryCode valorisé à 17.
Cette option s’applique uniquement sur les transaction initiées par le porteur (CIT) effectuées avec une carte CB, VISA ou MASTERCARD (enregistrée ou non dans un wallet Sherlock's ou un wallet externe).
Cette option ne s'applique pas :
- sur les transactions initiées par le commerçant (MIT)
- sur les CITs sur lesquelles le transfert de responsabilité n’est pas éligible (transaction Paypal par exemple)
- sur les CIT sur lesquelles le 3-D Secure n’a pas été effectué (cardOrder sans données 3-D Secure par exemple)
Connecteur Sherlock’s Paypage
Paiement par carte
Ce paragraphe décrit comment mettre en œuvre 3-D Secure pour les paiements à l’acte.
Description des flux
- Vous redirigez le client vers Sherlock’s Paypage en communiquant dans la requête les données de la transaction (montant, devise, ..).
- Sherlock's affiche la page de paiement, le client saisit le numéro de carte, le cryptogramme visuel, puis valide.
- Sherlock's procède à la vérification 3-D Secure.
- Sherlock's envoie une demande d’autorisation à l’acquéreur.
- Sherlock's enregistre la transaction dans le back office.
- Sherlock's affiche la page de ticket de paiement.
- Sherlock's vous retourne les réponses manuelle et automatique contenant les détails de la transaction y compris le résultat de l’authentification 3-D Secure.
- Sherlock's envoie, ou pas, la transaction en remise en fonction des modalités que vous avez paramétrées dans la requête de paiement.
La séquence décrite ci-dessus se transpose sur les moyens de paiement CB, Visa, Mastercard et Amex.
Mise en œuvre
Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de Sherlock's pour activer le service.
Paramétrer la requête de paiement
Pour proposer le paiement 3-D Secure via Sherlock’s Paypage vous n’avez aucun champ spécifique 3-D à renseigner.
Veuillez consulter un des guides Sherlock’s Paypage (Sherlock’s Paypage JSON, Sherlock’s Paypage POST ou Sherlock’s Paypage SOAP pour savoir comment renseigner la requête en fonction de votre besoin métier).
Analyser la réponse
Sherlock's retourne une réponse manuelle et une réponse Sherlock’s Paypage automatique classique . Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.
Les champs relatifs à un paiement 3-D Secure sont les suivants :
Cas d’usage | Champs de la réponse |
---|---|
Client authentifié fortement |
holderAuthentMethod =
|
Client authentifié passivement, sans souhait du commerçant (aussi appelé "Frictionless émetteur") |
holderAuthentMethod =
|
Client authentifié passivement, avec souhait du
commerçant (aussi appelé "Frictionless commerçant", ChallengeMode3DS =
NO_CHALLENGE) |
holderAuthentMethod =
|
Carte non enrôlée |
|
Le client n’a pas réussi à s’authentifier, le paiement est nécessairement refusé. |
holderAuthentMethod =
|
Problème technique qui a empêché le bon déroulement de l’authentification 3-D Secure. |
holderAuthentMethod =
NOT_SPECIFIED
|
Votre boutique n’est pas enrôlée 3-D Secure. |
|
Le client annule le processus d’authentification. |
|
Le client abandonne sur la page ACS et ferme son
navigateur. Vous ne recevez pas de réponse manuelle, mais
uniquement une réponse automatique avec un champ responseCode valorisé à
97. |
|
Connecteur Sherlock’s Office
Paiement à partir d’un numéro de carte
Description des flux
Un paiement 3-D Secure se déroule en 3 temps :
- la vérification de l’enrôlement de la carte du client ;
- la redirection du client vers l’ACS de sa banque ;
- la demande d’autorisation 3-D Secure.
Mise en œuvre
Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de Sherlock's pour activer le service.
Pour accepter un paiement carte 3-D Secure, vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.
Etape 1 : collecte des coordonnées de paiement
Vous collectez les données carte du client (numéro de carte, date de validité, cryptogramme visuel). Vous devez vous conformer aux recommandations PCI-DSS.
Etape 2 : vérification de l’enrôlement de la carte sélectionnée
Vous vérifiez l’enrôlement 3-D Secure de la carte en faisant appel à la
méthode cardCheckEnrollment
.
Paramétrer la requête de paiement
Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.
Nom du champ | Règle de valorisation |
---|---|
amount |
Montant du paiement. Le montant est affiché sur la page d’authentification du client. |
captureDay |
Doit être inférieur ou égal à 6. Si la valeur est supérieure à 6, le serveur Sherlock's la force à 6. |
cardCSCValue |
Valeur récupérée à l’étape précédente. |
cardExpiryDate |
Valeur récupérée à l’étape précédente. |
cardNumber |
Valeur récupérée à l’étape précédente. |
merchantName |
Nom de la boutique de votre site Web affiché sur la page d’authentification de la banque du client. Si non renseigné, sera affiché le nom de votre boutique renseigné lors de l’inscription de votre boutique sur Sherlock's. |
merchantReturnUrl |
Ne pas valoriser, champ déprécié. |
merchantUrl |
URL de votre site Web affichée sur la page d’authentification de la banque du client. Si non renseigné, sera affiché l’URL de votre boutique renseignée lors de l’inscription de votre boutique sur Sherlock's. |
orderChannel |
Pour les paiements effectués par Internet, valoriser : INTERNET |
panType |
Si vous utilisez le connecteur Sherlock’s Office
classique : PAN si vous utilisez le connecteur Sherlock’s Office en mode CSE : CSE |
paymentMeanBrand |
Pour les cartes co-badgées (CB+VISA ou CB+MASTERCARD), la
valeur indiquée détermine le choix du DS dans une cinématique 3-D
Secure v2. Exemple : pour une carte co-badgée CB+VISA :
|
fraudData.challengeMode3DS |
Dans un contexte 3-D Secure V2, si vous souhaitez demander
une exemption, veuillez vous référer au
chapitre correspondant Si vous souhaitez ajouter la carte dans le wallet Sherlock's à la suite du paiement, alors ce champ doit obligatoirement être valorisé avec «CHALLENGE_MANDATE» |
Analyser la réponse
Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.
Cas d’usage | Champs de la réponse | Action à réaliser |
---|---|---|
Carte enrôlée 3-D Secure. |
redirectionStatusCode =
00 |
Vous devez rediriger le client sur l’ACS de sa banque via
l’URL contenue dans le champ redirectionUrl (voir l'étape
suivante). |
Carte non enrôlée 3-D Secure. |
redirectionStatusCode =
01 |
Passez à l’étape 5 : demande
d’autorisation. Le champ redirectionData contient les informations nécessaires pour faire la demande d'autorisation même si la carte n'est pas enrôlée. |
Erreur technique empêchant le bon déroulement d’une cinématique 3-D Secure. | redirectionStatusCode = 10,
80, 89 |
Passez à l’étape 5 : demande d’autorisation. |
Boutique non enrôlée au programme 3-D Secure. | responseCode = 40 |
Veuillez contacter l'assistance technique de LCL. |
Transaction invalide |
redirectionStatusCode =
12 |
Une ou plusieurs données de la requête sont invalides.
Consultez le champ errorFieldName , et corrigez
la valeur incorrecte. |
Carte invalide | redirectionStatusCode =
14 |
Les coordonnées du moyen de paiement sont invalides, repasser à l’étape 1 en demandant au client de saisir de nouveau ses informations de paiement. |
Clé secrète ou version de clé invalide |
redirectionStatusCode =
34 |
Vérifiez la clé secrète utilisée (champ secretKey ) et la version de
la clé (champ keyVersion ) |
Serveur Sherlock's temporairement indisponible | responseCode = 99 |
Vous pouvez soumettre une seconde fois la requête. Si l'erreur persiste, alertez l'assistance technique de LCL. |
Etape 3 : redirection du client vers l’ACS de sa banque
Si la carte est enrôlée, vous devez rediriger le client vers l’URL de l’ACS de sa banque, récupérée à l’étape précédente dans le champ redirectionUrl. Dans un cas d'authentification passive, vous devez aussi réaliser cette étape, même si le client ne sera pas réellement redirigé vers l'ACS de sa banque.
Merci de vous référer au paragraphe Formulaire POST vers l’ACS de la documentation Sherlock’s Office JSON pour mettre en œuvre ce message.
Etape 4 : récupération des données de l’authentification du client
A la fin du processus d'authentification, le client est redirigé vers votre site Web via une redirection HTTP. Le résultat de l’authentification est récupéré au travers du champ PARes.
Merci de vous référer au paragraphe Formulaire POST vers l’ACS de la documentation Sherlock’s Office JSON pour mettre en œuvre ce message.
Si le client abandonne le processus d’authentification (il ferme son navigateur, il n’est jamais redirigé sur votre site Web), ne transmettez pas la demande d’autorisation, ne livrez pas la commande.
Etape 5 : demande d’autorisation 3-D Secure
Après son authentification (y compris pour une authentification passive ou une authentification échouée), au retour du client sur votre site de commerce électronique, transmettez la demande d’autorisation 3-D Secure via la méthode cardValidateAuthenticationAndOrder.
En cas d'authentification échouée, Sherlock's ne transmet pas de demande d'autorisation vers votre acquéreur, le paiement est nécessairement refusé.
Paramétrer la requête
Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.
Nom du champ | Règle de valorisation |
---|---|
redirectionData |
Contient les données de la transaction de paiement.
Valorisez ce champ avec le champ redirectionData reçu en
retour de la méthode cardCheckEnrollment . |
transactionReference ou |
Doit être identique au champ transactionReference ou s10TransactionReference
transmis lors de l’appel à la méthode cardCheckEnrollment . |
paResMessage |
Si vous avez redirigé le client vers l’ACS de sa banque,
car sa carte est enrôlée : renseignez ce champ avec le contenu du
champ PARes , préalablement "URL
encodé", reçu en retour de l’ACS.Si vous n’avez pas redirigé
le client vers l’ACS de sa banque, car sa carte n’est pas enrôlée,
ne renseignez pas ce champ. |
messageVersion |
Valorisez ce champ avec le champ messageVersion reçu en retour
de la méthode cardCheckEnrollment |
Analyser la réponse
Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.
Les informations ci-dessous ne concernent que l'authentification. Pour les informations sur le paiement, veuillez-vous référer aux documentations des connecteurs Sherlock’s Office.
Cas d’usage | Champs de la réponse |
---|---|
Client authentifié | Voir Analyser la réponse. |
Le client n’a pas réussi à s’authentifier, ou a annulé sur la page ACS, le paiement est nécessairement refusé. | Voir Analyser la réponse. |
Problème technique qui a empêché le bon déroulement de l’authentification 3-D Secure. | Voir Analyser la réponse. |
paResMessage invalide.
Ce cas peut survenir :
|
= 95holderAuthentProgram =
3DSholderAuthentMethod =
NOT_SPECIFIED holderAuthentRelegationCode =
NholderAuthentStatus =
FAILURE |
Session 3D expirée. Ce cas peut survenir si vous
transmettez la requête cardValidateAuthenticationAndOrder
plus de 15 minutes après traitement de la requête cardCheckEnrollment . |
holderAuthentResponseCode =
89holderAuthentProgram =
3DSholderAuthentMethod =
NOT_SPECIFIEDholderAuthentRelegationCode =
NholderAuthentStatus =
ERROR |
Clé secrète ou version de clé invalide | responseCode = 34 |
Cette opération a déjà été effectuée sur cette transaction. | responseCode = 24 |
Connecteur Sherlock’s In-App
Paiement à partir d'un numéro de carte
Description des flux
Un paiement 3-D Secure se déroule en 3 temps :
- la vérification de l’enrôlement de la carte du client ;
- la redirection du client vers l’ACS de sa banque ;
- la demande d’autorisation 3-D Secure.
Mise en oeuvre
Si votre boutique ne dispose pas d'authentification 3-D Secure, veuillez contacter l’assistance technique de Sherlock's pour activer le service.
Pour accepter un paiement carte 3-D Secure, vous devez mettre en œuvre les messages reçus et transmis par les entités nommées « Serveur e-commerce » et « App Mobile » du schéma ci-dessus.
Etape 1 : initialisation du paiement
Vous initialisez le paiement en faisant appel à la méthode orderInitialize
.
Paramétrer la requête
Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.
Nom du champ | Règle de valorisation |
---|---|
amount |
Montant du paiement. Le montant est affiché sur la page d’authentification du client. |
captureDay |
Doit être inférieur ou égal à 6. Si la valeur est supérieure à 6, le serveur Sherlock's la force à 6. |
sdkOperationName |
THREEDSECUREANDORDER |
challengeMode3DS |
Indiquez votre souhait d'exemption. Si le champ n'est pas renseigné, le champ est à la charge de l'émetteur. |
Analyser la réponse
Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.
Cas d’usage | Champs de la réponse | Action à réaliser |
---|---|---|
Initialisation de paiement réussie | redirectionStatusCode =
00 |
Vous affichez l'écran de collecte des coordonnées de paiement dans votre l'application mobile. Vous transmettez à l'application mobile les données nécessaire à la poursuite du paiement : |
Requête d'initialisation invalide | redirectionStatusCode = 12,
30 |
Une ou plusieurs données de la requête sont invalides.
Consultez le champ redirectionStatusMessage , et
corrigez la valeur incorrecte. |
Serveur Sherlock's temporairement indisponible | redirectionStatusCode =
99 |
Resoumettez la requête. Si le problème persiste, alertez l'assistance technique de LCL. |
Transaction dupliquée | redirectionStatusCode =
94 |
Le transactionReference ou le
transactionId est déjà
consommé par une autre requête de votre boutique. Resoumettez la
requête avec une autre référence de transaction. |
Etape 2: collecte des coordonnées de paiement
Vous collectez les données carte du client (numéro de carte, date de validité, cryptogramme visuel) via votre application mobile.
Etape 3 : vérification de l'enrôlement de la carte
Vous vérifiez l’enrôlement 3-D Secure de la carte en faisant appel à la
méthode cardCheckEnrollment
du SDK.
Paramétrer la requête
Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.
Nom du champ | Règle de valorisation |
---|---|
cardCSCValue |
Valeur récupérée à l’étape précédente. |
cardExpiryDate |
Valeur récupérée à l’étape précédente. |
cardNumber |
Valeur récupérée à l’étape précédente. |
paymentMeanBrand |
Pour les cartes co-badgées (CB+VISA ou CB+MASTERCARD), la
valeur indiquée détermine le choix du DS dans une cinématique 3-D
Secure v2. Exemple : pour une carte co-badgée CB+VISA :
|
Analyser la réponse
Cas d’usage | Champs de la réponse | Action à réaliser |
---|---|---|
Carte enrôlée 3-D Secure. | redirectionStatusCode =
00 |
Vous devez rediriger le client sur l’ACS de sa banque via
l’URL contenue dans le champ authentRedirectionUrl (voir
l'étape suivante). |
Carte non enrôlée 3-D Secure. | redirectionStatusCode =
01 |
Passez à l’étape 6 : demande d’autorisation. |
Erreur technique empêchant le bon déroulement d’une cinématique 3-D Secure. | redirectionStatusCode = 10,
80, 89, 99 |
Passez à l’étape 6 : demande d’autorisation. |
Boutique non enrôlée au programme 3-D Secure. | reponseCode = 40 |
Veuillez contacter l'assistance technique de LCL. |
Transaction invalide | redirectionStatusCode =
12 |
Une ou plusieurs données de la requête sont invalides.
Consultez le champ errorFieldName , et corrigez
la valeur incorrecte. |
Carte invalide | redirectionStatusCode =
14 |
Les coordonnées du moyen de paiement sont invalides, repasser à l’étape 1 en demandant au client de saisir de nouveau ses informations de paiement. |
Wallet inexistant ou moyen de paiement inexistant | redirectionStatusCode =
25 |
Vérifier le champ merchantWalletId ou le
champpaymentMeanId |
Etape 4 : redirection du client vers l’ACS de sa banque
Si la carte est enrôlée, vous devez rediriger le client vers l’URL de
l’ACS de sa banque, récupérée à l’étape précédente dans le champ authentRedirectionUrl
. Dans un cas
d'authentification passive, vous devez aussi réaliser cette étape, même si
le client ne sera pas réellement redirigé vers l'ACS de sa banque.
Merci de vous référer au paragraphe traitant de la redirection vers l’ACS de la documentation Sherlock’s In-App pour mettre en œuvre ce message.
Etape 5 : récupération des données de l’authentification du client
A la fin du processus d'authentification, le client est redirigé vers
votre application via une redirection HTTP. Le résultat de
l’authentification est récupéré au travers du champ PARes
.
Merci de vous référer au paragraphe traitant du retour de l’ACS de la documentation Sherlock’s In-App pour mettre en œuvre ce message.
Si le client abandonne le processus d’authentification (il ferme son navigateur, il n’est jamais redirigé sur votre site Web), ne transmettez pas la demande d’autorisation, ne livrez pas la commande.
Etape 6 : demande d’autorisation 3-D Secure
Après son authentification (y compris pour une authentification passive
ou une authentification échouée), au retour du client sur votre
application de commerce électronique, transmettez la demande
d’autorisation 3-D Secure via la méthode cardValidateAuthenticationAndOrder
.
En cas d'authentification échouée, Sherlock's ne transmet pas de demande d'autorisation vers votre acquéreur, le paiement est nécessairement refusé.
Paramétrer la requête
Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.
Nom du champ | Règle de valorisation |
---|---|
paResMessage |
Si vous avez redirigé le client vers l’ACS de sa banque car
sa carte est enrôlée, renseignez ce champ avec le contenu du champ
PARes , préalablement "URL
encodé", reçu en retour de l’ACS.Si vous n’avez pas redirigé
le client vers l’ACS de sa banque car sa carte n’est pas enrôlée,
ne renseignez pas ce champ. |
Analyser la réponse
Veuillez vous référer à la documentation Sherlock’s In-App.
Les exemptions à l'authentification forte
Description des exemptions
Le protocole 3-D Secure v2 permet d'authentifier le client de manière passive, lorsque le risque de fraude est suffisamment bas. Ce type d'authentification est aussi appelée authentification « frictionless ». Lors d'un paiement « frictionless », l’opération est bien authentifiée, mais le client n’est pas sollicité. Dans un cas de frictionless, un cryptogramme d’authentification est fourni par l’émetteur et transmis dans la demande d’autorisation.
La DSP2 distingue plusieurs cas d'exemption :
- les exemptions pour petits montants (< 30 €) ;
- les exemptions suite à une analyse de risque acquéreur (Transaction Risk Analysis Acquéreur) ;
- les exemptions suite à une analyse de risque émetteur (Transaction Risk Analysis Emetteur) ;
- les exemptions dans le cadre d'un paiement chez un bénéficiaire de confiance ;
- les exemptions sur l'utilisation de cartes non-nominatives (cartes attribuées aux personnes morales).
Le paiement frictionless se décline de 2 manières :
- frictionless commerçant,
que vous demandez explicitement dans la requête de paiement, via le
champ
faudData.challengeMode3DS
. Même si vous demandez une authentification « frictionless » la décision définitive d’accorder ou pas cette authentification frictionless reste du ressort de l’émetteur de la carte. Il est important de noter que si l’émetteur accorde l'authentification frictionless, dans ce cas, vous perdez la garantie de paiement, c’est alors vous qui supportez le risque d’impayé et non plus l’émetteur de la carte. Si l’émetteur n'accorde pas l'authenification « frictionless », il supporte le risque d'impayé. - frictionless émetteur décidé par l’émetteur de la carte en fonction des données de contexte de la transaction que vous aurez renseignées dans la requête. Même si l’émetteur accorde l'authentification frictionless, vous conservez la garantie de paiement, c’est donc l’émetteur de la carte qui supporte le risque d’impayé.
Mise en oeuvre des exemptions
Exemption TRA acquéreur
Vous pouvez demander une exemption si votre analyse de risque montre que le risque de fraude est suffisamment bas pour solliciter une authentification « frictionless ». Ce cas de dérogation est appelé Transaction Risk Analysis (TRA) acquéreur. Pour profiter de cette fonctionnalité, vous devez demander l'autorisation à votre acquéreur, qui vous indiquera les modalités d'usage de cette exemption (montant maximal, règles à appliquer en cas d'évolution dans le temps, ...), et demander à votre contact Sherlock's habituel d'activer l'option « TRA acquéreur ».
Paramétrer la requête
Champ | Valorisation |
---|---|
fraudData.challengeMode3DS |
NO_CHALLENGE_TRA_ACQ |
Analyser la réponse
Cas d'usage | Champs de la réponse | Action à réaliser |
---|---|---|
Demande d'exemption accordée par l'émetteur et client authentifié passivement |
|
|
Demande d'exemption rejetée par l'émetteur et client authentifié fortement |
|
|
Demande d'exemption non autorisée car non
activé sur votre boutique et client authentifié (dans ce cas
Sherlock's traduit en demande d'exemption "basique"
: fraudData.challengeMode3DS =
NO_CHALLENGE) |
voir chapitre suivant | Contactez votre interlocuteur Sherlock's pour ajouter le droit à l'utilisation de cette fonctionnalité |
La valeur du champ fraudData.challengeMode3DS
peut être
surchargée avec la valeur NO_CHALLENGE si :
- vous n'avez pas demandé l'autorisation à votre acquéreur et n'avez donc pas l'option « TRA acquéreur » activée sur votre boutique
- l'émetteur est encore en EMVCo 2.1.0 (au lieu de EMVCo 2.2) et que la transaction est réalisée sur le réseau Visa ou Mastercard
Exemption sans motif
Si vous ne bénéficiez pas du droit d'utilisation de l'exemption TRA acquéreur, vous pouvez aussi demander une exemption basique.
Paramétrer la requête
Champ | Valorisation |
---|---|
fraudData.challengeMode3DS |
NO_CHALLENGE |
Analyser la réponse
Cas d'usage | Champs de la réponse | Action à réaliser |
---|---|---|
Demande d'exemption accordée par l'émetteur et client authentifié passivement |
|
|
Demande d'exemption rejetée par l'émetteur et client authentifié fortement |
|
Exemption pour petit montant et exemption TRA Emetteur
Même si vous ne demandez pas explicitement d'exemption, l'emetteur de la carte peut accorder une exemption dans 2 autres cas :
- le paiement est d'un montant faible, inférieur à 30 € ;
- l'analyse de risque effectuée par l'émetteur montre que le risque de fraude est suffisament bas.
Paramétrer la requête
Champ | Valorisation |
---|---|
challengeMode3DS |
NO_PREFERENCE |
Il est préférable de valoriser les champs recommandés par les réseaux. Veuillez vous référer au chapitre suivant.
Analyser la réponse
Cas d'usage | Champs de la réponse |
---|---|
Demande d'exemption accordée par l'émetteur et client authentifié passivement |
|
Champs permettant de favoriser le paiement "frictionless"
Afin de favoriser le paiement « frictionless » et par conséquent optimiser votre taux de conversion, vous devez renseigner certains champs de la requête de paiement recommandés par les réseaux CB, VISA et MASTERCARD. Ces champs optionnels sont transmis au Directory Server du réseau ainsi qu’à l’émetteur de la carte qui décide ou pas d’accorder l'authentification frictionless.
Ce paragraphe liste les champs des connecteurs Sherlock's qui, s’ils sont alimentés, sont transmis au réseau de la carte ainsi qu’à l’émetteur dans la demande d’authentification. Ces données, définies par la norme EMVco, sont utilisées pour la lutte contre la fraude et favorisent l’obtention d'une authentification frictionless.
Seuls sont indiqués dans le tableau suivant les réseaux ayant explicitement donné des informations sur les champs ayant un impact sur l'obtention d'une authentification frictionless.
Parmi ces champs on peut distinguer :
- R - champs Recommandés par le réseau : ces champs facultatifs ont été identifiés par le réseau comme étant important pour le scoring de la transaction. Ainsi le réseau recommande leur alimentation par le commerçant si l’information est disponible.
- Rx - champs Recommandés par le réseau CB et ayant une pertinence majeure pour le scoring du DS CB : ces champs facultatifs ont été identifiés par le réseau CB comme étant très important pour le scoring de la transaction. Ainsi le réseau CB recommande leur alimentation par le commerçant si l’information est disponible. L'ordre d'importance est traduit par le chiffre derrière la lettre R. Les champs les plus importants sont classés en R1 et ainsi de suite.
- F - champs Facultatifs : ces champs sont purement facultatifs, le réseau n’a pas indiqué de recommandation pour leur alimentation.
- A - champs Absents : ces champs ne sont pas transmis au réseau.
Direct to Authorize
Description
Un commerçant peut demander le traitement d’une transaction en autorisation avec une exemption (de type SCA exemption) sans passer par une demande d’authentification du porteur de la carte: il s’agit du « Direct To Authorization (DTA) ».
Par défaut cette option s’applique sur Visa et Mastercard. Vous pouvez modifier ce paramétrage en vous rapprochant de votre contact Sherlock's habituel.
2 motifs d’exemption sont supportées par le DTA:
- les exemptions pour petits montants (inférieur à 30 €)
- les exemptions suite à une analyse de risque acquéreur
Seuls les cas de paiement à l’acte (ONE_SHOT) et 1er paiement pour une commande livrée en plusieurs fois (MULTIPLE_1) peuvent faire du DTA.
Le DTA est disponible sur les connecteurs Sherlock’s Paypage, Sherlock’s Office et Sherlock’s In-App.
En cas de refus en Soft Decline (A1) sur Sherlock’s Paypage, nous effectuerons automatiquement une nouvelle tentative de paiement en mode 3-D Secure (retrySofDecline) selon les règles suivantes :
- Si une exemption de type NO_CHALLENGE_DTA était demandée alors une nouvelle tentative de paiement en mode 3-D Secure de type NO_CHALLENGE s’effectuera
- Si une exemption de type NO_CHALLENGE_TRA_ACQ_DTA était demandée alors une nouvelle tentative de paiement en mode 3-D Secure de type NO_CHALLENGE_TRA_ACQ s’effectuera si vous avez l’option TRA_ACQ, sinon une nouvelle tentative de paiement en mode 3-D Secure de type NO_CHALLENGE s’effectuera
En cas d’éventuelles MIT réalisées via la méthode duplicate, Sherlock's chainera automatiquement ces MIT avec la CIT DTA.
Mise en oeuvre
Exemption petits montants
Vous pouvez demander du DTA avec une exemption de type petit montant pour des paiements d’un montant faible, inférieur à 30 €. Pour profiter de cette fonctionnalité, vous devez demander à votre contact Sherlock's habituel d'activer l'option « DTA ».
Paramétrer la requête
Champ | Valorisation |
---|---|
fraudData.challengeMode3DS |
NO_CHALLENGE_DTA |
Analyser la réponse
Cas d'usage | Champs de la réponse | Action à réaliser |
---|---|---|
Transaction acceptée |
|
|
Transaction refusée en SoftDecline (A1) |
|
Si utilisation du connecteur Sherlock’s Office ou Sherlock’s In-App, vous pouvez faire une nouvelle tentative de paiement en mode 3-D Secure de type NO_CHALLENGE |
Exemption TRA acquéreur
Vous pouvez demander du DTA avec une exemption de type Transaction Risk Analysis (TRA) acquéreur si votre analyse de risque montre que le risque de fraude est suffisamment bas. Pour profiter de cette fonctionnalité, vous devez demander l'autorisation à votre acquéreur, qui vous indiquera les modalités d'usage de cette exemption (montant maximal, règles à appliquer en cas d'évolution dans le temps, ...), et demander à votre contact Sherlock's habituel d'activer l'option « TRA acquéreur » et l’option « DTA ».
Paramétrer la requête
Champ | Valorisation |
---|---|
fraudData.challengeMode3DS |
NO_CHALLENGE_TRA_ACQ_DTA |
Analyser la réponse
Cas d'usage | Champs de la réponse | Action à réaliser |
---|---|---|
Transaction acceptée |
|
|
Transaction refusée en SoftDecline (A1) |
|
Si utilisation du connecteur Sherlock’s Office ou Sherlock’s In-App, vous pouvez faire une nouvelle tentative de paiement en mode 3-D Secure de type NO_CHALLENGE_TRA_ACQ si vous avez l’option TRA_ACQ, sinon de type NO_CHALLENGE |
Authentification du client dissociée du paiement (aussi appelé Authentication-only)
Ce paragraphe décrit comment mettre en œuvre des cas d’usage de 3-D Secure nécessitant de dissocier le flux d’authentification du flux de paiement.
Authentification traitée par Sherlock's et paiement traité par un autre PSP
Description des flux
Mise en œuvre
Si votre boutique n’est pas 3-D Secure, ou si vous n'avez pas le droit d'utiliser la fonction « Authentication-only » veuillez contacter l’assistance technique de Sherlock's pour activer le service.
Pour mettre en œuvre un paiement carte 3-D Secure en mode « Authentication-only », vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.
Etape 1 : collecte des coordonnées de paiement
Vous collectez les données de carte du client (numéro de carte, date de validité, cryptogramme visuel). Vous devez vous conformer aux recommandations PCI-DSS.
Etape 2 : vérification de l’enrôlement de la carte via Sherlock's
Paramétrer la requête de paiement
Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.
Nom du champ | Règle de valorisation |
---|---|
cardCSCValue | Valeur récupérée à l’étape précédente |
cardExpiryDate | Valeur récupérée à l’étape précédente |
cardNumber | Valeur récupérée à l’étape précédente |
merchantName | Nom de la boutique de votre site affiché sur la page
d’authentification de la banque du client. Si non renseigné,
sera affiché le nom de votre boutique renseigné lors de
l’inscription de votre boutique sur Sherlock's. |
merchantReturnUrl | Ne pas valoriser, champ déprécié. |
merchantUrl | URL de votre site affichée sur la page d’authentification de la banque du client. Si non renseigné, sera affiché l’URL de votre boutique renseignée lors de l’inscription de votre boutique sur Sherlock's. |
panType | Valoriser à PAN. |
paymentMeanBrand | Pour les cartes co-badgées (CB+VISA ou CB+MASTERCARD), la
valeur indiquée détermine le choix du DS. Exemple : pour une
carte co-badgée CB+VISA :
|
Analyser la réponse
Merci de vous référer à la partie Analyser la réponse du paragraphe de Connecteur Sherlock’s Office.
Etape 3 : redirection du client vers l’ACS de sa banque
Merci de vous référer à la même étape du paragraphe Connecteur Sherlock’s Office.
Etape 4 : récupération des données de l’authentification du client
Merci de vous référer à la même étape du paragraphe Connecteur Sherlock’s Office.
Etape 5 : vérification du résultat de l’authentification
Merci de vous référer à la même étape du paragraphe Enrôlement d'une carte sans paiement.
Etape 6 : demande d’autorisation vers l’autre PSP
Les données 3-D Secure sont présentes dans la réponse de la méthode cardValidateAuthentication appelée à l’étape précédente : container authenticationResult.threeDV2.
Authentification traitée par un autre PSP et paiement traité par Sherlock's
Description des flux
Particularitées de ce mode d'intégration
Sur ce type d'intégration, Sherlock's ne procède pas à
l'authentification du porteur et ne peut donc pas se prononcer sur la
garantie de paiement. Le champ guaranteeIndicator
sera donc vide
quel que soit le résultat de l'authentification et de l'autorisation.
Lors de la demande d'autorisation, Sherlock's considère que vous êtes satisfait du résultat d'authentification et que vous souhaitez donc passer à la suite du paiement. Les règles spécifiques (refus des transactions en 3D_ERROR, refus des transactions sans garantie de paiement) sont disponibles sur Sherlock's pour bloquer des paiements en fonction du résultat de l'authentification sont donc ignorées dans ce cas.
Mise en œuvre
Pour mettre en œuvre un paiement carte 3-D Secure en mode « Authentication-only », vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.
Etape 1 : collecte des coordonnées de paiement
Vous collectez les données de carte du client (numéro de carte, date de validité, cryptogramme visuel). Vous devez vous conformer aux recommandations PCI-DSS.
Etape 2 : demande d’authentification vers autre PSP
Etape 3 : demande d’autorisation 3-D Secure vers Sherlock's
Après son authentification, au retour du client sur votre site de commerce électronique, transmettez la demande d’autorisation 3-D Secure via la méthode cardOrder.
Paramétrer la requête de paiement
Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.
Nom du champ | Règle de valorisation | |
---|---|---|
authenticationResult.holderAuthentProvider |
Doit être positionné à 2 (autre PSP) | |
amount |
Renseigné avec le montant à autoriser | |
captureDay |
Doit être inférieur ou égal à 6. Si la valeur est
supérieure à 6, le serveur Sherlock's le force à
6. |
|
cardCSCValue |
Renseigné avec la valeur récupérée à l’étape 1. Doit nécessairement être renseigné dans le cadre d’un paiement 3-D Secure. | |
cardExpiryDate |
Renseigné avec la valeur récupérée à l’étape 1. | |
cardNumber |
Renseigné avec la valeur récupérée à l’étape 1. | |
orderChannel |
Pour les paiements effectués par Internet, valoriser : INTERNET | |
paymentPattern |
ONE_SHOT ou RECURRING_1 | |
panType |
Si vous utilisez le connecteur Sherlock’s Office
classique : PAN Si vous utilisez le connecteur Sherlock’s Office en mode CSE : CSE |
|
paymentMeanBrand |
Renseigné avec la valeur récupérée à l’étape 1. | |
authenticationResult.holderAuthentProgram |
3DS_V2 | |
authenticationResult.threeDV2.cavv |
À renseigner avec la valeur protocolaire "authenticationValue" reçue à l’étape 2. | |
authenticationResult.threeDV2.cavvAlgorithm |
À renseigner avec la donnée reçue dans le message spécifique "CB-AVALGO" reçue à l’étape 2 (uniquement requis lorsque l'authentification a été effectué avec FAST'R by CB). | |
authenticationResult.threeDV2.eci |
À renseigner avec la valeur protocolaire "eci" reçue à l’étape 2. | |
authenticationResult.threeDV2.txStatus |
À renseigner avec la valeur protocolaire "transStatus" reçue à l’étape 2. | |
authenticationResult.threeDV2.authentTransStatusReason |
À renseigner avec la valeur protocolaire "transStatusReason" reçue à l’étape 2. | |
authenticationResult.threeDV2.authentAcsTransId |
À renseigner avec la valeur protocolaire "acsTransID" reçue à l’étape 2. | |
authenticationResult.threeDV2.authentDsTransId |
À renseigner avec la valeur protocolaire "dsTransID" reçue à l’étape 2. | |
authenticationResult.threeDV2.authentThreedsServerTransId |
À renseigner avec la valeur protocolaire "threeDSServerTransID" reçue à l’étape 2. | |
authenticationResult.threeDV2.authentAmount |
À renseigner avec la valeur protocolaire "purchaseAmount" valorisée par le PAT en charge de traiter l'authentification à l'étape 2. | |
authenticationResult.threeDV2.authentDateTime |
À renseigner avec la valeur protocolaire "purchaseDate" valorisée par le PAT en charge de traiter l'authentification à l'étape 2. | |
authenticationResult.threeDV2.holderAuthentType |
À positionner en fonction du mode d'authentification réalisé (Challenge ou Frictionless) à l'étape 2. | |
authenticationResult.threeDV2.authentScoreValue |
À renseigner avec la donnée reçue dans le message spécifique "CB-SCORE" reçue à l’étape 2 (uniquement requis lorsque l'authentification a été effectué avec FAST'R by CB). | |
authenticationResult.threeDV2.challengeMode3DS |
À renseigner en fonction de la donnée "threeDSRequestorChallengeInd" (souhait marchand du mode d'authentification) valorisée par le PAT en charge de traiter l'authentification à l'étape 2. | |
authenticationResult.threeDV2.authentCancelReason |
À renseigner avec la valeur protocolaire "challengeCancel" reçue à l’étape 2. | |
authenticationResult.threeDV2.authentDSMerchantName |
À renseigner avec le nom commercial de votre boutique utilisé lors de l'authentification à l'étape 2 (uniquement requis sur un paiement CB). | |
authenticationResult.threeDV2.authentExemptionReasonList |
À renseigner avec la valeur correspondante reçue à l’étape 2 (uniquement requis si l'authentification a été faite en mode frictionless). | |
authenticationResult.threeDV2.authentMessageVersion |
À renseigner avec la version du protocole EMV 3-D Secure utilisé par le PAT en charge de l'authentification à l'étape 2 (exemple : 2.1.0) | |
authenticationResult.threeDV2.authentACSMethod |
À renseigner avec la valeur protocolaire "authenticationMethod" reçue à l’étape 2. |
Analyser la réponse
Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.
Cas d’usage | Champs de la réponse |
---|---|
Paiement accepté | responseCode = 00 acquirerResponseCode = 00
guaranteeIndicator Non
renseigné.authentRelegationCode :
positionné à Y si l'émetteur refuse le transfert de
responsabilité, N sinon. |
Clé secrète ou version de clé invalide | responseCode = 34 |
Paiement refusé | responseCode <>
00acquirerResponseCode <>
00 |
Enrôlement d'une carte sans paiement
Description des flux
La vérification d’une carte via le processus 3-D Secure avant son enrôlement dans le wallet Sherlock's se déroule en 4 temps :
- la vérification de l’enrôlement de la carte ;
- la redirection du client vers l’ACS de sa banque pour l’authentifier ;
- la vérification de l’authentification 3-D Secure ;
- l’enregistrement de la carte dans le wallet si l’authentification est réussie.
Mise en œuvre
Si votre boutique n’est pas 3-D Secure, ou si vous n'avez pas le droit d'utiliser la fonction "Authentication-only" veuillez contacter l’assistance technique de Sherlock's pour activer le service.
Pour mettre en œuvre la vérification 3-D Secure d’une carte avant son enrôlement dans un wallet, vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.
Etape 1 : collecte des coordonnées de paiement
Merci de vous référer à la même étape du paragraphe Connecteur Sherlock’s Office.
Etape 2 : vérification de l’enrôlement de la carte sélectionnée
Vous vérifiez l’enrôlement 3-D Secure de la carte en faisant appel à la méthode cardCheckEnrollment.
Paramétrer la requête
Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.
Nom du champ | Règle de valorisation |
---|---|
amount | Etant donné qu’il n’y a pas de paiement, vous pouvez valoriser à 0. |
cardCSCValue | Valeur récupérée à l’étape précédente. |
cardExpiryDate | Valeur récupérée à l’étape précédente. |
cardNumber | Valeur récupérée à l’étape précédente. |
merchantName | Nom de la boutique de votre site affiché sur la page
d’authentification de la banque du client. Si non renseigné,
sera affiché le nom de votre boutique renseigné lors de
l’inscription de votre boutique sur Sherlock's. |
merchantReturnUrl | Ne pas valoriser, champ déprécié. |
merchantUrl | URL de votre site Web affichée sur la page
d’authentification de la banque du client. Si non renseigné,
sera affiché l’URL de votre boutique renseignée lors de
l’inscription de votre boutique sur Sherlock's. |
panType | Valoriser à PAN |
challengeMode3DS | Valorisez le champ avec CHALLENGE_MANDATE (valeur par défaut pour les moyens de paiement CB, VISA, MC, AMEX). |
paymentMeanBrand | Pour les cartes co-badgées (CB+VISA ou CB+MASTERCARD), la
valeur indiquée détermine le choix du DS. Exemple : pour une
carte co-badgée CB+VISA :
|
Analyser la réponse
Merci de vous référer à la partie Analyser la réponse du paragraphe de Connecteur Sherlock’s Office.
Etape 3 : redirection du client vers l’ACS de sa banque
Merci de vous référer à la même étape du paragraphe Connecteur Sherlock’s Office.
Etape 4 : récupération des données de l’authentification du client
Merci de vous référer à la même étape du paragraphe Connecteur Sherlock’s Office.
Etape 5 : vérification du résultat de l’authentification
Après son authentification, au retour du client sur votre site de commerce électronique, vérifiez le résultat de son authentification via la méthode cardValidateAuthentication.
Paramétrer la requête
Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.
Nom du champ | Règle de valorisation |
---|---|
redirectionData | Contient les données de la transaction de paiement. Valorisez ce champ avec le champ redirectionData reçu en retour de la méthode cardCheckEnrollment. |
transactionReference ou |
Doit être identique au champ transactionReference ou s10TransactionReference transmis lors de l’appel à la méthode cardCheckEnrollment. |
paResMessage | Si vous avez redirigez le porteur vers l’ACS de sa banque,
car sa carte est enrôlée : renseignez ce champ avec le contenu du
champ PARes, préalablement "URL encodé", reçu en retour de
l’ACS. Si n’avez pas redirigé le porteur vers l’ACS de sa
banque, car sa carte n’est pas enrôlée, ne renseignez pas ce
champ. |
Analyser la réponse
Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.
Cas d’usage | Champs de la réponse |
---|---|
Client authentifié |
holderAuthentMethod =
holderAuthentStatus = ATTEMPT
ou SUCCESSthreeDv2.holderAuthentType =
cf. dictionnaire des données |
Le client n’a pas réussi à s’authentifier, ou a annulé sur la page ACS |
holderAuthentProgram =
holderAuthentMethod =
holderAuthentStatus =
FAILUREsi cinématique 3DSv2 threeDv2.holderAuthentType =
CHALLENGE |
Problème technique qui a empêché le bon déroulement de l’authentification 3-D Secure. |
holderAuthentProgram =
holderAuthentMethod =
NOT_SPECIFIEDholderAuthentStatus =
ERRORsi cinématique 3DSv2 threeDv2.holderAuthentType =
CHALLENGE |
paResMessage invalide.
Ce cas peut survenir :
|
holderAuthentResponseCode =
95 |
Session 3D expirée. Ce cas peut survenir si vous
transmettez la requête cardValidateAuthentication
plus de 15 minutes après traitement de la requête cardCheckEnrollment . |
holderAuthentResponseCode =
89holderAuthentProgram =
3DSholderAuthentMethod =
NOT_SPECIFIEDholderAuthentStatus =
ERROR |
Clé secrète ou version de clé invalide | responseCode = 34 |
Utilisation de la fonction
cardValidateAuthentication non autorisée sur cette
boutique Contacter l'assistance technique. |
responseCode = 40 |
Etape 6 : ajouter la carte au wallet
Si le client est bien authentifié vous pouvez enregistrer sa carte à son wallet via la méthode addCard. Merci de vous référer à la documentation Sherlock’s Office pour connaître les détails d’implémentation de cette méthode.
Synthèse des règles de décision 3-D Secure
Règles générales 3-D Secure
Dans les 3 cas suivants:
- Problème technique
- BIN carte non éligible (BIN absent du message Pres du DS)
- Carte non enrôlée 3DSv2 (dans le message Ares du DS)
Sherlock's poursuit avec une Demande d’Autorisation CB2A 160 2019 avec flag d’indisponibilité avec les champs suivants:
- Champ 59 type 0407 = 09 (VAD)
- Champ 56 type 0033 = Octet1 bit ‘5’ activé «indisponibilité technique de mettre en œuvre l’authentification»
Les champs concernés sont valorisés de la manière suivante:
Règles complémentaires Sherlock's
En fonction des options complémentaires auxquelles vous avez souscris, Sherlock's applique les règles suivantes :
Calcul du transfert de responsabilité pour une CIT
Pour les paiements cartes (CB, Visa, Mastercard) via des acquéreurs français, Sherlock's calcule l’indicateur de transfert de garantie et alimente le champ guaranteeIndicator comme décrit ci-dessous :
Calcul du transfert de responsabilité pour une MIT
Pour les paiements cartes (CB, Visa, Mastercard) via des acquéreurs français, Sherlock's calcule l’indicateur de transfert de garantie et alimente le champ guaranteeIndicator comme décrit ci-dessous :
Démarrer 3-D Secure en 4 étapes
Etape 1 - mettre en œuvre le service
En fonction de votre cas d’usage, suivez les recommandations d’intégration décrites dans un des chapitres précédents.
Etape 2 - tester le service sur l’environnement recette
Une fois la mise en œuvre des connecteurs Sherlock's réalisée, vous pouvez effectuer des tests pour valider votre intégration de Sherlock's.
Connecteur Sherlock’s Paypage
Données de test | |
---|---|
merchantId | 201000076690001 |
clé secrète | p64ifeYBVIaRcjaWoahCiw9L8wokNLqG2_YOj_POD4g |
version de la clé | 1 |
cartes de test | cf page "Cartes de test" |
Serveur | URL de test |
---|---|
Paypage POST | https://payment-webinit-sherlocks.test.sips-services.com/paymentInit |
Paypage JSON | https://payment-webinit-sherlocks.test.sips-services.com/rs-services/v2/paymentInit |
Paypage SOAP | https://payment-webinit-sherlocks.test.sips-services.com/services/v2/paymentInit |
Connecteur Sherlock’s Office
Données de test | |
---|---|
merchantId | 201040040170001 |
Clé secrète | rxSP61eeP_oNi5TxCD7Ngy9YcwC8MLw6OlmFGGcsY54 |
Version de la clé | 1 |
cartes de test | cf page "Cartes de test" |
Serveur | URL de test |
---|---|
Office | https://office-server-sherlocks.test.sips-services.com/ |
ACS de simulation
Lors de vos tests et en fonction de la carte utilisée, vous êtes redirigé vers notre simulateur ACS 3-D Secure v2.
Sur ces pages, vous pourrez simuler :
- une authentification réussie (holderAuthentStatus = SUCCESS) ;
- une authentification échouée (holderAuthentStatus = FAILURE) ;
- une erreur technique lors de la phase d’authentification (holderAuthentStatus = ERROR).
- un cas ou le porteur n’a pas eu à s’authentifier (holderAuthentStatus = ATTEMPT).
Etape 3 - souscrire au service en production
Si votre boutique n’a pas encore été inscrite au service 3-D Secure, vous devez en faire la demande auprès de votre interlocuteur habituel, en indiquant pour quels moyens de paiement le service 3-D Secure doit être activé (CB/VISA/MASTERCARD et/ou AMEX).
Etape 4 – démarrer et valider le service en production
L’activation du service 3-D Secure est à présent opérationnelle en production.
Afin de vous assurer qu’il n’y a pas de régression, contrôlez l’évolution de votre taux de transformation. Il est normal que le taux de transformation réduise légèrement, mais si vous constatez une réduction importante de votre taux de transformation, avertissez rapidement votre contact habituel, afin qu’il réalise avec vous le diagnostic du problème rencontré.