Définition
Les flux SCA définissent comment un PSU effectue son authentification forte auprès de son ASPSP, lors d'un consentement DSP ou d'une initiation de paiement.
La DSP2 prévoit trois modes — redirect, decoupled, embedded — et chaque banque choisit lequel elle propose. Pour un TPP qui veut couvrir tout le marché, maîtriser les trois est indispensable.
Les 3 modes en bref
- Redirect — le PSU est renvoyé sur la page ou l'app de sa banque pour s'authentifier, puis revient vers le TPP. Le plus courant en France.
- Decoupled — le PSU reste dans l'interface du TPP, mais valide la SCA via une notification push dans l'app de sa banque. L'UX la plus fluide.
- Embedded — le PSU saisit ses facteurs SCA directement dans l'interface du TPP, qui les transmet à la banque. Le plus rare et le moins recommandé.
Redirect : le standard de fait
Le plus répandu, surtout en France et en Allemagne. Le TPP redirige vers l'URL d'authentification de l'ASPSP ; le PSU s'identifie sur la vraie page de sa banque (biométrie, SMS, push), puis revient avec un code OAuth2. Avantages : familier, responsabilité claire côté banque, intégration simple. Inconvénients : sortie du contexte TPP (perte de marque), retours parfois ratés sur mobile (deep link), friction si la session bancaire a expiré.
Decoupled : la meilleure UX
Le TPP déclenche la SCA côté ASPSP, qui envoie une notification push dans l'app bancaire ; le PSU valide par biométrie sur son téléphone, sans quitter le site du TPP, qui poll le statut. Avantages : maintien du contexte, biométrie native, pas de redirection. Inconvénients : suppose l'app bancaire installée, gestion plus complexe (polling ou webhook), support inégal selon les banques.
Embedded : à éviter sauf cas spécifique
Le TPP affiche un formulaire pour saisir identifiants et facteurs SCA, qu'il transmet à la banque. Avantage : aucune redirection. Inconvénients majeurs : risque de phishing (le PSU s'habitue à saisir ses credentials hors contexte), responsabilité ambiguë, pas de biométrie, et un mode mal vu des régulateurs — la plupart des grandes banques le refusent.
Comparaison synthétique
| Critère | Redirect | Decoupled | Embedded |
|---|---|---|---|
| UX fluidité | Moyenne | Excellente | Bonne |
| Sécurité perçue | Excellente | Excellente | Faible |
| Compatibilité | Très large | Variable | Très limitée |
| Mobile natif | Moyen (deep links) | Excellent | Bon |
| Effort d'intégration | Faible | Moyen | Élevé |
| Recommandé | Oui (défaut sûr) | Oui (si dispo) | Non (à éviter) |
Dans l'écosystème PSD2
Le flux est choisi par l'ASPSP, pas par le TPP. Côté TPP, il faut détecter dynamiquement le ou les modes de chaque banque et adapter l'intégration. Les agrégateurs (Bridge, Tink, TrueLayer) absorbent cette complexité.
Exemples concrets
- Banques françaises (redirect) : BNP Paribas, Société Générale, Crédit Agricole, LCL, BPCE et La Banque Postale privilégient le redirect, la SCA se faisant sur leur app via push.
- Néobanques (decoupled) : N26, Revolut, Boursorama et Hello Bank offrent souvent un mode decoupled plus fluide, surtout sur mobile.
- Cas PISP : Fintecture, au checkout, doit détecter la banque dès la saisie de l'IBAN, router vers le bon flux et gérer le polling en decoupled — d'où sa valeur ajoutée face à une intégration banque par banque.
- Conversion : passer du redirect au decoupled peut faire gagner 10 à 15 points de conversion sur un panier e-commerce.
- Cas AISP : une seule SCA complète à la connexion, puis 180 jours de refresh via token OAuth2 sans re-SCA.
- Pièges : certaines banques exigent un délai minimal avant le polling, d'autres imposent un webhook — lire chaque doc ASPSP est obligatoire.
- Évolution PSR / DSP3 : durcissement des exigences de qualité des flux et égalité de traitement entre clients propres et clients TPP, mettant fin à certaines pratiques discriminantes.