3-D Secure 2. 0 et SCA

1) Pourquoi l'opérateur iGaming est-il 3DS2 et qu'est-ce que SCA

3-D Secure 2. x (EMV 3DS) est le protocole d'authentification du titulaire de carte dans l'e-commerce.
Le SCA (Strong Customer Authentication) est une exigence réglementaire (PSD2/UK) qui oblige à effectuer une vérification à deux facteurs dans un certain nombre de scénarios.

• Liability shift : lorsque l'authentification réussie, le risque de fraude passe à l'émetteur.
• Ci-dessus la conversion vs 3DS1 : la collecte de 100 + data-elements permet une frictionless sans challenge.
• Scripts natifs : SDK pour iOS/Android, in-app, decouped et out-of-band de confirmation.

2) Rôles et composants (EMV 3DS)

3DS Server (chez vous ou chez PSP) : génère des requêtes vers le schéma, agrège les données du device, gère les versions 2. 1/2. 2/2. 3.
Répertoire Server (DS) : routeur de schémas (Visa/Mastercard/AmEx, etc.).
Serveur de contrôle d'accès (ACS) : serveur de l'émetteur ; décide : frictionless ou challenge.
SDK/Method : collecte des signaux device (fingerprinting), web-SDK/iframe et mobile-SDK.

3) Flux UX types

3. 1 Frictionless (pas de challenge)

1. Merchant/PSP → DS : AReq avec données 3DS (device, historique, signaux de risque).
2. DS/ACS → ARes (frictionless) : l'authentification a été effectuée sans la participation de l'utilisateur.
3. Ensuite, → l'autorisation (Auth).

Quand il est déclenché : faible risque, whitelist (Trusted Beneficiary), LVP, données qualitatives.

3. 2 Challenge (avec challenge)

1. ARes nécessite CReq/CRes (OTP, confirmation push dans la banque, biométrie).
2. Après le succès, l'autorisation →, liability shift enregistré.

3. 3 Decoupled / Out-of-Band

Confirmation dans l'application de la banque sans redirect. Utile dans les scénarios mobiles.

3. 4 3RI (3DS Requestor Initiated)

Utilisé pour le MIT (merchant-initiated transactions) - abonnements, retraits. Il n'y a pas de SCA à chaque répétition, mais il faut une référence correcte au CIT initial.

4) SCA : où est obligatoire et où agit

Obligatoire : la plupart des transactions de commerce électronique dans l'EEE/Royaume-Uni si l'émetteur et l'acquéreur dans la zone SCA.
Out-of-scope : MOTO (courrier/téléphone), certaines chaînes d'entreprise, itinéraires inter-zones (TRA de l'émetteur peut s'appliquer).

4. 1 Exceptions

TRA (Transaction Risk Analysis) : faible risque pour le fournisseur/la banque (confirmé par les métriques frod).
LVP (Low-Value Payments) : petites sommes, avec les seuils et les compteurs de l'émetteur.
Whitelist (Trusted Beneficiary) : destinataire sur la liste blanche du client de l'émetteur.
Secure Corporate/Merchant Initiated (MIT) : débits ultérieurs hors SCA s'il y a un CIT initial avec SCA et références correctes.

5) Marquage des transactions et drapeaux pour iGaming

CIT (Customer Initiated Transaction) : le prélèvement primaire, nécessite généralement un SCA (ou exemption).
MIT Recurring/Unscheduled COF : débits ultérieurs ; n'exigent pas de SCA lorsqu'il existe un lien avec le CIT initial (références/identifiants interarmées).
Les indicateurs corrects dans les requêtes PSP/schéma sont critiques pour la liability shift et l'omission de SCA sur les répétitions.

6) Données affectant la décision ACS

• Device/Browser: user-agent, accept headers, screen, timezone, language.
• Données de compte : âge du compte, date du dernier mot de passe, nombre de connexions échouées.
• Données de transaction : MSS/catégorie, montant/devise, tentatives précédentes, velocity.
• Shipping/Billing : correspondance d'adresse, historique du destinataire.
• 3DS method completion indicator : a-t-il eu le temps de travailler 3DS Method (fingerprint).
• Plus le contexte est riche - plus la chance de frictionless est élevée.

7) Flux d'intégration avec l'orchestrateur de paiement

7. 1 Séquence (web/mobile)

1. Initiate 3DS (3DS Server ↔ DS/ACS) → obtenir ARes.
2. Si challenge → travailler CReq/CRes via SDK/iframe.
3. Succès → Auth (autorisation) avec indication du résultat 3DS (ECI, CAVV/cryptogramme, dsTransID).
4. Webhook PSP → orchestrateur → Ledger/DWH (sans PAN).

7. 2 Soft-decline et retrai

L'autorisation sans SCA peut retourner « soft-decline (code) » → refaire le paiement avec SCA.
L'orchestrateur tient une machine d'essai : no SCA → soft-decline → 3DS2 → Auth.

7. 3 Multi-PSP

Vérifiez la prise en charge des versions 3DS (2. 1/2. 2/2. 3), app-SDK, decoupled.
Routage intelligent : si vous dégradez ACS chez une partie des émetteurs, utilisez le chemin de secours (si les politiques/schémas le permettent).

8) modèles UX qui augmentent la conversion

Native/SDK dans les applications mobiles : moins de radiés, plus d'achèvement.
Pré-collect de données (e-mail, adresse, signaux comportementaux) jusqu'à 3DS.
Écrans d'attente transparents et textes compréhensibles (localisation par langue/région).
Timaouts avec un léger retour à payer et une répétition du challenge.
Whitelisting prompt : invitez le client à ajouter un merchant à la banque de confiance (si disponible).

9) Erreurs et cas extrêmes

Timeout/Unavailable ACS → les codes corrects et la répétition (ou fallback par stratégie).
Version downgrade : si 2. 2/2. 3 n'est pas disponible, retour à la version compatible.
Méthode partiale : si la méthode 3DS n'est pas terminée, envoyez toujours AReq - mieux vaut des données partielles que zéro.
Mixed flows : à la fois 3DS + AVS address vérification - mapper correctement les statuts.
Chargeback après 3DS : contester avec des artefacts (ECI, CAVV, ARes/CRes refs).

10) Documents et artefacts à conserver

ID de transaction 3DS (dsTransID, threeDSServerTransID).
Résultats d'authentification (ECI, CAVV/AVV, statuts ARes/CRes).
Logs SDK (sans PII/PAN), temporisation et codes d'erreur.
Liens MIT vers le CIT initial pour les abonnements/répétitions.
Politiques de traitement des exclusions soft-decline et TRA.

11) Métriques et objectifs (KPI pour iGaming)

Conversion

3DS completion rate (proportion d'authentification réussie).
Proportion de frictionless vs challenge (l'objectif est de ↑ frictionless).
Taux d'absentéisme sur les écrans 3DS.

Risque

Raid frod après liability shift (ci-dessous - mieux).
Part de soft-decline et succès des retraits ultérieurs avec 3DS.

Technique

Temps 3DS p95 (initiation → résultat).
Erreurs SDK/iframe, délais ACS.

12) Chèque de démarrage 3DS2 + SCA

• 3DS Server est connecté (version 2. 1/2. 2/2. 3), bins de test ont travaillé.
• Les SDK Web/Mobile-SDK sont intégrés (scripts in-app + webview).
• Collecte de données de vice/browser incluse (3DS Method).
• Les étiquettes CIT/MIT/COF sont correctes ; le lien vers le CIT initial est stocké.
• Le flux soft-decline → la répétition avec SCA est implémenté dans l'orchestrateur.
• Les expériences (TRA/LVP/whitelist) sont configurées et les causes/résultats sont logés.
• Multi-PSP : les versions 3DS et fallback sont validées.
• Дэшборды KPI: frictionless %, challenge success %, abandon, soft-decline.
• Les politiques de stockage des artefacts 3DS et dispute-playbooks sont prêtes.
• Les tests A/B des indices UX (localisation, textes, temporisations) sont prévus.

13) Interconnexion avec PCI DSS et Tokenization

3DS2 ne remplace pas PCI DSS : il est sur l'authentification et PCI sur la protection des données.
Pour PAN-safe : entrer la carte dans les champs/iframe hébergés ; l'orchestrateur ne voit que des jetons et des artefacts 3DS (ECI/CAVV).
Pour COF/MIT, utilisez des tokens réseau ou des jetons vault pour réduire les frondes et augmenter l'autorisation.

14) FAQ court

Dois-je toujours faire 3DS ? Dans la zone SCA, oui s'il n'y a pas d'exposition/exclusion correcte. L'émetteur peut exiger un challenge.
Si la banque est cassée ? Utilisez des stratégies de retraits/temporisations et, si possible, un itinéraire différent.
3DS donnera-t-il une augmentation de la conversion ? Un 3DS2 bien configuré avec des données riches augmente la proportion de frictionless et réduit frod/charjbecky.
Quelle est la chose la plus critique pour réussir ? Données contextuelles riches, drapeaux CIT/MIT/COF corrects, UX rapide et traitement soft-decline compétent.

15) Résumé

Pour iGaming, la 3DS2 + SCA n'est pas une « douleur obligatoire », mais un outil de croissance : plus de frictionless, moins de frod, transfert de responsabilité à l'émetteur, monétisation stable des abonnements et des prélèvements. Placez les drapeaux appropriés (CIT/MIT/COF), maintenez les expériences selon les règles, assurez l'entrée pan-sécurisée et construisez un orchestrateur avec des rétrécissements et une observabilité intelligents - alors l'authentification deviendra un allié et non un frein à la conversion.