Comment implémenter l'authentification 3DS pour le SaaS, les logiciels et les jeux vidéo

Pour intégrer l'authentification 3DS dans votre système de paiement, vous devez intégrer une solution de paiement qui prend en charge ce protocole, ce qui ajoute une étape supplémentaire aux paiements par carte en ligne pour des raisons de sécurité.  Ceci est crucial pour réduire la fraude et se conformer à différentes règles, telles que l'authentification forte du client (SCA) de l'UE.

Ce guide propose des instructions étape par étape sur la manière d'intégrer 3DS et d'améliorer vos processus de paiement, ce qui vous aidera à créer un système conforme.

L'exécution réussie de cette stratégie nécessite un MoR ou un processeur de paiement entièrement compatible avec le 3DS 2 protocole moderne.

Pour commencer, vous devez sélectionner un partenaire de paiement mondial adapté qui est certifié pour effectuer le protocole 3DS 2 et également capable de revenir au 3DS 1 si nécessaire. Ce partenaire prendra en charge la communication entre votre système SaaS, le réseau de cartes et la banque émettrice. L'acquisition 3DS peut être envisagée à ce stade. Votre équipe de développement devra décider s'il faut utiliser une simple Page de Paiement Hébergée, ce qui économise du temps et de l'argent sur l'intégration, ou une Intégration API/SDK directe, ce qui offre plus de contrôle sur l'apparence et l'expérience de la page de paiement.

Votre partenaire doit être certifié et se conformer à toutes les spécifications EMV 3DS, évitant ainsi les complications lors de la mise en œuvre du protocole de sécurité sur les différents réseaux de cartes.

1. Sélectionnez le type d'intégration : L'option la plus simple est d'utiliser une Page de paiement hébergée, dans laquelle le partenaire gère le traitement des transactions. Si un plus grand contrôle de l'expérience utilisateur est souhaité, Intégration API/SDK directe peut être utilisé, donnant accès à un éventail plus large de fonctionnalités Stripe.  
2. Vérifier la Certification : Assurez-vous que votre partenaire est à jour des dernières spécifications EMV 3DS. 

Le succès du bon déroulement dépend de la précision des données fournies. 3DS 2 nécessite jusqu'à 100 points de données pour déterminer le risque, votre système doit donc collecter et envoyer ces informations lors de chaque demande de transaction.

Il est nécessaire d'inclure dans le système de paiement tous les champs nécessaires, qui comprennent l'adresse IP, l'e-mail et le nom du titulaire de la carte, en plus des données contextuelles nécessaires provenant de vos systèmes. L'ajout d'informations contextuelles telles que l'ancienneté du compte du client ou son historique d'achats aide le moteur de risque de la banque à approuver le paiement sans vérification supplémentaire.

1. Champs de données obligatoires : Assurez-vous que votre système de paiement collecte et transmet toutes les informations nécessaires, y compris l'adresse IP du client, l'adresse de facturation, le nom complet du titulaire de la carte, l'adresse e-mail et le numéro de téléphone.
2. Enrichissement des données contextuelles : Intégrez les informations back-end dans la demande de paiement. L'analyse basée sur les risques nécessite l'accès à des données client essentielles, notamment :

• • Âge/date de création du compte client (crucial pour la rétention SaaS)
  • Historique des achats précédents (un facteur de la fréquence des transactions)
  • Spécifications de l'appareil (ID de l'appareil, navigateur, résolution d'écran)

Vous devez créer un plan et l'intégrer à votre calendrier en termes de 3DS performance. Le défi consiste à réduire les frictions pour le client et à se conformer aux règles, c'est pourquoi il est nécessaire de prendre en compte le risque et la nécessité d'effectuer chaque transaction.

Cette étape vise à faciliter le “Flux Sans Friction” pour de nombreuses transactions valides et initier le “Flux de Défi” lorsque cela est requis pour les titulaires de carte EEE ou en cas de risque élevé. Un tableau d'analyse des risques ci-dessous peut contribuer à la conformité aux règles applicables et peut avoir un impact sur les taux de conversion.

Pour chaque transaction, avant d'initier le paiement, vous devez effectuer une évaluation des risques à l'aide de ce tableau :

la Flux Sans Friction en 3DS 2 concerne les taux de conversion grâce à la suppression possible de l'authentification pour les clients reconnus. Pour les entreprises SaaS, le système doit être configuré pour identifier correctement les paiements de renouvellement et ainsi bénéficier de l'exemption de Paiement Récurrent, un élément clé de la rétention des revenus. Vous devez également intégrer votre processus de paiement avec le moteur de risque de votre partenaire de paiement afin qu'il soit capable de prendre des décisions en temps réel, ce qui permet la réalisation d'un flux sans friction lorsque le score de risque est faible. Ce taux d'approbation élevé pour les transactions à faible risque aide à gérer le volume important de microtransactions typiques des SaaS et jeux vidéo.

• Signalement des abonnements (Modèle SaaS) : Pour les paiements récurrents SaaS facturation :
  • Signaler le premier paiement comme nécessitant 3DS pour la mise en place du cadre des identifiants enregistrés.
  • Signaler tous les renouvellements ultérieurs à montant fixe comme un “Paiement Récurrent” pour demander l'exemption SCA.

• Intégration du moteur de risque : Prenez le temps de configurer votre compte MoR auprès de votre prestataire de services de paiement afin que son moteur de risque puisse prendre des décisions en temps réel. Le moteur devrait automatiquement demander le parcours sans friction lorsque le score de risque est faible.

Dans les cas où une application mobile est utilisée (ce qui est le cas dans les SaaS et les jeux vidéo), la procédure d'authentification est cruciale, et un processus de paiement fluide impacte directement la conversion. Pour le sécuriser, vous devez utiliser les SDK mobiles dédiés de votre partenaire de paiement pour le processus 3DS, en gardant le client dans votre application pendant la vérification. Cela peut réduire la probabilité que le client soit redirigé vers un navigateur externe, ce qui est parfois associé à l'abandon de panier.

De plus, la prise en charge de l'authentification biométrique (Face ID, empreinte digitale) via le 3DS 2 protocole peut offrir une méthode de confirmation d'identité relativement rapide et serait courante chez les utilisateurs mobiles.

1. Intégration du SDK In-App : Utilisez les SDK mobiles dédiés (iOS/Android) de votre partenaire de paiement pour gérer le flux 3DS. Ainsi, le client restera dans votre application pendant le processus de vérification.
2. Éviter les redirections : Le flux devrait afficher une invite d'authentification qui contient les informations à authentifier et les identifiants pour le faire. Éviter la redirection du navigateur pour la connexion pendant le processus peut influencer les taux d'achèvement d'achat. 
3. Prise en charge de la biométrie : Le protocole 3DS 2 permet l'authentification biométrique (Face ID, empreinte digitale). Votre partenaire de traitement des paiements doit activer cette fonctionnalité afin que les clients puissent s'authentifier rapidement si leur banque le prend en charge.

Conseils de dépannage

• Augmentation de l'abandon de panier : Pour éviter l'abandon de panier, vous pouvez utiliser 3DS 2 pour permettre un déroulement fluide des transactions ne présentant aucun défi ou un risque trop élevé, en affichant l'invite d'authentification uniquement lorsque cela est nécessaire.
• Gestion des problèmes d'affichage sur mobile : Pour optimiser le traitement des achats in-app sur mobile, utilisez les kits de développement logiciel mobiles dédiés de votre fournisseur de paiement afin d'intégrer le processus de défi dans la webview de l'application, évitant ainsi d'ouvrir une page qui prolongerait l'inertie de la session.
• Renouvellements échouant en raison de la SCA : Tenez compte du cas où le système de facturation n'inclut pas la fonction de suivi des paiements récurrents et d'identifier des moyens alternatifs pour gérer de tels cas. Si la première tentative de paiement est également manquée, le client pourrait nécessiter une autorisation par e-mail pour procéder à la transaction.