Definição
Os fluxos SCA definem como um PSU faz sua autenticação forte junto ao seu ASPSP, em um consentimento PSD ou em uma iniciação de pagamento.
A PSD2 prevê três modos — redirect, decoupled, embedded — e cada banco escolhe qual oferece. Para um TPP que quer cobrir todo o mercado, dominar os três é indispensável.
Os 3 modos em resumo
- Redirect — o PSU é redirecionado para a página ou o app do banco para se autenticar e depois retorna ao TPP. O mais comum na França.
- Decoupled — o PSU permanece na interface do TPP, mas valida o SCA por uma notificação push no app do banco. A UX mais fluida.
- Embedded — o PSU insere seus fatores de SCA diretamente na interface do TPP, que os transmite ao banco. O mais raro e o menos recomendado.
Redirect: o padrão de fato
O mais difundido, sobretudo na França e na Alemanha. O TPP redireciona para a URL de autenticação do ASPSP; o PSU se identifica na página real do seu banco (biometria, SMS, push) e retorna com um código OAuth2. Vantagens: familiar, responsabilidade clara do lado do banco, integração simples. Desvantagens: saída do contexto do TPP (perda de marca), retornos às vezes mal-sucedidos no mobile (deep links), atrito se a sessão bancária tiver expirado.
Decoupled: a melhor UX
O TPP dispara o SCA do lado do ASPSP, que envia uma notificação push no app bancário; o PSU valida por biometria no celular, sem sair do site do TPP, que faz polling do status. Vantagens: manutenção do contexto, biometria nativa, sem redirecionamento. Desvantagens: pressupõe o app bancário instalado, gestão mais complexa (polling ou webhook), suporte desigual entre os bancos.
Embedded: a evitar, salvo caso específico
O TPP exibe um formulário para inserir credenciais e fatores de SCA, que transmite ao banco. Vantagem: nenhum redirecionamento. Grandes desvantagens: risco de phishing (o PSU se acostuma a inserir suas credenciais fora de contexto), responsabilidade ambígua, sem biometria e um modo mal visto pelos reguladores — a maioria dos grandes bancos o recusa.
Comparação resumida
| Critério | Redirect | Decoupled | Embedded |
|---|---|---|---|
| Fluidez de UX | Média | Excelente | Boa |
| Segurança percebida | Excelente | Excelente | Fraca |
| Compatibilidade | Muito ampla | Variável | Muito limitada |
| Mobile nativo | Média (deep links) | Excelente | Boa |
| Esforço de integração | Baixo | Médio | Alto |
| Recomendado | Sim (padrão seguro) | Sim (se disponível) | Não (a evitar) |
No ecossistema PSD2
O fluxo é escolhido pelo ASPSP, não pelo TPP. Do lado do TPP, é preciso detectar dinamicamente o modo ou os modos de cada banco e adaptar a integração. Os agregadores (Bridge, Tink, TrueLayer) absorvem essa complexidade.
Exemplos concretos
- Bancos franceses (redirect): BNP Paribas, Société Générale, Crédit Agricole, LCL, BPCE e La Banque Postale privilegiam o redirect, com o SCA acontecendo em seu app via push.
- Neobancos (decoupled): N26, Revolut, Boursorama e Hello Bank costumam oferecer um modo decoupled mais fluido, sobretudo no mobile.
- Caso PISP: no checkout, a Fintecture precisa detectar o banco já na digitação do IBAN, rotear para o fluxo certo e gerenciar o polling em decoupled — daí seu valor agregado frente a uma integração banco a banco.
- Conversão: passar do redirect ao decoupled pode ganhar de 10 a 15 pontos de conversão em um carrinho de e-commerce.
- Caso AISP: um único SCA completo na conexão e, depois, 180 dias de refresh via token OAuth2 sem novo SCA.
- Armadilhas: alguns bancos exigem um intervalo mínimo antes do polling, outros impõem um webhook — ler a documentação de cada ASPSP é obrigatório.
- Evolução PSR / PSD3: endurecimento das exigências de qualidade dos fluxos e igualdade de tratamento entre clientes próprios e clientes de TPP, pondo fim a certas práticas discriminatórias.