Authentification forte du client dans la boutique en ligne : quand elle s'applique et que faire

Authentification forte du client : ce qui se cache derrière

L'authentification forte du client (Strong Customer Authentication, SCA) découle de la directive européenne sur les services de paiement DSP2 (directive UE 2015/2366) et est entrée en vigueur le 14 septembre 2019. Elle a modifié l'authentification des paiements en ligne pour les clientes et clients européens.

Les normes techniques de réglementation (RTS) de la DSP2 précisent les exigences minimales. Outre la SCA, elles incluent l'exigence de « normes ouvertes de communication communes et sécurisées » avec des spécifications précises pour les interfaces documentées, les environnements de test (sandbox) ainsi que les statistiques de surveillance et de disponibilité. Ces règles régissent l'accès des prestataires de services tiers accrédités (AISP, PISP, CBPII).

Les paiements par carte se déroulaient traditionnellement en deux étapes : l'autorisation – où la banque ou l'émetteur de la carte approuve le paiement – et la capture, lors de laquelle la carte est débitée. Avec la SCA, une étape supplémentaire et obligatoire s'ajoute avant l'autorisation et la capture : l'authentification.

La cliente ou le client répond à une demande de la banque et fournit des informations supplémentaires. Trois options sont possibles : la connaissance, comme un mot de passe ; la possession, comme un téléphone mobile ; la biométrie, comme une empreinte digitale. Cette étape protège la clientèle grâce à la prévention de la fraude.

La SCA exige au moins deux de ces trois éléments, soit une authentification à deux facteurs. Les deux facteurs doivent être indépendants l'un de l'autre et provenir de catégories différentes. Un mot de passe seul ne suffit plus.

La SCA s'applique aux paiements initiés par le payeur, à l'accès en ligne aux comptes de paiement et aux ventes à distance présentant un risque de fraude. Elle a été introduite par la directive DSP2 et précisée par les normes techniques de réglementation (RTS) de l'Autorité bancaire européenne (EBA).

Quand la SCA s'applique à votre propre boutique

Quatre critères déterminent si vous devez vous pencher sur l'authentification forte du client. Le sujet est pertinent si le siège de l'entreprise se trouve dans l'Espace économique européen (EEE) ou si des paiements sont effectués pour des comptes liés au sein de l'EEE, si des clientes et clients se trouvent dans l'EEE ou si les cartes de crédit et/ou de débit sont acceptées.

Si l'une de ces affirmations est vraie, le sujet est pertinent pour votre propre boutique. Important pour la planification : la SCA n'est pas obligatoire pour chaque transaction en ligne individuelle. L'obligation s'applique au cas par cas, selon la transaction.

Pour les paiements en ligne par carte, l'authentification s'effectue via 3-D Secure 2.0. La clientèle reçoit une notification push sur son smartphone (possession) et confirme le paiement par reconnaissance faciale (inhérence).

Les paramètres concrets ne sont pas effectués dans la boutique, mais directement auprès du prestataire de services de paiement dans le compte correspondant. Les commerçantes et commerçants doivent concevoir le processus de paiement (checkout) de manière à ce qu'une étape d'authentification supplémentaire soit toujours possible – même si elle n'apparaît pas à chaque achat.

Quatre critères : l'authentification forte du client est-elle pertinente pour ma boutique ?

Exceptions – et pourquoi elles n'offrent aucune sécurité garantie

Il existe des exceptions à la SCA pour les achats récurrents et pour les paiements inférieurs à 30 euros. L'authentification peut également être omise pour les transactions à faible risque. Le risque est évalué en fonction du volume et du taux de fraude associé au prestataire de paiement ou à la banque.

Plus précisément, il s'agit de : transactions récurrentes de même montant, paiements de petits montants inférieurs à 30 euros avec un plafond cumulatif, bénéficiaires de confiance (liste blanche ou whitelisting) ainsi que transactions à faible risque sur la base d'une analyse des risques en temps réel (TRA).

Ces exceptions ne constituent pas une garantie. Les banques ne sont pas tenues de les approuver et peuvent tout de même exiger une authentification de la cliente ou du client. Les prestataires de services de paiement peuvent renforcer les paramètres de vérification selon leurs propres critères ; ni la boutique ni le commerçant ou la commerçante ne peuvent influencer cela.

En termes de planification : celui qui compte sur une exception doit toujours prévoir l'étape d'authentification dans le processus de paiement. L'exception réduit la probabilité d'abandon, mais ne l'élimine pas.

Exceptions à la SCA – et leurs limites

Perspective suisse : pas d'obligation DSP2, mais des conséquences tangibles

La directive DSP2 s'applique aux États membres de l'UE et est pertinente pour l'EEE. La Suisse ne l'a pas reprise : ici, il n'y a toujours pas d'obligation légale générale d'ouverture des API. Le Conseil fédéral mise sur une approche dirigée par le marché et observe l'évolution de près.

Néanmoins, les commerçants suisses ne restent pas à l'écart. Ceux qui ont une clientèle dans l'EEE devraient se pencher sur la SCA, car la banque émettrice ou le prestataire de services de paiement l'impose selon ses propres règles.

La liste des critères – siège dans l'EEE, paiements pour des comptes liés dans l'EEE, clientèle dans l'EEE, acceptation des cartes de crédit et de débit – le montre : avoir une clientèle dans l'EEE suffit déjà pour devoir se pencher sur le sujet.

La standardisation en Suisse s'effectue de bas en haut via des initiatives sectorielles plutôt que par une obligation légale d'ouverture. SFTI « Common API » élabore des spécifications pour les API bancaires et d'assurance. SIX permet, avec bLink, un raccordement sécurisé et standardisé entre les banques et les prestataires tiers, par exemple pour l'information sur les comptes ou la soumission de paiements, permettant ainsi de mettre à l'échelle les cas d'usage du multibanking. Un standard API uniforme à l'échelle de l'UE n'est pas non plus prescrit par la DSP2.

UE/EEE et Suisse en comparaison : réglementation, interfaces, application

Ce que les commerçants peuvent faire concrètement

La première étape consiste à clarifier la situation avec votre propre prestataire de services de paiement : dans quelles situations une authentification renforcée est-elle demandée ? La réponse varie selon le prestataire, le réseau de cartes et le profil de risque, et ne peut pas être déterminée depuis la boutique.

Deuxièmement, les paramètres du compte chez le prestataire de services de paiement doivent être examinés. Ils sont effectués directement auprès du prestataire de services de paiement dans le compte correspondant – pas dans le système de boutique. Comme le prestataire peut renforcer la vérification selon ses propres critères, il vaut la peine de mettre régulièrement à jour les paramètres.

Troisièmement, les clientes et clients doivent être préparés à cette étape supplémentaire. Ils sont invités par leur banque à autoriser le paiement et ont besoin pour cela d'accéder à leur téléphone mobile ou à l'application bancaire.

Concrètement, cela signifie pour le processus de paiement : la boutique intègre 3-D Secure 2.0. La clientèle confirme le paiement via une notification push sur le smartphone (possession) et par reconnaissance faciale (inhérence). Les authentifications client proposées par le prestataire de services de paiement sont disponibles pour tous les systèmes de paiement.

Des abandons surviennent lors du processus de paiement – c'est pourquoi il faut surveiller les points d'abandon. S'il s'avère que de nombreux achats s'arrêtent précisément à l'étape d'authentification, c'est un sujet à discuter avec le prestataire de services de paiement, pas une question de design dans la boutique.

Pour les abonnements et les achats récurrents, il faut également clarifier comment ces paiements sont gérés chez le prestataire, afin que l'exception pour les achats récurrents puisse effectivement s'appliquer.

En six étapes vers un processus de paiement compatible avec la SCA

Au-delà de la SCA : garder un œil sur les interfaces

Les interfaces de paiement et d'open banking augmentent la vitesse d'innovation, mais élargissent aussi la surface d'attaque potentielle. En pratique, ce sont surtout les autorisations non sécurisées, les droits excessifs, la journalisation et la surveillance insuffisantes ainsi que les configurations non sécurisées des transports et des protocoles qui entraînent des fuites de données et des abus. Les OWASP API Security Top 10 actuels classent toujours les faiblesses d'autorisation et de contrôle d'accès en tête de liste.

Comme mesures prioritaires, on considère des concepts d'autorisation et d'authentification propres ainsi que la protection contre l'épuisement des ressources. S'y ajoutent des droits minimaux pour les accès tiers et une surveillance efficace avec des indicateurs clés.

Pour les instituts, sur la base des directives de la FINMA, comptent une architecture robuste de sécurité des API, une gouvernance propre, la gestion des risques tiers et des preuves vérifiables. Les instituts concernés doivent permettre des accès tiers traçables et sécurisés, y compris la transparence sur la disponibilité et les performances.

Pour les commerçants qui intègrent des paiements open banking ou des informations sur les comptes, cela signifie : les mêmes questions – qui a le droit de faire quoi, comment est-ce journalisé, comment est-ce surveillé – font partie de la sélection et de l'exploitation du prestataire.