Como funciona o Vínculo de Dispositivo da Jornada Sem Redirecionamento

Visão Geral

A Jornada Sem Redirecionamento (JSR) é uma modalidade do Open Finance as a Service que permite ao usuário autorizar consentimentos e realizar pagamentos sem sair do aplicativo da instituição iniciadora de pagamentos (ITP) — eliminando o redirecionamento ao app ou site da detentora de conta (Banco aprovador).

Para que essa jornada seja segura, ela exige o Vínculo de Dispositivo: um mecanismo que associa criptograficamente o dispositivo móvel do usuário à sua conta na detentora, utilizando o padrão FIDO2. Uma vez que o dispositivo esteja vinculado e autorizado, o usuário pode realizar transações sem redirecionamento entre a ITP e a detentora de conta.

---

Ciclo de Vida do Vínculo: Máquina de Estados

O vínculo de dispositivo percorre uma sequência de estados bem definida. Cada etapa possui um timeout máximo — caso não seja concluída no prazo, o vínculo é automaticamente rejeitado.

Estados e Transições

---

Fluxo Detalhado por Etapa

1. Criação do Vínculo — AWAITING_RISK_SIGNALS

O processo se inicia quando a ITP cria o vínculo de dispositivo via endpoint da API. Nesse momento, o dispositivo do usuário deve enviar os sinais de risco para a detentora de conta.

• O processamento dos sinais de risco deve ocorrer preferencialmente de forma assíncrona, para cumprir os requisitos de desempenho dos endpoints.
• A detentora pode rejeitar a solicitação de forma síncrona, retornando os erros previstos na especificação.
• A detentora tem autonomia sobre seu apetite a risco: caso entenda que as informações recebidas não são suficientes, pode negar o pagamento mesmo com sinais opcionais não enviados.

2. Validação pelo Titular — AWAITING_ACCOUNT_HOLDER_VALIDATION

Estado transitório que representa o redirecionamento do usuário ao ambiente da detentora para autenticação. O usuário deve confirmar a vinculação no app da detentora.

• Prazo máximo: 15 minutos.
• Se o prazo expirar sem que os sinais, validações e redirecionamento sejam concluídos, o status é alterado para REJECTED.

3. Registro do Dispositivo — AWAITING_ENROLLMENT

Com a validação concluída, o dispositivo do usuário realiza o enrollment FIDO2: geração de um par de chaves assimétricas no hardware seguro do dispositivo.

• A chave privada permanece no dispositivo e nunca trafega pela rede.
• A chave pública é enviada à detentora via fido-registration-options.
• A detentora identifica a plataforma do usuário (Android/iOS) nesse momento.
• A validação da origin FIDO é obrigatória: o atributo origin presente no clientDataJSON deve estar contido no software_origin_uris registrado durante o DCR/DCM. Se a validação falhar, a solicitação deve ser rejeitada com o código ORIGEM_FIDO_INVALIDA.
• Prazo máximo: 5 minutos.

Pré-requisito de infraestrutura: A página que hospeda a validação de biometria FIDO (relying party) deve estar configurada em um domínio próprio protegido por um Certificado BRCAC (certificado emitido por Autoridade Certificadora credenciada pelo Open Finance Brasil). A aquisição do certificado BRCAC deve ser realizada junto a uma AC parceira antes da configuração do domínio FIDO, pois ele é exigido para que o dispositivo consiga validar a autenticidade do relying party durante o processo de enrollment e autenticação.

4. Autorização Final — AUTHORISED

Após o enrollment, o usuário tem 5 minutos para concluir a autorização enviando suas credenciais à detentora. Uma vez no estado AUTHORISED:

• O dispositivo está apto a realizar transações sem redirecionamento entre ITP e detentora.
• A plataforma do usuário é registrada novamente no fido-sign-options durante cada pagamento.
• Os campos dailyLimit e transactionLimit ficam disponíveis na consulta GET /enrollments/{enrollmentId} após a autorização do consentimento.

Se o usuário não concluir a autorização dentro do prazo, o estado é alterado para REVOKED.

---

Limites do Vínculo de Dispositivo

Durante a autorização do vínculo, o usuário define os limites que serão aplicados às transações realizadas através desse dispositivo. As regras são:

Limite diário:

• Apresentado inicialmente em branco para o usuário.
• O usuário é informado sobre os limites Pix estabelecidos na detentora.
• Se o usuário não definir um limite, a detentora considera o limite Pix vigente como limite diário.
• Nunca deve ser tratado como 0 caso não definido.

Limite por transação:

• Apresentado por padrão como R$ 500,00.
• O usuário pode reduzir o valor.
• Caso exista contrato bilateral entre ITP e detentora, o valor padrão pode ser superior a R$ 500,00.

Convivência com limites do arranjo:
Ambos os limites precisam ser respeitados simultaneamente. Para uma transação ser permitida, ela deve respeitar tanto o limite do arranjo Pix (definido entre cliente e detentora) quanto o limite do vínculo (definido durante a autorização). Não existe limite máximo definido para o período de piloto.

Número de dispositivos:
Não existe limite para a quantidade de dispositivos que podem ser vinculados entre a ITP, o cliente e a detentora.

---

Revogação do Vínculo

A revogação pode ocorrer a qualquer momento após o estado AUTHORISED, por iniciativa de qualquer uma das partes:

• Usuário: pode revogar tanto pelo app da ITP quanto pelo app da detentora — especialmente importante em caso de perda ou roubo do dispositivo.
• ITP: pode revogar unilateralmente caso identifique necessidade em processo interno.
• Detentora de conta: pode revogar unilateralmente caso alguma regra não seja respeitada ou em situações de fraude.

Atenção: A revogação do vínculo não implica no cancelamento de pagamentos agendados cujo consentimento já foi autorizado. Como vínculo e consentimento são entidades separadas, os agendamentos permanecem ativos.

---

Sincronização de Status

Como o vínculo pode ser revogado tanto na ITP quanto na detentora, é necessário manter o status sincronizado entre as partes. Os mecanismos disponíveis são:

• Polling: consultas periódicas ao GET /enrollments/{enrollmentId}.
• Webhook: notificações automáticas enviadas pela detentora quando o status do vínculo é alterado.

---

Múltiplas Alçadas e Pagamentos

Caso o consentimento possua múltiplas alçadas aprovadoras, a aprovação via jornada sem redirecionamento representa apenas o primeiro aprovador. As demais aprovações devem ser coletadas conforme o processo interno de cada detentora.

---

Certificações Necessárias

Para participar da Jornada Sem Redirecionamento, as instituições precisam obter as seguintes certificações:

Iniciadoras de pagamentos (ITP):

Requisito de Certificado para o Domínio FIDO

Além das certificações funcionais e de segurança, as instituições precisam adquirir um Certificado BRCAC para configurar o domínio da página que realiza a validação de biometria (FIDO). Esse certificado é emitido por Autoridades Certificadoras (ACs) credenciadas no âmbito do Open Finance Brasil e é obrigatório para:

• Estabelecer a identidade confiável do relying party FIDO perante o dispositivo do usuário.
• Garantir a integridade do canal durante o enrollment e a autenticação biométrica.
• Satisfazer a validação da origin FIDO exigida na especificação.

A compra do certificado BRCAC deve ser providenciada com antecedência, pois é um pré-requisito para a configuração do domínio FIDO e não está incluída nos processos de certificação funcional ou de segurança listados acima. Nossos especialistas podem te ajudar durante qualquer etapa deste processo.

---

Perguntas Frequentes

A revogação do vínculo cancela pagamentos agendados?
Não. O vínculo foi utilizado para autorizar o consentimento, mas vínculo e consentimento são entidades separadas. A revogação do vínculo não cancela os pagamentos agendados a partir de um consentimento já autorizado.

Existe prazo máximo para o campo expirationDateTime?
Não. O campo /data/expirationDateTime representa a data de expiração do vínculo de fato e não é alterado a cada transição de status da máquina de estados.

Existe limite de dispositivos por CPF?
Não existe limite de dispositivos que podem ser vinculados entre a ITP, o cliente e a detentora.

Quando a ITP informa os limites à detentora?
Essa informação não é enviada da ITP para a detentora. Os limites e prazo de expiração são definidos pelo usuário no momento da autorização do vínculo.

O que é o campo "Dispositivo Autorizado" na tela de autorização?
É um campo que permite ao cliente definir um nome amigável para o vínculo, facilitando que ele se recorde do dispositivo ao qual aquela autorização está associada.

---

Etapa 1: Solicitação de vinculação de conta

O usuário inicia a jornada de vinculação de conta na Instituição Iniciadora de Transação de Pagamento (ITP). Escolhe a Instituição Detentora de Conta (ID) que será utilizada para realizar os pagamentos sem redirecionamento.

A ITP deve: Garantir uma experiência clara, segura e informativa; Indicar, em algum ponto da jornada, que o serviço é baseado em Open Finance; Permitir a seleção eficiente da ID; Validar os dados inseridos, ocultar informações sensíveis; Preparar a solicitação de vinculação de conta para envio à ID; Quando aplicável, exibir mensagens de erro claras ao usuário. A tela deve conter as seguintes informações:

A. Identificação do Open Finance: mencionar o Open Finance em algum ponto visível da interface. Ex.: tooltip, selo, frase como "com a segurança do Open Finance”.

B. Próximos passos: dar visibilidade sobre as próximas etapas até a conclusão da jornada.

C. Finalidade da jornada: informar o usuário que o vínculo de conta está sendo criado para realização de transações futuras.

D. Termos e condições: quando aplicável, apresentar os termos de uso de forma clara.

E. Opt-in: não utilizar opt-in para aceite.

F. Aceite: informar que, ao continuar, o usuário está concordando com os termos e condições.

Nas nossas telas, o processo de criação de vínculo se inicia na Tela de Gestão Open Finance, o cliente escolhe a visualização de contas salvas e em seguida abre um pop up informando quais são as contas saltas e se ele deseja adicionar mais contas para criar o vínculo, como é mostrado nas telas a seguir.

Nesse momento o cliente observa os opções de contas salvas e pode incluir novos vínculos, quando clique em Autorizar e salvar uma nova conta.

Na sequência, o cliente deverá apenas informar a Instituição com a qual deseja autorizar o vínculo de conta. Assim que o fizer, seguirá automaticamente para a próxima etapa.

Cenário: Busca e seleção da ID:disponibilizar ferramenta de busca e seleção da ID, com funcionamento baseado em marcas e conforme os critérios abaixo:

1. Exibir todas as Detentoras que ofereçam a JSR.
2. Permitir que o usuário busque tanto pela marca da ID quanto por um participante associado, exibindo corretamente a marca correspondente nos resultados.
3. Exigir que a seleção final da ID seja feita pela marca da instituição, e não pelo nome do participante associado.
4. Exibir apenas marcas adequadas ao tipo de público identificado (PF ou PJ).
5. Garantir que cada marca seja exibida uma única vez, mesmo que existam múltiplos registros para ela no Diretório de Participantes.

Esta é a etapa de checagem dos dados da conta a ser salva, antes de seguir para a detentora de conta informada.
Caso a troca da instituição seja necessária, bastará utilizar o botão em forma de ícone “seta para esquerda”, localizado na parte superior esquerda da tela.

Por fim, após conferir os dados, basta clicar no botão Continuar para a confirmação para prosseguir com a jornada.

O redirecionamento será automático para o ambiente da instituição detentora de conta, onde comunicamos a criação do vínculo de dispositivo (enrollment) e enviamos os parâmetros de sinais de riscos. No ambiente da detentora de contas, o cliente passa pelas etapas de Autenticação e Confirmação do Pagamento.

Autenticação e criação de vínculo

O formato de Autenticação é definido pela própria Instituição Detentora de contas, respeitando os seus modelos de segurança, a exemplo de login e senha, reconhecimento biométrico ou reconhecimento facial.

O mesmo ocorre com o formato de Confirmação da operação, que segue os padrões estabelecidos pela Instituição Financeira escolhida, em alinhamento com os requisitos de etapas e ações definidos pelo ecossistema Open Finance.

Redirecionamento (volta) e efetivação da jornada

Após a confirmação do pagamento no ambiente da detentora de contas, o cliente é novamente redirecionado para o ambiente da empresa contratante do Open Keys, onde é necessário confirmar sua identidade através de um gesto (biometria, Fáceis, PIN, etc).

Após a confirmação da identidade do cliente, o Open Keys processa as informações da operação e o cliente, então, visualiza a confirmação do vínculo de conta.

Nesta tela, ele terá as opções de ser redirecionado para o endereço de callback informado na jornada ou Ir para a área de gestão, onde será redirecionado para a Área de Gestão das Contas Salvas (Vínculos).

Assim, o vínculo da conta está concluído e o usuário pode prosseguir para o pagamento.

Cenário: Efetivação da vinculação de conta

1. Resultado da solicitação: exibir mensagem informando sobre o resultado (sucesso ou falha) da solicitação de vinculação de conta.
2. Detalhes do vínculo: informar sobre a possibilidade de acesso aos detalhes do vínculo através da área de gestão.
3. Cancelamento do vínculo: informar sobre a possibilidade de cancelamento do vínculo através da área de gestão.