3D Secure

Qu'est-ce que 3D Secure ?

3D Secure, ou 3DS, est un protocole de sécurité pour les paiements en ligne conçu pour empêcher l'utilisation frauduleuse des cartes de crédit dans les transactions sans présentation de la carte (CNP). Ce protocole, développé en 1999, exige des étapes de vérification supplémentaires pour les clients au cours du processus d'achat afin de s'authentifier et de réduire le risque de fraude. Le flux ci-dessous présente un processus de paiement utilisant le protocole 3DS :

Où ?

  • L'interface MPI (Merchant Plugin Interface) lance le processus de vérification en facilitant l'échange sécurisé d'informations entre le commerçant, le serveur d'annuaire du système et la banque émettrice du titulaire de la carte.
  • Scheme Directory Server (DS) fait office de base de données centralisée et facilite l'identification de la banque émettrice du titulaire de la carte et de la méthode d'authentification correspondante à utiliser.
  • Le serveur de contrôle d'accès de l'émetteur (ACS) est chargé de vérifier et de valider l'identité du titulaire de la carte lors d'une transaction 3DS. Le serveur de contrôle d'accès de l'émetteur reçoit les demandes d'authentification et procède à l'évaluation des risques et aux contrôles d'authentification sur la base des règles et politiques prédéfinies de la banque.

3D Secure 2, ou 3DS2, publié en 2016, est une version mise à jour du protocole 3DS original et utilise des méthodes d'authentification dynamiques telles que la biométrie et l'authentification token, alors que le protocole 3DS original repose sur des mots de passe statiques. Le protocole 3DS2 vise à améliorer l'expérience de l'utilisateur et à rendre le processus d'authentification plus fluide pour l'utilisateur final. EMVCo, une organisation détenue par les principales marques de cartes, a développé et géré les deux protocoles. Toutes les grandes marques de cartes ont cessé de supporter la première version de 3DS en octobre 2022. Par conséquent, l'intégration de l'étape de vérification 3DS2 est essentielle pour garantir l'expérience et la sécurité de vos clients. Yuno propose déjà une intégration 3DS2 facile pour votre entreprise.

Logo du visa
Visa
Logo Mastercard
Mastercard
Logo American Express
American Express
Logo JCB
JCB
Logo Diners Club
Diners Club
Logo UnionPay
UnionPay
Logo de Cartes Bancaires
Cartes Bancaires

Avantages de 3D Secure 2

Comme nous l'avons mentionné, 3DS2 a été développé pour améliorer l'expérience de l'utilisateur et adapter le protocole 3DS au paysage moderne des paiements.

Préparés aux nouvelles technologies

3DS2 a été conçu en tenant compte de l'essor des smartphones et a permis aux banques d'offrir des expériences d'authentification innovantes par le biais de leurs applications bancaires mobiles, telles que l'authentification biométrique utilisant les empreintes digitales ou la reconnaissance faciale. Les commerçants peuvent donc proposer plusieurs méthodes d'authentification qui s'alignent sur les préférences des consommateurs et les avancées technologiques, ce qui se traduit par un processus d'authentification plus pratique et plus sûr.

Capacités d'intégration

En ce qui concerne l'intégration, 3DS2 comprend un composant SDK qui permet une intégration native dans les applications mobiles. Les commerçants peuvent ainsi authentifier les transactions dans leurs propres applications. Désormais, le flux de contestation se produit directement dans les flux de paiement mobile, ce qui élimine le besoin de redirections pleine page et offre une expérience plus transparente à l'utilisateur.

Quantité de données disponibles pour l'authentification

3DS2 permet aux entreprises d'échanger dix fois plus de données sur chaque transaction avec la banque du titulaire de la carte. Il s'agit notamment de données spécifiques au paiement, comme l'adresse de livraison, et de données contextuelles, comme l'identifiant de l'appareil du client ou l'historique des transactions précédentes. Cela permet à la banque d'évaluer le niveau de risque de la transaction et éventuellement d'authentifier le paiement sans que le titulaire de la carte n'ait à fournir d'informations supplémentaires. Par conséquent, un paiement utilisant les protocoles 3DS2 peut faire l'objet d'un flux sans friction ou d'un flux de défi pour compléter le paiement.

Flux Sans Friction

Dans un flux sans friction, les données du client sont confirmées sans aucune saisie manuelle. Cela se produit lorsque le système reconnaît et vérifie l'appareil du client et que les données sont échangées en arrière-plan. Le client étant identifié et validé par ces informations, aucune demande supplémentaire n'est nécessaire de la part des systèmes de paiement.

Flux de Défi

Le flux de difficultés survient lorsque les informations stockées ne suffisent pas à valider le client. Comme l'identité du client n'est pas confirmée, le système exige une étape supplémentaire pour valider le client, à l'aide d'un mot de passe à usage unique ou d'une vérification biométrique. Selon le système de validation, le client peut être redirigé vers une page de l'émetteur de la carte pour saisir les informations nécessaires.

L'utilisation de 3DS2 se traduit par une expérience utilisateur plus fluide et sans friction. L'amélioration des flux de données et des capacités de prise de décision permise par 3DS2 réduit le taux d'abandon du panier et améliore les taux de conversion.

Paiement 3D Secure 2

L'ajout de l'étape de vérification 3DS2 au processus de commande modifie le déroulement normal des opérations. Vous trouverez ci-dessous un organigramme du processus complet de vérification et une description de chaque étape pour vous aider à mieux comprendre le processus.

  1. Le client fournit les données de sa carte pour lancer la procédure de paiement du commerçant.
  2. Le système du commerçant vérifie s'il prend en charge le système 3DS2.
  3. Si le commerçant ne prend pas en charge le système 3DS2, le processus de paiement se déroule normalement, sans vérification du système 3DS2.
  4. Si le commerçant prend en charge le système 3DS2, Yuno envoie les informations relatives à la transaction au fournisseur de services 3DS de l'émetteur afin d'évaluer le risque de la transaction. Ces données comprennent des informations sur le titulaire de la carte et sur l'appareil, en fonction des restrictions régionales ou des lois du marché, telles que l'identifiant de l'appareil, l'adresse MAC, la géolocalisation, les transactions précédentes, etc.
  5. Le fournisseur de services 3DS de l'émetteur détermine si la transaction présente un risque élevé et s'il est nécessaire de procéder à une vérification supplémentaire.
  6. Le paiement passe à l'étape de l'autorisation si aucune contestation n'est nécessaire (flux sans friction).
  7. Si une contestation est nécessaire (flux de contestation), elle est présentée au titulaire de la carte pour vérifier son identité. Cette vérification peut faire appel à la biométrie et/ou à l'authentification à deux facteurs, comme un mot de passe à usage unique ou une fingerprint.
  8. Le système vérifie si le titulaire de la carte a réussi à relever le défi.
  9. Le paiement passe à l'étape de l'autorisation si le titulaire de la carte vérifie avec succès son identité.
  10. Si le titulaire de la carte ne vérifie pas son identité, le paiement est annulé.
  11. Le commerçant vérifie auprès de l'émetteur de la carte si la transaction est autorisée.
  12. Si la transaction est autorisée, le paiement est traité avec succès.
  13. Si la transaction n'est pas autorisée, le paiement est annulé ou refusé.

Configurer 3D Secure pour vos paiements

📘

Amélioration du SDK v1.1

Avec le SDK v1.1, la logique 3DS est gérée automatiquement à l'aide de la fonction continuePayment() aucune configuration distincte de 3DS n'est nécessaire. Pour plus d'informations, voir la page Documentation du SDK Web Yuno.

Vous décidez si votre système implémentera le 3DS2 ou non. L'étape de vérification 3DS2 est ajoutée lors de la définition du routage dynamique de vos cartes. Lorsque vous démarrez vos routes de cartes, vous pouvez ajouter l'étape 3DS2 avant de définir le fournisseur de paiement. Lorsque l'étape de vérification 3DS2 est ajoutée, lors de l'initialisation d'un paiement par carte, le système Yuno analyse si la carte a besoin d'une vérification supplémentaire. Si un défi supplémentaire est nécessaire, l'utilisateur sera redirigé vers l'environnement bancaire pour compléter l'autorisation. En revanche, le processus de paiement se déroulera normalement.

Pour créer des paiements avec le flux de travail 3DS DIRECT, vous devez remplir certaines conditions.

Prérequis

Avant d'utiliser 3DS DIRECT, vous devez activer 3DS dans votre tableau de bord Yuno et spécifier les scénarios dans lesquels vous souhaitez que vos clients puissent l'utiliser. Ceci peut être configuré dans le Yuno Dashboard sous : Routing > Card Routes > 3DS Step. Ces scénarios doivent être indiqués sur votre itinéraire CARD. En outre, vous aurez besoin des données de configuration 3DS suivantes dans la connexion du fournisseur de paiement :

  • BIN de l'acquéreur: il s'agit du numéro d'identification de la banque (BIN) utilisé pour compenser et régler la transaction, ainsi que le pays dans lequel il est autorisé à être utilisé.
  • Merchant ID: Il s'agit du numéro d'affiliation fourni par l'acquéreur.
  • Code de catégorie de commerçant (MCC): L'acquéreur fournira un code spécifique représentant votre catégorie de commerçant.
  • Nom du commerçant: Il s'agit du nom officiel ou de la raison sociale de l'entreprise ou de l'entité qui effectue la transaction commerciale.
  • URL du marchand: Le site web ou la plateforme en ligne du commerçant.
  • Code pays: Le pays où le paiement doit être traité, selon la norme ISO 3166-1 Codes pays.
📘

Utilisation d'une interface MPI externe pour l'authentification

Si vous utilisez une interface MPI externe pour effectuer l'authentification, les paramètres suivants sont requis pour une connexion réussie avec le fournisseur :

  • BIN de l'Acquéreur
  • Code pays de l'acquéreur
  • ID commerçant
  • MCC

Intégration de Yuno 3D Secure 2

Il existe différentes façons d'intégrer 3DS dans Yuno, en fonction de vos besoins.

D'une manière générale, une intégration 3DS nécessite une setup_id/device_fingerprint pour la session de paiement comme première étape de l'analyse de sécurité, et cet identifiant ne peut être obtenu qu'en exécutant un SDK/JS fourni par un fournisseur autorisé 3DS. En utilisant nos SDK nous nous occupons de toute la logique pour vousVous n'avez donc pas à vous préoccuper des différents besoins des fournisseurs.

Par conséquent, en fonction de votre intégration Yuno, vous avez trois options différentes :

  1. Intégration de la caisse: Le flux de travail de la caisse fait partie de la solution de caisse fournie par Yuno. Utilisez nos SDK afin que nous puissions gérer toute la logique concernant les exigences des fournisseurs externes et les exécutions pour 3DS. Si vous souhaitez définir des cas spécifiques pour l'analyse 3DS, vous pouvez le faire dans la route CARD de votre tableau de bord Yuno.
  2. Intégration externe: Utilisez votre propre 3DS et envoyez les champs d'autorisation correspondants lors de la création du paiement (card_data - eci, cryptogramme, etc.). Uniquement disponible pour les commerçants conformes à la norme PCI.
  3. Intégration directe: Le flux de travail direct n'est disponible que pour les commerçants conformes à la norme PCI. Il offre un moyen simple de créer un paiement et de valider les informations de l'utilisateur, le commerçant n'ayant qu'une seule requête à effectuer pour créer le paiement. Pour mettre en œuvre avec succès l'intégration directe, suivez les étapes décrites dans le guide de l'intégration directe. guide d'intégration et fournissez les informations requises selon les instructions. Pour chaque paiement, vous disposerez d'un :
    1. PENDING/WAITING_ADDITIONAL_STEP statut/sous statut.
    2. sdk_action_required défini sur true.
    3. redirect_url défini dans payment.payment_method.payment_method_detail.card.

Vous êtes responsable de rediriger vos clients vers l'URL fournie par la fonction redirect_url afin que nous puissions recueillir des informations sur l'appareil et présenter le défi au client si nécessaire. Une fois que le client a réussi le défi 3DS, il est automatiquement redirigé vers la page d'accueil du site Web de la callback_urlque vous avez fourni lors de la création du paiement à l'aide du endpoint Create Payment.

Pour chaque scénario, les webhooks de Yuno vous informent rapidement du résultat du challenge 3DS et de l'état final du paiement. Vous serez ainsi informé en temps réel de la progression et de l'achèvement de la transaction de paiement. De plus, vous pouvez toujours obtenir les informations relatives au paiement en utilisant notre service d'obtention de paiement.

Après avoir exécuté le 3DS pour chaque scénario, vous recevrez toutes les informations nécessaires dans la réponse du paiement à l'intérieur de la balise payment_method.detail.card.card_data.three_d_secure objet :

ChampDescriptionExemple
versionFait référence à la version du protocole de la spécification EMV 3-D Secure utilisée. 1.0, 2.0, 2.1.0, 2.2.0, 2.2.1.2.2.1
indicateur_commerce_électroniqueCe champ doit être complété par le résultat du champ ECI fourni par le service 3D Secure. L'indicateur de commerce électronique (ECI) indique à l'émetteur de la carte si la transaction a été protégée par un protocole de sécurité tel que VbV ou MCSC. Visa et MasterCard exigent que cette valeur soit indiquée dans la demande d'autorisation pour toutes les transactions 3-D Secure (MAX : 2, MIN : 0).04
cryptogrammeCe champ doit être complété par le résultat du champ cryptogramme fourni par le service 3DSecure. Dans les transactions Visa, il représente la valeur de vérification de l'authentification du titulaire de la carte (CAVV), une valeur cryptographique générée par l'émetteur comme preuve de l'authentification du paiement lors d'un achat en ligne pour bénéficier de la protection contre la rétrofacturation. Les transactions MasterCard ont une valeur similaire appelée Accountholder Authentication Value (AAV) ou Universal Cardholder Authentication Field (UCAF). Lorsqu'il soumet une transaction pour autorisation, le commerçant doit inclure le CAVV ou l'AAV/UCAF pour prouver que le titulaire de la carte a été authentifié. Il est généralement codé en base64 (MAX : 40, MIN : 0).BA0BB1Z3N5Q4kjkBU3c3ELGUsJY =
transaction_idPour 3DS v1 : il s'agit de l'identifiant unique de la transaction. Il est généré automatiquement par le MPI. Il a généralement une longueur de 28 octets et est codé en base64. Il est communément appelé XID (MAX : 40, MIN : 0). Pour 3DS v2 : Identifiant de transaction universellement unique attribué par le DS pour identifier une seule transaction. (MAX : 36, MIN:36).Ex pour V1 : "TjY0MjAxRjA4MD4987DUzMzYyNjU=" Ex pour V2 : “c4e59ceb-a382-4d6a-bc87-385d591fa09d”
directory_server_transaction_idID de transaction généré par le serveur d'annuaire Mastercard lors de l'authentification (MAX 255 ; MIN 3).f38e6948-5388-41a6-bca4-b49723c19437
pares_statusIndique le résultat de l'authentification du titulaire de la carte au cours du processus 3-D Secure. Il vous indique si l'authentification a réussi (O), échoué (N), n'a pas pu être réalisée (U) ou a seulement été tentée (A).Y
acs_idIdentifiant unique fourni par le serveur de contrôle d'accès (ACS) au cours de la procédure d'authentification 3-D Secure.ACS-1234567890
[...]
     "payment_method": {
        "vaulted_token": "",
        "type": "CARD",
        "vault_on_success": false,
        "token": "",
        "detail": {
            "card": {
                "verify": false,
                "capture": false,
                "installments": 1,
                "installments_plan_id": null,
                "first_installment_deferral": 0,
                "installments_type": "",
                "installment_amount": null,
                "soft_descriptor": "",
                "authorization_code": "",
                "retrieval_reference_number": "",
                "voucher": null,
                "card_data": {
                    "holder_name": "John Doe",
                    "iin": "40000000",
                    "lfd": "1026",
                    "number_length": 16,
                    "security_code_length": 3,
                    "brand": "VISA",
                    "issuer_name": "",
                    "issuer_code": null,
                    "category": "STANDARD",
                    "type": "CREDIT",
                    "three_d_secure": {
                        "version": "2.1.0",
                        "electronic_commerce_indicator": null,
                        "cryptogram": null,
                        "transaction_id": null,
                        "directory_server_transaction_id": null,
                        "pares_status": null,
                        "acs_id": "z1A6ZTh7NopIhdb2R420"
                    }
                }
[...]

Statut des transactions

Une transaction 3DS fonctionne de manière similaire à une transaction d'achat classique. Elle passe par différents états qui représentent le processus d'autorisation. Une fois que la transaction 3DS est marquée comme SUCCEEDED, Yuno passe au processeur et génère une transaction d'ACHAT pour facturer le client. Le tableau suivant décrit tous les états possibles et leurs descriptions.

StatutDescription
CRÉÉLe paiement est créé et attend l'identifiant de session SDK de Yuno.
PENDINGLe défi est à relever, et la redirect_url est renvoyée par Yuno.
IN_PROCESSL'utilisateur est en train de relever le défi.
SUCCÈSLe défi a été relevé correctement.
REFUSÉLe défi a été relevé mais refusé par la banque.
ERREURUne erreur s'est produite lors de la redirection vers le défi de l'utilisateur.

Comme mentionné précédemment, si le paiement est PENDING, la transaction 3DS sera PENDING défi est requis. Une fois le défi terminé, qu'il ait été réussi ou non, le paiement et la transaction seront mis à jour vers les statuts correspondants (SUCCEEDED DECLINED).

Utilisation de 3DS pour des scénarios spécifiques

Lors de la configuration de la route CARD dans le tableau de bord Yuno, vous pouvez spécifier les situations pour lesquelles 3DS doit être exécuté en utilisant les conditions disponibles. Comme indiqué précédemment, certaines étapes préliminaires seront nécessaires pour exécuter le 3DS en fonction de la méthode d'intégration utilisée.