3-D Secure status guide
1. Introduction
Avec l’introduction de la directive PSD2, il est plus important que jamais de faire le suivi de vos transactions 3-D Secure.
Que vous utilisiez Page de paiement hebergée ou DirectLink, nous avons rendu les choses vraiment simples pour vous. Utilisez ce guide pour en savoir davantage sur les endroits où vous pouvez trouver les informations disponibles et comment les lire.
Devenez un expert 3-D Secure en un rien de temps !
2. Comprendre les statuts 3-D Secure
Hormis pour des exclusions et des exemptions clairement définies, tous vos clients devront réaliser avec succès une vérification par authentification 3-D Secure. Un statut 3-D Secure (qui est le résultat de la vérification par authentification) et un statut global de transaction (qui indique le résultat de la demande d’autorisation) seront attribués à la transaction.
Par conséquent, ils sont tous deux le résultat de deux étapes distinctes:
- Statut 3-D Secure : premièrement, le/la client-e doit prouver qu’il/elle est le détenteur/la détentrice légitime de la carte de crédit utilisée pour la transaction. Cette vérification par authentification a lieu sur le portail en ligne de l’émetteur de votre client. Un aperçu des résultats possibles est visible dans notre guide sur les paramètres
- Statut global de transaction : deuxièmement, votre acquéreur vérifie en consultant l’émetteur de votre client que suffisamment de fonds sont disponibles pour la transaction, ce qui aboutit à une autorisation réussie/refusée. Un aperçu des résultats possibles est visible dans notre guide sur les statuts des transactions
Vous pouvez rechercher les résultats tant manuellement dans le Back Office que sur notre outil Reporting:
- Back Office: Recherchez la transaction sous Opérations > Gestion transactions. Dans l’aperçu, vérifiez le « Status » (qui est le statut global de la transaction) et l’image combinée à une description (qui est le statut 3-D Secure)
L’image montre où chercher le statut 3-D Secure et le statut global de la transaction dans le Back Office - Reporting: Assurez-vous de configurer votre profil Electronic reporting comme décrit dans notre vidéo dédiée. Les paramètres ECI / STATUT indiquent le statut 3-D Secure / statut global de la transaction respectivement
Si vous traitez des transactions via Page de paiement hebergée, notre plateforme déploie la version 1 automatiquement pour vous..
Si vous traitez des transactions via DirectLink, vous devez déployer la version 1 vous-même.Découvrez comment le faire dans le chapitre dédié DirectLink.
Le tableau ci-dessous vous donne un aperçu complet des scénarios possibles et de la façon dont notre plateforme vous les affiche des deux manières :
| Statut 3-D Secure (Back Office) | Statut 3-D Secure (paramètre ECI dans Reporting | Statut de la transaction | Description |
|---|---|---|---|
| Pouce totalement levé/ « Cardholder has been successfully identified! V1 » |
5 | En fonction du résultat de l’autorisation par votre acquéreur, soit 2 5 9 |
Le titulaire de la carte a été identifié avec succès. En cas d’impayés frauduleux, l’émetteur est responsable |
| Pouce à moitié levé/ « Cardholder not identified: liability shift rules to be applied (depending on transaction date and credit card country) » |
6 12 |
En fonction du résultat de l’autorisation par votre acquéreur, soit 2 5 9 |
Votre client n’a pas eu l’occasion de réaliser la vérification par authentification. En cas d’impayés frauduleux, l’émetteur est responsable |
| Point d’exclamation/ « Cardholder authentication failed! » |
91 | 2 | Votre client n’a pas réussi la vérification par authentification à cause d’un mot de passe ou d’un PIN incorrect par exemple. Notre plateforme n’exécute pas du tout l’étape d’autorisation et abandonne la transaction |
| Pas d’image/ « Cardholder authentication not technically possible!!! » |
92 | En fonction du résultat de l’autorisation par votre acquéreur et de votre préférence, soit 2 5 9 |
L’authentification n’a pas été possible en raison d’une erreur technique. Par défaut, notre plateforme n’exécute pas du tout l’étape d’autorisation et abandonne la transaction (statut 2). Cependant, notre plateforme vous permet de choisir de réaliser l’autorisation malgré tout, comme cela est décrit dans le chapitre dédié. |
| Pouce totalement levé/ « Cardholder has been successfully identified! V2 challenge » |
5 | En fonction du résultat de l’autorisation par votre acquéreur, soit 2 5 9 |
Votre client a réussi la vérification par authentification et s’est identifié activement conformément au protocole SCA (« Challenge flow » ou flux avec interaction). En cas d’impayés frauduleux, l’émetteur est responsable |
| Pouce totalement levé/ « Cardholder has been successfully identified! V2 frictionless » |
5 | En fonction du résultat de l’autorisation par votre acquéreur, soit 2 5 9 |
Le titulaire de la carte a été identifié avec succès. Étant donné que vous avez fourni suffisamment d’informations avec la transaction conformément au protocole SCA, votre client n’a pas dû s’identifier activement (« Frictionless flow » ou flux sans interaction) |
Veuillez noter qu’il s’agit d’informations données à titre indicatif uniquement, étant donné que la responsabilité définitive dépend de divers facteurs
3. Comprendre le fichier journal des authentifications
En plus de connaître le statut 3-D Secure de vos transactions, notre plateforme enregistre le fichier journal de chaque vérification par authentification. Ces fichiers contiennent des informations détaillées concernant le flux exact ayant mené au résultat de la vérification par authentification.
Consultez ces informations pour n’importe quelle transaction dans le Back Office via Opérations > Gestion transactions. En cliquant sur « AUTHENTICATION LOG » dans l’aperçu, vous avez accès à un tableau
| Colonne | Description |
|---|---|
| MsgType |
Étape exécutée de la vérification par authentification actuelle.
Si notre plateforme devait déployer 3-D Secure Version 1, les valeurs suivantes seraient possibles :
|
| Status |
Statut/résultat de l’étape effectuée.
Si notre plateforme devait déployer 3-D Secure Version 1, les valeurs suivantes seraient possibles :
|
| Date |
Horodatage de l’étape effectuée |
| Details |
Informations/paramètres de l’étape effectuée.
|
| Card N° |
La carte utilisée lors de l’étape concernée |
L’image montre où chercher les fichiers journaux d’authentification dans le Back Office
L’image montre un exemple de tableau contenant les fichiers journaux d’authentification dans le Back Office
Comprendre et gérer le retour à 3-D Secure v1
Il est possible que notre plateforme traite des transactions dans le mode 3-D Secure v1 (vérifier la colonne « MsgType » en conséquence dans le fichier journal d’authentification). Veuillez faire attention à ces éléments puisque la v1 sera totalement supprimée en octobre 2022. Pour vous aider à gérer des transactions de ce type, consultez le tableau présentant les causes et solutions possibles
| Message d’erreur (colonne « MsgType ») | Description | Solution |
|---|---|---|
| V2ParamMissing | Paramètres v2 obligatoires manquants | Assurez-vous de mettre votre DirectLink intégration à jour en conséquence. Si vous traitez des transactions via notre Page de paiement hebergée nous nous en chargeons pour vous |
| acquirerBIN/acquirerMerchantID not recognized | Vous devez vous être inscrit pour la v2 chez MasterCard | Veuillez-nous contacter ou contacter votre acquéreur pour le demander |
| "Detail":"billAddrCountry; V2Error caused fallback to v1 "Detail":"billAddrLine1,billAddrLine2 "Detail":"cardholderName; "Detail":"email; "Detail":"acctNumber; "Detail":"browserLanguage" "Detail":"acctInfo.nbPurchaseAccount,acctInfo.txnActivityDay,acctInfo.txnActivityYear" "Detail":"Name(s) of erroneous fields separated by (,) : acctInfo.suspiciousAccActivity,threeDSRequestorAuthenticationInfo.threeDSReqAuthMethod, acctInfo.shipAddressUsageInd,acctInfo.chAccAgeInd,acctInfo.shipNameIndicator,acctInfo.paymentAccAge,acctInfo.paymentAccInd,acctInfo.shipAddressUsage" |
Erreur reçue de la part du directory server (DS). Code ISO non valable conformément aux tableaux ISO (pour le pays ou la monnaie) |
Paramètre non valables envoyés pour les paramètres (v2 obligatoires) Assurez-vous de mettre votre DirectLink intégration à jour en conséquence. |
| Error received from the DS. Format of one or more elements is invalid according to the specification","Detail":"threeDSRequestorURL" | Les détails concernant votre site web dans le Back Office ne sont pas corrects (Configuration > Abonnement > Vos données administratives > Site Internet) |
Corrigez votre URL dans le Back Office |
| Specific reason fallbacks to V1 because transaction status will be blocked by issuer MC Fallback to V1 since Transaction status reason is 82 Cb Fallback to V1 since Transaction status reason is 13 |
Erreurs non spécifiées |
Ces erreurs se produisent chez un tiers. La solution ne dépend pas de nous |
4. Continuer/interrompre le flux de la transaction
Conformément aux directives PSD2, le statut 2 est attribué par défaut aux transactions pour lesquelles une vérification par authentification n’a pas pu être déployée en raison de problèmes techniques. Notre plateforme interrompt la transaction en n’exécutant pas l’autorisation du tout.
Cependant, vous pouvez annuler ce scénario par défaut en donnant l’ordre à la plateforme de continuer l’étape d’autorisation quoi qu’il en soit. Pour utiliser cette option, suivez ces étapes :
- Connectez-vous au Back Office. Rendez-vous sous Avancé > Fraud detection > 3D-Secure
- Sélectionnez la méthode de paiement pour laquelle vous voulez annuler le scénario par défaut en cliquant sur “EDITER”
- Select radio button option “Continuer” for both "Continuer/interrompre la transaction si un problème technique empêche de se connecter au répertoire de MasterCard durant la vérification de l'enrôlement 3D-Secure.” et “Continuer/interrompre la transaction si le système d'identification du titulaire est temporairement indisponible.”. Confirmez en cliquant sur “ENVOYER”
L'image montre où configurer la fonction Continuer / Interrompre dans le Back Office
- Si vous utilisez cette option, vous pouvez être tenu responsable des impayés frauduleux
- Il est très probable que le statut 2 soit toujours attribué à votre transaction, étant donné qu’en vertu de PSD2, tout acheteur en ligne doit réussir une vérification par authentification
-
5. Fin partielle du transfert de responsabilité
Tous les grands projets énumérés ci-après sont harmonisés et achevés pour que la mise hors service officielle de 3DS v1 ait lieu en octobre 2022 :
- VISA
- Mastercard
- American Express
- JCB
- Diners Discover
VISA et Mastercard ont d’ores et déjà annoncé une période de transition vers EMV 3DS.
En fait, seules les transactions entièrement authentifiées seront prises en charge par VISA et Mastercard, les commerçants utilisant 3DS v1 seront ainsi moins protégés contre la fraude.
Vous trouverez des informations dans le Back Office d’Ingenico sous « Titulaire de la carte non identifié : règles en matière de transfert de responsabilité qui s’appliquent (en fonction de la date de la transaction et du pays de la carte de crédit) » et ECI=12, dans le retour d’information après la vente.
Pour le même message « Titulaire de la carte non identifié : règles en matière de transfert de responsabilité qui s’appliquent (en fonction de la date de la transaction et du pays de la carte de crédit) » et ECI=6, le transfert de responsabilité reste en vigueur.
Visa
| Visa Secure 3DS V1 | Avant le 16 octobre 2021 | Après le 16 octobre 2021 |
|---|---|---|
| Entièrement authentifié (l’émetteur participe) | La responsabilité de la fraude est transférée à l’émetteur (ECI=5) | Aucun changement |
| Tentative d’authentification (émetteur non participant) | La responsabilité de la fraude est transférée à l’émetteur (ECI=12) | La responsabilité de la fraude est transférée au commerçant (ECI=12). Résultat du paiement=N |
Mastercard
| Mastercard Identity Check 3DS V1 | Avant le 5 octobre 2021 | Après le 5 octobre 2021 |
|---|---|---|
| Entièrement authentifié (l’émetteur participe) | La responsabilité de la fraude est transférée à l’émetteur (ECI=5) | Aucun changement |
| Tentative d’authentification (émetteur non participant) | La responsabilité de la fraude est transférée à l’émetteur (ECI=12) | La responsabilité de la fraude est transférée au commerçant (ECI=12). Résultat du paiement=N |