L’authentification forte (SCA) est devenue un pilier de la sécurité des transactions en ligne en Europe. Pour les développeurs, architectes et DSI de plateformes SaaS ou e-commerce, comprendre ses exigences, ses exemptions et ses évolutions réglementaires est crucial pour garantir la conformité et optimiser les taux de conversion. Cet article détaille les spécificités du SCA en 2026, l’impact du 3D Secure 2, les changements introduits par le PSR, et l’arrivée prochaine de l’EUDI Wallet, en fournissant des clés d’intégration concrètes.

Ce que le SCA impose réellement en 2026 : PSD2, RTS et application effective

La Directive sur les services de paiement 2 (PSD2), via son article 97, a introduit l’exigence d’une authentification forte du client (SCA) pour sécuriser les paiements électroniques et les accès aux comptes en ligne. Concrètement, un prestataire de services de paiement (PSP) doit appliquer le SCA lorsque le payeur accède en ligne à son compte de paiement, initie un paiement électronique, ou effectue une action à distance présentant un risque de fraude.

Le cadre technique est défini par le Règlement Délégué (UE) 2018/389 (RTS SCA), applicable depuis le 14 septembre 2019 et modifié par le règlement (UE) 2022/2360. Le SCA exige l’utilisation d’au moins deux facteurs d’authentification, choisis parmi trois catégories :

• Connaissance : quelque chose que seul l’utilisateur connaît (mot de passe, code PIN).
• Possession : quelque chose que seul l’utilisateur possède (téléphone, carte bancaire, token matériel).
• Inhérence : quelque chose que l’utilisateur est (empreinte digitale, reconnaissance faciale, vocale).

Ces facteurs doivent être indépendants, c’est-à-dire que la compromission de l’un ne doit pas affaiblir la fiabilité des autres. Il est important de noter que si le RTS est applicable depuis 2019, son application généralisée, notamment pour le e-commerce par carte, a été progressive. En France, après une période de flexibilité de supervision, les banques ont pu commencer à rejeter les transactions non conformes à partir du 15 mai 2021, marquant la dernière étape d’une montée en charge progressive.

Les exemptions du RTS : seuils, analyse de risque (TRA) et transactions hors périmètre

Pour ne pas entraver l’expérience utilisateur, le RTS prévoit des exemptions au SCA, sous des conditions strictes. Les développeurs doivent comprendre ces mécanismes pour les implémenter correctement et minimiser la friction tout en respectant la conformité.

Exemptions de faible montant et récurrentes

• Faible montant à distance (art. 16) : Les paiements de moins de 30 € peuvent être exemptés, à condition que le cumul des opérations exemptées depuis le dernier SCA ne dépasse pas 100 €, ou que le nombre d’opérations consécutives exemptées ne dépasse pas cinq.
• Sans contact en point de vente (art. 11) : Similaire, pour les paiements de moins de 50 €, avec un cumul maximum de 150 € ou cinq opérations consécutives.
• Bénéficiaires de confiance (art. 13) : Un SCA est requis pour créer ou modifier une liste de bénéficiaires de confiance. Les paiements ultérieurs vers ces bénéficiaires peuvent être exemptés.
• Paiements récurrents (art. 14) : Si un payeur initie une série de paiements de même montant et vers le même bénéficiaire, le SCA n’est requis que pour la première opération ou lors de la modification du mandat. Les opérations suivantes sont exemptées.
• D’autres exemptions existent pour le transport, le stationnement (art. 12), ou les processus spécifiques aux entreprises (art. 17). L’accès aux informations de compte (art. 10) est exempté après le premier SCA, mais un renouvellement est requis tous les 180 jours.

Analyse de risque de transaction (TRA)

L’exemption la plus complexe est l’Analyse de Risque de Transaction (TRA, art. 18). Elle permet aux prestataires de services de paiement de ne pas appliquer le SCA si le risque de fraude est jugé faible. Trois conditions cumulatives doivent être remplies :

1. Le taux de fraude du PSP (calculé sur 90 jours glissants pour les paiements à distance, incluant SCA et exemptés) est inférieur ou égal à un taux de référence prédéfini.
2. Le montant de la transaction ne dépasse pas un seuil d’exemption spécifique (ETV).
3. L’analyse de risque en temps réel ne détecte aucun signal de fraude (comportement anormal, informations inhabituelles sur l’appareil, localisation suspecte, etc.).

Les seuils d’exemption (ETV) et les taux de fraude maximum associés sont les suivants pour les paiements par carte à distance :

• 500 € : Taux de fraude max 0,01 %
• 250 € : Taux de fraude max 0,06 %
• 100 € : Taux de fraude max 0,13 %

Si le taux de fraude du PSP dépasse le seuil, l’exemption TRA correspondante est perdue. Il est crucial de noter que l’émetteur conserve toujours la possibilité d’exiger le SCA, même si l’acquéreur demande une exemption.

Transactions hors périmètre SCA : les MIT

Il est essentiel de distinguer les exemptions des opérations qui sont tout simplement hors du champ d’application du SCA. C’est le cas des Transactions Initiées par le Commerçant (MIT), comme les prélèvements ou les paiements par carte récurrents non initiés par le payeur. Elles ne nécessitent pas de SCA pour chaque transaction, mais la mise en place du mandat initial par le payeur doit, elle, être soumise au SCA si elle est réalisée à distance. Un exemple typique est le paiement d’abonnement où le client donne une fois son accord et les prélèvements suivants sont automatiques. Cette distinction est fondamentale pour l’intégration de solutions de paiement pour marketplace ou abonnements.

3D Secure 2 en pratique : frictionless, challenge et soft decline

EMV 3-D Secure (3DS2) est le protocole de référence pour l’application du SCA aux paiements par carte en ligne. Il vise à réduire la friction pour l’utilisateur tout en augmentant la sécurité.

Fonctionnement et acteurs

Le 3DS2 implique plusieurs acteurs : le commerçant ou son PSP (agissant comme 3DS Requestor via un 3DS Server), le Directory Server du schéma de carte (Visa, Mastercard), et l’Access Control Server (ACS) de la banque émettrice de la carte. Lors d’une transaction, un grand nombre de données contextuelles (appareil, comportement, historique) est transmis à l’émetteur.

• Flux frictionless : Si l’émetteur juge le risque de fraude faible, l’authentification se fait en arrière-plan sans interaction directe avec le client.
• Flux challenge : Si le risque est jugé plus élevé, l’émetteur demande une authentification forte au client (via son application bancaire, biométrie, code SMS, etc.).

L’utilisation de 3DS2 est fortement recommandée pour bénéficier des exemptions SCA. Les commerçants qui ne l’utilisent pas doivent gérer les refus dits « soft decline » des émetteurs.

Évolution du protocole

Le 3DS1 a été progressivement retiré, avec une fin d’acceptation par Visa et Mastercard le 15 octobre 2022. La version 3DS 2.2 gère notamment les soft declines et les demandes d’exemption, tandis que la version 2.3.1 (septembre 2022) a introduit des améliorations comme SPC (Secure Payment Confirmation) et l’authentification out-of-band.

Un avantage majeur du 3DS2 est le transfert de responsabilité en cas de fraude. Une transaction pleinement authentifiée via 3DS2 déplace généralement la responsabilité fraude vers l’émetteur. Cependant, si une exemption est demandée par l’acquéreur et que l’émetteur ne passe pas en challenge, la responsabilité peut rester côté acquéreur.

Le soft decline : la banque exige le SCA après coup

Le « soft decline » est un refus d’autorisation par lequel l’émetteur indique que le SCA est requis pour que le paiement puisse être traité. Pour les développeurs, cela signifie qu’un premier refus d’autorisation (par exemple, avec le code 65 chez Mastercard) ne doit pas être traité comme un échec définitif. Il faut relancer le paiement en incluant une authentification EMV 3DS (avec un indicateur de défi « SCA exigé ») puis renvoyer la transaction pour une nouvelle autorisation. Ignorer cette étape peut entraîner des pénalités.

Dynamic linking et pièges d’intégration côté développeur

Le dynamic linking est une exigence clé du SCA pour les paiements électroniques à distance, stipulée à l’article 5 du RTS 2018/389. Il impose que le code d’authentification généré soit spécifiquement lié au montant et au bénéficiaire de l’opération. Le payeur doit pouvoir visualiser clairement ces informations avant de valider. Toute modification, même minime, du montant ou du bénéficiaire après l’authentification rend le code invalide et nécessite une nouvelle authentification.

Pour les développeurs et architectes, cette exigence a des implications directes sur la conception des parcours de paiement. Il est impératif de s’assurer qu’aucune modification du panier (ajout de frais, application d’une remise, changement de devise) n’intervienne entre l’étape d’authentification et la finalisation du paiement sans déclencher un nouveau SCA.

Pièges courants en intégration SCA

L’intégration du SCA peut se heurter à plusieurs difficultés, souvent liées à une mauvaise gestion des flux asynchrones ou des cas d’erreur :

• Soft decline non géré : Ne pas relancer une transaction avec 3DS2 après un refus indiquant que le SCA est requis.
• Mandat d’abonnement non authentifié : Omettre le SCA pour la première échéance d’un abonnement, invalidant les paiements récurrents ultérieurs (MIT).
• Rupture du dynamic linking : Modifier le montant ou le bénéficiaire après que le client a validé l’authentification.
• Gestion des abandons : Ne pas prévoir d’états « en attente » ou de mécanismes de reprise pour les challenges 3DS abandonnés ou expirés.
• Perte de webhooks : Après une redirection 3DS, le webhook de confirmation du PSP peut être perdu. Une stratégie de réconciliation par polling du statut de la transaction et l’utilisation de clés d’idempotence sont essentielles. Pour approfondir ces défis, consultez notre article sur l’intégration de solutions de paiement bancaire.

SCA sous le PSR : ce qui change et le calendrier réel

Le paysage réglementaire des paiements évolue avec l’arrivée du Règlement sur les Services de Paiement (PSR), qui remplacera la PSD2 pour de nombreux aspects. Le SCA, actuellement régi par l’article 97 de la PSD2 et les RTS, sera déplacé vers l’article 85 du PSR.

Une nouveauté notable est l’article 85(12) du PSR, qui inscrit explicitement dans la loi l’exigence que les éléments d’authentification proviennent de catégories différentes (connaissance, possession, inhérence), un critère qui était jusqu’à présent issu d’un avis de l’Autorité Bancaire Européenne (ABE).

L’article 89 du PSR confie à l’ABE la mission d’élaborer de nouveaux RTS pour le SCA, les exemptions, la protection des identifiants et la surveillance des transactions. Ces nouveaux RTS devront être révisés dans un délai de 12 mois après l’entrée en vigueur du PSR, en tenant compte des innovations technologiques, du règlement DORA (Digital Operational Resilience Act) et de l’intégration des European Digital Identity Wallets.

Le calendrier d’application est crucial : l’article 85 du PSR s’appliquera 21 mois après l’entrée en vigueur du règlement. Au vu de l’accord politique provisoire de novembre 2025 et du vote plénier indicatif du Parlement européen le 14 décembre 2026, une publication au Journal Officiel de l’Union Européenne début 2027 est probable, menant à une application effective du PSR vers fin 2028. Il est donc essentiel de commencer à anticiper ces changements dès 2026. Pour une analyse plus approfondie des impacts du PSR sur les plateformes, notre article sur PSD3 et PSR : Cinq changements majeurs à anticiper dans une plateforme de paiement en 2026 fournit des éclaircissements complémentaires.

Par ailleurs, la Vérification du Bénéficiaire (VoP) pour les virements instantanés en euros est déjà une obligation depuis le 9 octobre 2025 en application du Règlement IPR (UE) 2024/886, imposant de nouveaux contrôles avant validation des virements.

EUDI Wallet et SCA : acceptation fin 2027 et spécification TS12

L’European Digital Identity Wallet (EUDI Wallet), prévu par le règlement eIDAS modifié par 2024/1183, représente une évolution majeure pour l’authentification en ligne. Chaque État membre doit proposer au moins un Wallet certifié au plus tard le 24 décembre 2026. Bien que son usage soit volontaire pour les citoyens, son acceptation deviendra obligatoire pour de nombreux acteurs.

Selon l’article 5f(2) du règlement eIDAS modifié, les parties utilisatrices privées qui sont tenues par le droit de l’Union ou national, ou par contrat, d’utiliser une authentification forte pour l’identification en ligne, devront accepter le Wallet sur demande volontaire de l’utilisateur. Cela inclut des secteurs clés comme la banque, les services financiers, le transport et l’énergie. Cette obligation d’acceptation entrera en vigueur au plus tard fin 2027 (36 mois après l’entrée en vigueur des actes d’exécution).

Il est crucial de comprendre que l’EUDI Wallet ne réécrit pas la PSD2 ni le PSR. Il s’ajoute comme un moyen d’authentification supplémentaire et interopérable que certains acteurs devront accepter. La manière dont un paiement est approuvé et lié (via dynamic linking) reste régie par les règles SCA existantes. Les micro et petites entreprises sont exemptées de cette obligation d’acceptation.

La spécification technique EUDI TS12 est en cours d’élaboration pour définir le SCA via le Wallet. Elle prévoit une attestation SCA (SD-JWT VC) émise par le PSP, liée à la transaction (respectant le dynamic linking) et protégée par une preuve de possession (KB-JWT). Le Wallet pourra porter les trois catégories de facteurs SCA. Le contenu détaillé de cette attestation sera défini par un « rulebook SCA » de l’ABE, encore en évolution. L’intégration de cette nouvelle brique nécessitera une attention particulière à la conformité eIDAS, comme nous l’expliquons dans notre guide sur l’intégration de la signature électronique.

Que préparer avant fin 2026

L’année 2026 est une période charnière pour les développeurs et architectes en charge des plateformes de paiement. Anticiper les évolutions est la clé pour maintenir la conformité et une expérience utilisateur fluide :

• Audit de conformité SCA actuel : S’assurer que les implémentations 3DS2 et les mécanismes d’exemption sont à jour et correctement gérés, notamment les soft declines.
• Préparation au PSR : Commencer à évaluer l’impact du futur article 85 du PSR sur vos architectures d’authentification et les nouveaux RTS de l’ABE. Les choix techniques faits aujourd’hui auront des répercussions sur les coûts d’adaptation futurs.
• Intégration EUDI Wallet : Identifier si votre entité sera soumise à l’obligation d’accepter l’EUDI Wallet fin 2027 et commencer à planifier les évolutions nécessaires, notamment pour la gestion des identités et l’authentification.
• Robustesse des intégrations : Renforcer les mécanismes de réconciliation des paiements, la gestion des webhooks, et la résilience face aux échecs d’authentification, en particulier pour les paiements récurrents et les transactions à fort enjeu.

La complexité croissante des réglementations de paiement et d’identité numérique exige une expertise technique pointue pour transformer ces contraintes en opportunités. Nuvelia accompagne les éditeurs SaaS et les entreprises dans l’audit de conformité PSD2 et l’intégration des solutions d’open banking et de SCA.

À lire ensuite

Trois ressources du même domaine d’expertise.

PSD2 & SCA

Vérification du Bénéficiaire et Virement Instantané : Les Pièges d’Intégration PSP en 2026

10 min de lecture · Nabil Hsissi · Expert paiement

PSD2 & SCA

Vérification du Bénéficiaire et Virement Instantané : Les Pièges d’Intégration PSP en 2026

11 min de lecture · Nabil Hsissi · Expert paiement

PSD2 & SCA

PSD3 et PSR : Cinq changements majeurs à anticiper dans une plateforme de paiement en 2026

11 min de lecture · ♡ 48 · Nabil Hsissi · Expert paiement