Definición
Los flujos SCA definen cómo un PSU realiza su autenticación reforzada ante su ASPSP, durante un consentimiento PSD o una iniciación de pago.
La PSD2 prevé tres modos — redirect, decoupled, embedded — y cada banco elige cuál ofrece. Para un TPP que quiere cubrir todo el mercado, dominar los tres es indispensable.
Los 3 modos en resumen
- Redirect — el PSU es enviado a la página o la app de su banco para autenticarse y luego vuelve al TPP. El más habitual en Francia.
- Decoupled — el PSU permanece en la interfaz del TPP, pero valida la SCA mediante una notificación push en la app de su banco. La UX más fluida.
- Embedded — el PSU introduce sus factores de SCA directamente en la interfaz del TPP, que los transmite al banco. El más raro y el menos recomendado.
Redirect: el estándar de facto
El más extendido, sobre todo en Francia y Alemania. El TPP redirige a la URL de autenticación del ASPSP; el PSU se identifica en la página real de su banco (biometría, SMS, push) y vuelve con un código OAuth2. Ventajas: familiar, responsabilidad clara del lado del banco, integración sencilla. Inconvenientes: salida del contexto del TPP (pérdida de marca), retornos a veces fallidos en móvil (deep links), fricción si la sesión bancaria ha caducado.
Decoupled: la mejor UX
El TPP dispara la SCA del lado del ASPSP, que envía una notificación push a la app bancaria; el PSU valida con biometría en su teléfono, sin salir del sitio del TPP, que hace polling del estado. Ventajas: mantenimiento del contexto, biometría nativa, sin redirección. Inconvenientes: presupone la app bancaria instalada, gestión más compleja (polling o webhook), soporte desigual según los bancos.
Embedded: a evitar salvo caso específico
El TPP muestra un formulario para introducir credenciales y factores de SCA, que transmite al banco. Ventaja: ninguna redirección. Grandes inconvenientes: riesgo de phishing (el PSU se acostumbra a introducir sus credenciales fuera de contexto), responsabilidad ambigua, sin biometría y un modo mal visto por los reguladores — la mayoría de los grandes bancos lo rechazan.
Comparación resumida
| Criterio | Redirect | Decoupled | Embedded |
|---|---|---|---|
| Fluidez de UX | Media | Excelente | Buena |
| Seguridad percibida | Excelente | Excelente | Débil |
| Compatibilidad | Muy amplia | Variable | Muy limitada |
| Móvil nativo | Media (deep links) | Excelente | Buena |
| Esfuerzo de integración | Bajo | Medio | Alto |
| Recomendado | Sí (opción segura) | Sí (si disponible) | No (a evitar) |
En el ecosistema PSD2
El flujo lo elige el ASPSP, no el TPP. Del lado del TPP hay que detectar dinámicamente el modo o los modos de cada banco y adaptar la integración. Los agregadores (Bridge, Tink, TrueLayer) absorben esta complejidad.
Ejemplos concretos
- Bancos franceses (redirect): BNP Paribas, Société Générale, Crédit Agricole, LCL, BPCE y La Banque Postale privilegian el redirect, con la SCA realizándose en su app mediante push.
- Neobancos (decoupled): N26, Revolut, Boursorama y Hello Bank suelen ofrecer un modo decoupled más fluido, sobre todo en móvil.
- Caso PISP: en el checkout, Fintecture debe detectar el banco en cuanto se introduce el IBAN, enrutar al flujo correcto y gestionar el polling en decoupled — de ahí su valor añadido frente a una integración banco por banco.
- Conversión: pasar del redirect al decoupled puede ganar de 10 a 15 puntos de conversión en una cesta de comercio electrónico.
- Caso AISP: una sola SCA completa en la conexión y, después, 180 días de refresh mediante un token OAuth2 sin nueva SCA.
- Trampas: algunos bancos exigen un retardo mínimo antes del polling, otros imponen un webhook — leer la documentación de cada ASPSP es obligatorio.
- Evolución PSR / PSD3: endurecimiento de las exigencias de calidad de los flujos e igualdad de trato entre los clientes propios y los clientes de TPP, poniendo fin a ciertas prácticas discriminatorias.