3DS2, SCA et taux d'acceptation. 7 chapitres et un QCM final.

Chapitre 1. DSP2 et l'authentification forte : le cadre.

La DSP2 (directive UE 2015/2366) a fait de l'authentification forte du client, la SCA (Strong Customer Authentication), une obligation légale qui couvre tout paiement électronique initié par le payeur dans l'Espace économique européen. Les modalités techniques sont fixées par les RTS (règlement délégué UE 2018/389). Ce texte, et non la directive elle-même, définit les facteurs, le dynamic linking et surtout les exemptions qui font l'objet de ce cours. Pour un e-commerçant, la SCA n'est pas qu'une contrainte de conformité. Mal gérée, elle coûte plusieurs points de conversion. Bien gérée, elle devient un avantage concurrentiel mesurable.

Les trois facteurs d'authentification

• Connaissance, quelque chose que seul le client sait : mot de passe, code secret. Le numéro de carte, la date d'expiration et le CVV n'en font pas partie (données imprimées sur la carte).
• Possession, quelque chose que seul le client détient : téléphone enrôlé (app bancaire, SIM), carte elle-même via cryptogramme dynamique, token matériel.
• Inhérence, quelque chose que le client est : empreinte digitale, reconnaissance faciale, biométrie comportementale (admise sous conditions par l'EBA).
• La SCA exige au moins deux facteurs de catégories différentes, indépendants : la compromission de l'un ne doit pas compromettre l'autre (art. 4(30) DSP2 et art. 9 RTS). Le SMS OTP seul (possession) + rien d'autre n'est pas une SCA ; SMS OTP + mot de passe en est une, mais l'EBA la juge fragile (SIM swap).

Chapitre 2. Le flux 3DS2 : frictionless et challenge.

EMV 3DS fait dialoguer trois domaines. Le 3DS Server siège côté acquéreur/PSP (domaine commerçant), le Directory Server (DS) est opéré par le scheme (domaine d'interopérabilité), l'ACS, Access Control Server, se tient côté émetteur (domaine émetteur). Toute la valeur du protocole tient dans un message, l'AReq (Authentication Request), qui transporte une centaine de champs de contexte. L'ACS y score le risque avant de décider s'il impose un challenge au porteur.

Frictionless ou challenge : la décision appartient à l'ACS

{
  "messageType": "AReq",
  "messageVersion": "2.2.0",
  "threeDSRequestorAuthenticationInd": "01",  // 01 = paiement ; 02 = recharge ; 04 = ajout de carte
  "threeDSRequestorChallengeInd": "01",       // 01 = pas de preference ; 05 = demande d'exemption TRA (v2.2)
  "acctNumber": "4970100000004321",           // PAN ou network token
  "purchaseAmount": "14250",                  // 142,50 EUR (exposant 2)
  "purchaseCurrency": "978",
  "browserIP": "92.184.105.17",
  "browserUserAgent": "Mozilla/5.0 ...",
  "browserTZ": "-120",                        // fuseau horaire du device en minutes
  "deviceChannel": "02",                      // 01 = SDK app, 02 = navigateur, 03 = 3RI
  "acctInfo": {
    "chAccAgeInd": "05",                      // compte client > 60 jours : signal issuer-friendly
    "nbPurchaseAccount": "11",                // achats sur 6 mois
    "suspiciousAccActivity": "01"             // pas d'activite suspecte observee
  },
  "merchantRiskIndicator": {
    "shipIndicator": "01",                    // livraison a l'adresse de facturation
    "deliveryTimeframe": "03",                // expedition sous 24 h (overnight)
    "reorderItemsInd": "02"                   // re-commande d'un article deja achete
  }
}

Chapitre 3. Données device et scoring de risque.

Là où 3DS1 transportait une dizaine de champs, EMV 3DS en véhicule plus d'une centaine (jusqu'à ~130 via SDK mobile). Ces champs sont le carburant du frictionless. Plus l'ACS reçoit de signaux exploitables, plus son moteur de risque peut authentifier sans challenge. Un intégrateur qui n'envoie que les champs obligatoires condamne mécaniquement ses clients au challenge, ou au refus.

• Données navigateur (deviceChannel 02) : IP, user-agent, langue, fuseau horaire, résolution d'écran, profondeur de couleur, support Java/JS, collectées via la « 3DS Method » (iframe cachée de l'ACS) avant l'AReq.
• Données SDK (deviceChannel 01, apps mobiles) : identifiants device, version OS, paramètres système, indicateurs d'intégrité, nettement plus riches et plus fiables que le navigateur.
• Merchant risk indicators : type de livraison, adresse de livraison vs facturation, délai de livraison, carte cadeau, précommande, re-commande.
• Historique du compte client (acctInfo) : ancienneté du compte, nombre d'achats sur 6 mois, tentatives d'ajout de carte sur 24 h, activité suspecte constatée, ancienneté de l'adresse de livraison.
• Données optionnelles émetteur-spécifiques : champs 3RI, données de travel & hospitality (EMV 3DS 2.2/2.3) pour les secteurs à autorisations différées.

{
  "acctInfo": {
    "chAccAgeInd": "05",           // compte cree il y a plus de 60 jours
    "chAccChangeInd": "04",        // derniere modification > 60 jours
    "chAccPwChangeInd": "05",      // dernier changement de mot de passe > 60 jours
    "nbPurchaseAccount": "11",     // 11 achats sur les 6 derniers mois
    "provisionAttemptsDay": "0",   // 0 tentative d'ajout de carte sur 24 h
    "txnActivityDay": "1",         // 1 transaction sur 24 h
    "txnActivityYear": "14",       // 14 transactions sur 12 mois
    "shipAddressUsageInd": "04",   // adresse de livraison utilisee depuis > 60 jours
    "shipNameIndicator": "01",     // nom de livraison = nom du titulaire du compte
    "suspiciousAccActivity": "01"  // aucune activite suspecte
  }
}

Versions du protocole : 2.1, 2.2, 2.3

• 2.1.0 (2017) : socle EMV 3DS. Pas de champ dédié aux exemptions. Elles passent par des bricolages dans threeDSRequestorChallengeInd.
• 2.2.0 (déc. 2018) : version de référence en Europe. Ajoute les indicateurs d'exemption natifs, l'authentification découplée (decoupled authentication), le 3RI étendu et les indicateurs whitelist (bénéficiaires de confiance).
• 2.3.1 (2021-2022) : device binding, support WebAuthn/passkeys (préparation de la SPC), meilleure gestion app-to-app, canal navigateur enrichi. Déploiement encore progressif chez les ACS.

Chapitre 4. Liability shift : qui paie la fraude ?

Le liability shift transfère la responsabilité financière de la fraude (chargebacks pour motif fraude) du commerçant vers l'émetteur. Deux situations l'ouvrent, quand la transaction a été authentifiée ou quand l'émetteur a eu l'occasion de l'authentifier. Authentifier coûte de la conversion et protège des impayés fraude. Cette tension est l'incitation économique centrale de 3DS, ce qui fait de toute stratégie d'exemption un arbitrage explicite entre conversion et exposition à la fraude.

Le véhicule technique du liability shift est le couple ECI + cryptogramme transmis en autorisation. Chez Visa, l'ECI 05 signale une authentification complète, 06 un attempt, 07 une transaction non authentifiée, quand chez Mastercard, 02 vaut pour complète, 01 pour attempt, 00 pour non authentifiée. Un PSP qui dégrade l'ECI (mauvais mapping, perte du CAVV) fait perdre silencieusement la protection au commerçant, un point d'audit classique.

Chapitre 5. Les exemptions SCA : panorama complet.

Les RTS prévoient des exemptions. La transaction est dans le champ de la SCA mais peut en être dispensée. À ne pas confondre avec les cas hors champ (MIT, MOTO, one-leg, prépayé anonyme), où la SCA ne s'applique tout simplement pas. Règle d'or, l'émetteur reste toujours le décideur final. Une exemption demandée par l'acquéreur peut être refusée, l'émetteur répondant alors par un soft decline pour forcer l'authentification.

TRA : l'exemption reine et ses seuils

Le taux s'apprécie au niveau du PSP demandeur (l'acquéreur pour une exemption acquéreur), toutes transactions à distance confondues, et non au niveau du marchand. Un marchand très propre chez un acquéreur dégradé hérite du plafond de ce dernier. Ce critère pèse dans le choix de l'acquéreur, et reste trop souvent ignoré. Au-delà de 500 €, aucune exemption TRA n'existe. Le challenge devient obligatoire, sauf autre exemption applicable (bénéficiaires de confiance, récurrent) ou cas hors champ.

MIT et hors champ. Une transaction initiée par le commerçant (abonnement, usage, complément) relève du hors champ, et non d'une exemption, parce que le porteur n'est pas là pour s'authentifier. En contrepartie, la transaction initiale qui établit le mandat (enregistrement de carte, premier prélèvement) doit être authentifiée SCA. Chaque MIT doit ensuite être chaînée à cette initiale via l'identifiant de transaction réseau. Un flag MIT sans chaînage valide sera de plus en plus souvent refusé par les émetteurs.

Chapitre 6. Soft declines 65/1A : le refus qui n'en est pas un.

Un soft decline n'est pas un refus de payer, l'émetteur répondant « je veux une authentification avant d'autoriser ». Il survient quand une autorisation arrive sans authentification ni exemption acceptée : tentative d'exemption TRA refusée, MIT mal flaguée, flux non-3DS hérité. Le traiter comme un refus définitif fait perdre la vente. Cette fuite de conversion est l'une des plus coûteuses, et l'une des plus faciles à corriger.

1) POST /authorize        montant 89,00 EUR, ECI 07, flag exemption TRA acquereur
   < response_code: 65    Visa -- "Authentication requested" (soft decline)
                          Mastercard equivalent : code 1A

2) Le PSP declenche automatiquement une authentification 3DS2
   AReq -> ARes transStatus "C" -> challenge app bancaire -> RReq "Y"
   CAVV genere, ECI passe a 05

3) POST /authorize        meme montant, ECI 05 + CAVV
   < response_code: 00    Approved

Delai total ajoute : 15 a 45 s (le temps du challenge).
Taux de recuperation observe apres retry authentifie : 70 a 90 %.

L'instrumentation repose sur trois indicateurs distincts, à suivre séparément. La part de soft declines dans les refus révèle une stratégie d'exemption trop agressive ou des MIT mal flaguées. Le taux de déclenchement du retry authentifié doit tendre vers 100 % des 65/1A. Le taux de récupération final, enfin, est attendu à 70-90 %, en dessous de quoi il faut chercher un problème d'UX de challenge ou un ACS défaillant sur certains BIN.

Chapitre 7. Stratégie d'exemption et optimisation de l'acceptation.

Une stratégie d'exemption ne se réduit pas à une liste de flags. Elle prend la forme d'un arbre de décision par transaction, alimenté par le montant, le segment client, le BIN émetteur et l'historique de réponse des émetteurs. Les meilleurs dispositifs le rendent dynamique, apprenant émetteur par émetteur quelles demandes d'exemption sont acceptées et ajustant le routage en conséquence.

• Hors champ d'abord : MIT correctement chaînée ? MOTO ? One-leg ? → autorisation directe avec les bons indicateurs, pas de 3DS.
• Wallet authentifiant (Apple Pay/Google Pay avec CDCVM) ? → la SCA est déléguée au device, pas de 3DS marchand.
• Montant ≤ 30 € → tenter LVP (en acceptant le risque de challenge-surprise sur compteurs).
• Montant ≤ plafond TRA de l'acquéreur et segment sain → demander l'exemption TRA, en autorisation directe ou via le flag 3DS2 (v2.2).
• Sinon → 3DS2 complet avec données maximales (acctInfo, merchant risk indicators) pour viser le frictionless.
• Dans tous les cas → gestion automatique du soft decline 65/1A avec retry authentifié.

Mesurer : le funnel d'acceptation de bout en bout

• Données issuer-friendly : acctInfo complet, cohérence adresse/nom, IP non masquée, le levier le moins cher.
• Retry intelligent : au-delà du soft decline, requalifier les refus rejouables (05 « do not honor » différé) vs définitifs (14, 41, 43 : ne jamais rejouer).
• Routage multi-acquéreur : router chaque BIN vers l'acquéreur qui obtient le meilleur taux d'autorisation et le meilleur plafond TRA ; gains typiques de 1 à 3 points.
• Network tokens : taux d'autorisation supérieur de 2 à 3 points en moyenne sur les flux card-on-file (voir le cours Tokenisation).
• Delegated authentication / SPC : déléguer la SCA au marchand ou au device (passkeys) pour supprimer le challenge, encore émergent et à suivre.