PSD2 et Authentification Forte (SCA) : Guide Complet pour les Développeurs en 2026
Le paysage des paiements numériques est en constante évolution, et en 2026, la Directive sur les Services de Paiement (PSD2) et son exigence d’Authentification Forte du Client (SCA) restent au cœur des préoccupations des développeurs et architectes. Cet article décrypte les obligations techniques, les exemptions via 3D Secure 2 (3DS2), les avancées comme FIDO2, et les récents bouleversements réglementaires tels que le Règlement sur les Paiements Instantanés (IPR) et la transition vers PSD3/PSR, afin de vous guider vers des intégrations conformes et résilientes.
Comprendre la PSD2 et l’Authentification Forte (SCA) en 2026
La Directive sur les Services de Paiement (PSD2), en vigueur depuis 2018, vise à renforcer la sécurité des transactions et à stimuler l’innovation dans le secteur financier européen. Au cœur de cette directive se trouve l’exigence d’Authentification Forte du Client (SCA), devenue obligatoire pour la plupart des paiements électroniques depuis le 14 septembre 2019 via les Normes Techniques de Réglementation (RTS SCA).
L’authentification forte repose sur l’utilisation d’au moins deux des trois facteurs indépendants suivants :
- Connaissance : quelque chose que seul l’utilisateur connaît (ex: mot de passe, code PIN).
- Possession : quelque chose que seul l’utilisateur possède (ex: smartphone, token physique).
- Inhérence : quelque chose que l’utilisateur est (ex: empreinte digitale, reconnaissance faciale).
Ces facteurs doivent être indépendants, de sorte que la compromission de l’un n’affecte pas la fiabilité des autres. La SCA s’applique aux initiations de paiement électronique et aux accès en ligne aux informations de compte.
Les exemptions à la SCA : optimiser l’expérience utilisateur
Si la SCA est une obligation, la PSD2 et les RTS prévoient des exemptions pour réduire la friction utilisateur tout en maintenant un niveau de sécurité adéquat. Les plus courantes incluent :
- Transactions à faible montant : Généralement sous 30 €, avec des limites cumulatives.
- Transactions répétitives : Après une première SCA, les paiements récurrents du même montant au même bénéficiaire peuvent être exemptés.
- Transactions initiées par le commerçant (MIT) : Pour les abonnements ou paiements différés, après une SCA initiale.
- Analyse des risques de transaction (TRA – Transaction Risk Analysis) : C’est l’exemption la plus technique et la plus utilisée. Elle permet aux prestataires de services de paiement (PSP) et aux émetteurs de cartes d’évaluer le risque d’une transaction en temps réel. Si le risque est jugé faible, la SCA peut être omise. C’est ici que le protocole 3D Secure 2 (3DS2) joue un rôle central.
Les évolutions réglementaires majeures : IPR 2024/886 et PSD3/PSR
L’année 2026 est une période charnière, marquée par la pleine application du Règlement sur les Paiements Instantanés et l’anticipation des textes finaux de PSD3/PSR. Ces évolutions redéfinissent les standards d’intégration pour les services de paiement.
Le Règlement sur les Paiements Instantanés (IPR) 2024/886 : Nouvelles obligations pour 2026
Le Règlement (UE) 2024/886, entré en vigueur le 8 avril 2024, est un jalon majeur pour les virements en euros. Il rend les paiements instantanés (SCT Inst) accessibles et abordables pour tous les citoyens et entreprises de la zone euro.
Voici les échéances clés à maîtriser pour les PSP et leurs partenaires intégrateurs :
- 9 janvier 2025 : Tous les Prestataires de Services de Paiement (PSP) de la zone euro doivent être en mesure de recevoir des virements SEPA Instantanés (SCT Inst) 24h/24, 7j/7, sans surcoût additionnel par rapport à un virement SEPA classique. Le plafond du schéma EPC de 100 000 € a été supprimé au niveau européen, bien que chaque banque puisse maintenir son propre plafond applicatif.
- 9 octobre 2025 : Double bascule critique. L’émission de virements SCT Inst devient obligatoire pour tout PSP de la zone euro. Parallèlement, la Vérification du Bénéficiaire (VoP – Verification of Payee) entre en vigueur. Les frais pour les virements instantanés ne peuvent excéder ceux des virements SEPA classiques équivalents (article 5 quater), impliquant une gratuité de fait pour de nombreux utilisateurs.
- 15 novembre 2026 : Tous les paiements SEPA devront obligatoirement utiliser des adresses structurées (ISO 20022). Les formats plus anciens seront rejetés, ce qui implique une migration significative pour les systèmes hérités.
Les exigences techniques sont strictes : un virement doit être traité en moins de 10 secondes, 24/7/365. Cela exclut les architectures batch traditionnelles et impose des contrôles de sanctions quotidiens, voire immédiats, plutôt que transaction par transaction. Pour les développeurs, la VoP implique l’intégration d’un appel API synchrone dans le tunnel de virement, affichant le résultat de concordance (match / close match / no match / vérification impossible) entre le nom du bénéficiaire et l’IBAN avant la confirmation du paiement. En cas de non-réalisation ou de mauvaise exécution de la VoP, un droit à remboursement est prévu sous certaines conditions, renforçant la lutte contre la fraude au RIB.
Pour approfondir les enjeux d’intégration des solutions de paiement et d’open banking, consultez notre guide sur l’intégration des services de paiement bancaire par Nuvelia.
PSD3 et PSR : Vers un cadre unifié et des API Open Banking renforcées
La réforme PSD3 (Directive sur les Services de Paiement 3) et PSR (Règlement sur les Services de Paiement) est la prochaine étape majeure. Après la proposition de la Commission en juin 2023 et un accord politique provisoire en novembre 2025, les textes finaux devraient être publiés au Journal Officiel de l’Union Européenne (JOUE) mi-2026, après une revue juridico-linguistique. L’application effective est anticipée pour mi/fin 2027-2028, avec une période de transition de 21 mois pour le PSR et une transposition de 18 mois pour la PSD3.
Le PSR introduit des règles de conduite directement applicables, renforçant la SCA, la lutte contre la fraude (notamment la fraude APP – Authorized Push Payment, avec une responsabilité étendue aux plateformes suite au trilogue), les remboursements, et la généralisation de la Confirmation of Payee (CoP), qui reprend la logique de la VoP. Il imposera également des exigences de performance accrues pour les API open banking, mettant fin aux dérogations pour les interfaces de repli et exigeant des tableaux de bord de consentement pour les clients.
La PSD3 se concentre sur l’agrément et la supervision, fusionnant les régimes de licence pour les établissements de paiement (PI) et les établissements de monnaie électronique (EMI) en un régime unique. Elle renforce les exigences de sauvegarde des fonds clients, notamment par une diversification obligatoire sur au moins deux établissements de crédit au-delà d’un certain seuil, et une logique T+1 pour la sécurisation des fonds entrants des EMI.
Parallèlement, le règlement FIDA (Financial Data Access), toujours en trilogue en 2026, vise à étendre la logique de l’open banking aux investissements, pensions, assurances et crédits, créant une nouvelle catégorie de prestataires : les FISP (Financial Information Service Provider). Son horizon d’application réaliste est 2029-2030.
L’année 2026 est donc une année de préparation intense. Les choix d’architecture actuels (microservices, gestion des consentements) doivent anticiper les futurs BTS/RTS de l’ABE qui détailleront l’implémentation des API, car les refontes ultérieures seront coûteuses. Pour une vue comparative des acteurs et de leurs API, notre analyse des solutions de paiement bancaire en France, incluant Wero, peut vous éclairer.
Implémentation technique de la SCA et gestion des défis
L’intégration de la SCA ne se limite pas à cocher une case réglementaire ; elle exige une compréhension approfondie des mécanismes techniques pour concilier sécurité et fluidité de l’expérience utilisateur.
3D Secure 2 (3DS2) et l’authentification forte frictionless
3DS2 est le protocole de référence pour l’implémentation de la SCA dans les paiements par carte. Contrairement à son prédécesseur (3DS1), 3DS2 est conçu pour être beaucoup plus transparent pour l’utilisateur.
Le mécanisme repose sur un échange enrichi de données entre le commerçant, l’émetteur de la carte (ASPSP) et le système 3DS (Directory Server). Lors d’une transaction, plus de 100 points de données (adresse IP, historique de transactions, type d’appareil, localisation, etc.) sont transmis. Sur cette base, l’émetteur évalue le risque :
- Flux « frictionless » : Si le risque est faible, l’authentification est validée sans aucune interaction de l’utilisateur. C’est l’objectif des exemptions basées sur l’analyse des risques (TRA).
- Flux « challenge » : Si le risque est jugé plus élevé, une authentification forte est requise (code SMS, biométrie via l’application bancaire).
Pour les développeurs, l’intégration de 3DS2 se fait généralement via les SDK (Software Development Kits) fournis par les PSP ou les fournisseurs de services 3DS. Ces SDK gèrent la complexité de l’échange de données côté client et la redirection éventuelle vers l’application bancaire pour le « challenge ». Une bonne intégration nécessite de :
- Utiliser la dernière version des SDK pour bénéficier des améliorations de performance et de sécurité.
- Transmettre le maximum de données contextuelles (informations sur l’appareil, l’adresse de livraison, etc.) pour augmenter les chances d’un flux « frictionless ».
- Gérer les différents statuts de réponse (authentification réussie, échec, exemption appliquée, etc.) et les scénarios de repli.
FIDO2 et l’avenir de l’authentification
FIDO2 est une suite de spécifications (WebAuthn, CTAP2) qui permet une authentification forte basée sur des clés cryptographiques, offrant une alternative robuste et résistante au phishing aux méthodes traditionnelles. Elle s’appuie sur des dispositifs d’authentification (biométrie intégrée, clés de sécurité USB) et est nativement supportée par les navigateurs web et les systèmes d’exploitation.
Ses avantages sont multiples :
- Sécurité renforcée : Les clés cryptographiques sont stockées localement et ne sont jamais transmises, rendant le phishing et les attaques par rejeu inefficaces.
- Expérience utilisateur améliorée : L’authentification par empreinte digitale ou reconnaissance faciale est plus rapide et moins intrusive qu’un code OTP.
- Standardisation : FIDO2 est un standard ouvert, favorisant l’interopérabilité.
Dans le contexte des paiements, FIDO2 pourrait devenir un moyen d’authentification forte privilégié, notamment avec l’émergence du EUDI Wallet (European Digital Identity Wallet). Ce portefeuille d’identité numérique européen, en cours de déploiement, pourra servir de moyen d’authentification forte pour confirmer des paiements, créant un pont entre l’identité numérique et le paiement. L’initiative Wero, solution de paiement souveraine européenne, prévoit d’ailleurs de converger avec l’EUDI Wallet pour simplifier l’onboarding et le KYC, comme nous l’expliquons dans notre article sur les enjeux de la signature électronique.
Gestion des consentements et des données client
La conformité à la PSD2 et au RGPD implique une gestion rigoureuse des données de paiement. La CNIL, en France, émet des recommandations claires concernant la conservation des données de carte bancaire :
- Interdiction de conserver le cryptogramme visuel (CVV/CVC) après la transaction.
- Le numéro de carte (PAN) peut être conservé pour la durée de la transaction, puis jusqu’à 13 mois (15 mois pour les débits différés) à des fins de preuve en cas de contestation. Au-delà, sa conservation n’est possible qu’avec un consentement explicite de l’utilisateur pour faciliter les paiements en un clic. C’est le rôle de la tokenisation chez les PSP, qui remplace le PAN par un jeton sécurisé, réduisant le périmètre de conformité PCI DSS pour le marchand.
- Il est impératif de ne jamais logguer un PAN en clair dans les logs applicatifs, les systèmes d’APM ou les tickets support. C’est une cause fréquente de non-conformité PCI découverte lors des audits.
De plus, la norme PCI DSS 4.0.1 a rendu obligatoires depuis le 31 mars 2025 plusieurs exigences « best practice » de la version 4.0. Cela inclut notamment l’inventaire et le contrôle des scripts de page de paiement, un point d’attention direct si vous intégrez des solutions de paiement via des iframes ou des composants avec des scripts tiers sur vos pages. Pour une analyse approfondie des API de paiement, notre comparatif Stripe vs Adyen vs Mollie fournit des éléments clés pour les développeurs SaaS.
Pièges courants et bonnes pratiques d’intégration
L’intégration des API de paiement et d’authentification est complexe. Au-delà de la conformité réglementaire, la robustesse technique est primordiale pour garantir la fiabilité des transactions et la confiance des utilisateurs.
Un des pièges les plus fréquents réside dans la perte de webhooks. Dans un système distribué, les notifications asynchrones de paiement peuvent échouer. Une architecture résiliente doit inclure un mécanisme de réconciliation par polling régulier des statuts de transaction chez le PSP, afin de rattraper les événements manqués. L’idempotence des appels API est également cruciale pour éviter les traitements multiples en cas de réessais.
Les échecs d’intégration peuvent également provenir de :
- Échec de vérification d’identité : Lors des processus d’onboarding ou de KYC, si les données fournies ne correspondent pas aux vérifications externes.
- Document rejeté à l’upload : Lié aux exigences de format, de qualité ou de contenu des pièces justificatives.
- Dossier expiré : Souvent le cas pour les parcours d’inscription qui ont une durée de vie limitée et qui nécessitent une reprise ou un redémarrage.
Ces scénarios, bien que techniques, ont des conséquences directes sur le taux de conversion et l’expérience client. Une surveillance proactive et des mécanismes de reprise sont indispensables.
Enfin, la transition vers les adresses structurées ISO 20022, obligatoire au 15 novembre 2026 pour tous les paiements SEPA, représente un défi concret pour les systèmes d’information, notamment les ERP et les back-offices. Il s’agit d’une migration de données qui impacte la manière dont les informations de paiement sont collectées, stockées et transmises.
Pour garantir la sécurité et la valeur juridique de vos processus digitaux, il est essentiel de maîtriser le cadre réglementaire eIDAS pour la signature électronique.
Sécurisez votre choix avant d’intégrer une solution de paiement.
Architecture, conformité, orchestration, délais d’intégration et dépendance fournisseur : Nuvelia vous aide à cadrer la solution adaptée à votre contexte.
Préparer l’avenir : Open Finance (FIDA) et convergence
L’écosystème financier est en pleine mutation. Au-delà de la PSD2 et des paiements instantanés, les régulateurs et les acteurs du marché préparent l’ère de l’Open Finance et de l’identité numérique.
Le règlement FIDA (Financial Data Access), dont les négociations en trilogue se poursuivent en 2026, marquera l’extension de la logique « open » au-delà des seuls comptes de paiement. Il englobera les données d’investissement, de pension, d’assurance et de crédit, ouvrant de nouvelles opportunités pour des services financiers innovants, mais aussi de nouveaux défis d’intégration et de sécurité des données.
La convergence entre l’Authentification Forte (SCA) et l’EUDI Wallet est un autre axe stratégique. Le portefeuille d’identité numérique européen offrira un moyen d’authentification robuste et interopérable, simplifiant potentiellement l’expérience SCA pour les utilisateurs tout en renforçant la sécurité.
Enfin, la réforme de la facturation électronique et de l’e-reporting en France, avec une réception obligatoire dès septembre 2026 et un échelonnement de l’émission, introduit un lien direct entre les systèmes de paiement et les obligations fiscales. Le statut d’encaissement des prestations de services devra être transmis, faisant du SI de paiement une source de données fiscales. L’adoption généralisée des adresses structurées ISO 20022 pour les paiements SEPA d’ici novembre 2026 s’inscrit pleinement dans cette logique de normalisation des échanges de données.
Toutes ces évolutions s’inscrivent dans un contexte de conformité cumulatif, notamment avec l’application du règlement DORA (Digital Operational Resilience Act), qui impose des exigences strictes en matière de résilience opérationnelle aux entités financières, y compris les PSP. La capacité à s’adapter rapidement à ces changements réglementaires et techniques est un facteur clé de succès pour les développeurs et les architectes en 2026.
À lire ensuite
