Sécurisez
les paiements clientsFluidifiez
votre parcoursRéduisez
les frais de mise en conformitéUn cadre réglementaire
entièrement maîtrisé
Afin de protéger les informations bancaires et de réduire la fraude, la DSP2 a introduit des exigences en matière d’identification client.
Conformément au protocole de sécurisation des paiements en ligne, chaque transaction doit être soumise à une authentification forte (Strong Customer Authentication) afin de certifier qu’elle est bien réalisée par le porteur de carte.
Le payeur doit renseigner au minimum 2 des 3 facteurs d’authentification, définis par l’Autorité Bancaire Européenne :
Mot de passe, code secret, question secrète...
Téléphone portable, appareil connecté, token, badge...
Empreinte digitale, reconnaissance faciale ou vocale...
Fluidifier les transactions carte
en évaluant le risque
L’authentification forte est réalisée sur décision de la banque émettrice. Cette dernière se base sur un score de risque, calculé grâce à l’exploitation de données complémentaires, qui replacent le paiement dans son contexte.
Cette opération est réalisée en tâche de fond et ne perturbe pas le processus de paiement.
Si les conditions de paiement du porteur sont considérées comme habituelles, il pourra bénéficier d’une authentification frictionless, sans redirection vers l’application bancaire. Dans le cas inverse, une authentification forte sera nécessaire.
L’analyse contextuelle s’effectue grâce au partage de près de 150 données en provenance :
Du téléphone (dans le cas d'un paiement mobile)
- Le type de plateforme utilisée avec l’adresse IP du porteur
- Le nom et le modèle du périphérique, la résolution de l’écran
- Le système d’exploitation ainsi que la version d’OS est également inclus
- Le fuseau horaire et la position de l’appareil
Du navigateur (dans le cas d’un paiement depuis un browser)
- Accept Headers (en-têtes) : indiquent les types de contenu (MIME) que le navigateur est capable de comprendre.
- Adresse IP : l’adresse IP du PC sur lequel le navigateur est en cours d’exécution.
- Java Enabled : indique si le navigateur est activé Java
- Language : indique la langue utilisée par le navigateur du détenteur de la carte.
- Screen Colour Depth : indique la profondeur de la palette de couleurs utilisée pour l’affichage des images à l’écran.
- Screen Height : indique la hauteur totale de l’écran du détenteur en pixels
- Screen Width : indique la largeur totale de l’écran du détenteur de carte en pixels.
- Time Zone : indique la différence de temps entre l’UTC et l’heure locale du détenteur de la carte.
- User-Agent : indique le contenu exact de l’en-tête HTTP User-agent.
Du risque marchand
- Le « compte client » : les données du client détenues par le commerçant dans le cadre d’un compte enregistré (âge du compte, dates de toute modification apportée au compte, adresse de livraison et fréquence des transactions, y compris les transactions réussies et abandonnées…).
- Les achats : habitudes d’achat du client, si les produits ou les services achetés ont été commandés auparavant (indicateur de nouvelle commande d’articles), lieu où la commande est expédiée (indicateur d’expédition) et si la commande est achetée en amont (indicateur de commande pré-achat).
- L’authentification des transactions passées : éventuelles frictions durant les transactions (demande d’authentification supplémentaire, date et heure des tentatives précédentes).
L’authentification du compte marchand du titulaire de carte : login client sur le compte marchand, support de l’opération (navigateur ou application mobile). L’information optionnelle peut inclure des justificatifs concernant l’émetteur et l’authentification de tiers, (Google, Apple). Si l’information existante n’est pas disponible par le détenteur de la carte, les données sont paramétrées en Guest (invité).
Quelques cas d'exemption
au protocole 3DS 2.0
Sous certaines conditions, la banque du payeur peut lever l’obligation d’authentification systématique
Notre protocole d'authentification forte
En quoi le 3D Secure 2.0 diffère-t-il de sa version précédente ?
Évolution du protocole sécurisé 3D Secure, la version 2.0 offre de nouveaux avantages :
- Data oriented : Il utilise une approche plus intelligente, en recueillant davantage de données sur la transaction pour évaluer le niveau de risque et déterminer si une authentification est nécessaire.
- Expérience utilisateur améliorée : Afin de réduire les frictions et ne pas endommager l’expérience utilisateur, le 3D Secure 2.0 incorpore l’authentification forte de manière plus fluide dans le processus de paiement.
- Sécurité renforcée : Avec des méthodes d’authentification et d’analyse plus avancées, le 3D Secure 2.0 permet l’identification plus précise des transactions frauduleuses, tout en réduisant les faux positifs.
- Multi-appareils : Contrairement à sa première version, le 3D Secure 2.0 est maintenant pris en charge sur une large variété d’appareils, offrant une authentification plus fluide sur tous les supports, y compris les smartphones et les tablettes.
Le paiement sera-t-il toujours soumis à une authentification forte ?
Dans la pratique, celles-ci se basent sur l’analyse certains facteurs, afin de calculer le score de risque de la transaction. Si les conditions de paiement sont considérées comme habituelles et sans risque, le porteur de carte pourra bénéficier d’une authentification frictionless, sans redirection vers l’application de sa banque.
Quelle régulation encadre le protocole 3D Secure 2.0 ?
En 2019, dans le cadre de la Directive des Services de Paiement n°2 (DSP2), le Parlement Européen a rendu obligatoire l’authentification forte (Strong Customer Authentication – SCA) afin de limiter les risques de fraude.