Jornada Otimizada: o Iniciador é aprovado no piloto que reduz pagamento rejeitado
A Jornada Otimizada une consentimento de dados e de pagamento em uma única aprovação — e checa o saldo antes de disparar a transação. O Iniciador foi uma das duas primeiras instituições aprovadas no piloto do Open Finance Brasil.
Todo mundo que trabalha com Pix via Open Finance já viu essa cena: o usuário aprova o pagamento, tudo parece certo, e a transação cai por falta de saldo. O usuário fica com a sensação de que "não funcionou", quando na verdade o problema é de timing, não de produto.
A Jornada Otimizada (JO) foi desenhada pelo Open Finance Brasil exatamente para resolver isso.
O que é a Jornada Otimizada
Hoje, consentimento de dados (que permite consultar saldo) e consentimento de pagamento são dois fluxos separados. O usuário autoriza o pagamento sem que o iniciador saiba, naquele momento, se há saldo disponível na conta.
A JO une os dois em uma única experiência de aprovação. Por trás da tela, os consentimentos continuam segregados (a arquitetura de permissões não muda), mas o usuário vê e aprova tudo de uma vez. Não é uma API nova: é uma orquestração mais inteligente das APIs que já existem.
Pense assim: é a diferença entre perguntar "você tem dinheiro?" depois que a pessoa já disse "sim, eu pago", e simplesmente olhar a carteira dela antes de fazer a pergunta.
Onde a Jornada Otimizada funciona
A JO está disponível para dois produtos: Pix Biometria (JSR ou jornada sem redirecionamento) e Pix Inteligente (transferências inteligentes ou sweeping). Abaixo, detalhamos como ela funciona em cada um dos produtos.
Pix Biometria (JSR, jornada sem redirecionamento)
O consentimento de dados e o consentimento de pagamento são aprovados juntos, sem o usuário sair do app do iniciador. Menos telas, menos etapas, menos chance de abandono no meio do caminho.
- O Software Cliente (client) gera um
access_tokenutilizando ogrant_type=client_credentialspara possibilitar a criação dos consentimentos primário e secundário. - O client cria um consentimento secundário de dados, solicitando permissões referentes aos agrupamentos de saldo e/ou limites. Esse consentimento deve ser criado com o parâmetro
isLinkedcom o valortrue, indicando que faz parte de uma Jornada Otimizada. - O client cria um consentimento primário de Vínculo de Dispositivo (JSR), vinculando-o ao consentimento de dados. O objeto
journeydeve terisLinked=trueelinkId=<consentId do consentimento de dados>. - O client chama o endpoint PAR, informando os escopos de ambos os consentimentos, e redireciona o usuário para autenticação e autorização. O Authorization Server identifica a jornada como otimizada a partir dos parâmetros recebidos.
- O usuário revisa os consentimentos no fluxo otimizado e realiza a aprovação.
- O client solicita um novo
access_tokenque inclua os escopos referentes a contas e Jornada sem Redirecionamento (JSR). - O client consulta a API Resources para identificar os recursos compartilhados.
- O client verifica a lista de contas e o saldo disponível para confirmar a possibilidade de execução do pagamento.
- O client inicia o processo de pagamento via Jornada sem Redirecionamento.
Pix Inteligente (Transferências Inteligentes / Sweeping)
Mesmo princípio aplicado a fluxos recorrentes de varredura de saldo. O sistema já sabe, antes de disparar a transferência, se a conta de origem comporta o valor.
- O Software Cliente (client) gera um
access_tokenutilizando ogrant_type=client_credentialspara possibilitar a criação dos consentimentos primário e secundário. - O client cria um consentimento secundário de dados, solicitando permissões referentes aos agrupamentos de saldo e/ou limites. Esse consentimento deve ser criado com o parâmetro
isLinkedcom o valortrue, indicando que faz parte de uma Jornada Otimizada. - O client cria um consentimento primário de Transferências Inteligentes, vinculando-o ao consentimento de dados. O objeto
journeydeve terisLinked=trueelinkId=<consentId do consentimento de dados>. - O client chama o endpoint PAR, informando os escopos de ambos os consentimentos, e redireciona o usuário para autenticação e autorização. O Authorization Server identifica a jornada como otimizada a partir dos parâmetros recebidos.
- O usuário revisa os consentimentos no fluxo otimizado e realiza a aprovação.
- O client solicita um novo
access_tokenque inclua os escopos referentes a contas e transferências inteligentes. - O client consulta a API Resources para identificar os recursos compartilhados.
- O client verifica a lista de contas e o saldo disponível para confirmar a possibilidade de execução do pagamento.
- O client inicia o processo de pagamento via Transferências Inteligentes.
Como a Jornada Otimizada aumenta conversão, na prática
A conversão de pagamento via Open Finance tem três grandes vilões: erro do usuário, indisponibilidade do banco e saldo insuficiente. A JO ataca diretamente o terceiro, e ele costuma ser o mais silencioso.
Alguns exemplos de onde isso aparece:
- Checkout de e-commerce com Pix automático. Sem JO, o cliente autoriza o pagamento e só descobre depois que faltou saldo, quando o pedido já foi cancelado no back-end. Com JO, a falta de saldo aparece antes da autorização, e o cliente pode resolver na hora (Pix de outra conta, escolher outro método) em vez de abandonar a compra.
- Cobrança recorrente (assinatura, mensalidade). Hoje, uma tentativa de débito automático sem saldo vira uma cobrança rejeitada que precisa ser reprocessada, gerando custo operacional e atrito com o cliente. Com JO aplicada ao Pix Inteligente, o sistema identifica o risco de saldo insuficiente antes de disparar a cobrança.
- Onboarding de app financeiro. Fluxos que hoje pedem duas aprovações separadas (dados, depois pagamento) perdem uma fração de usuários no meio do caminho. Unificar em uma aprovação só reduz esse ponto de abandono.
Em todos os casos, o ganho não vem de "vender mais". Vem de rejeitar menos por um motivo evitável, e é exatamente esse tipo de rejeição que mais corrói taxa de conversão em pagamentos recorrentes e checkout.
Onde estamos hoje
A JO está em fase de piloto, e a aprovação não é automática: exige homologação técnica junto ao Open Finance Brasil. Até agora, duas instituições foram aprovadas: o Iniciador e a Pluggy, cliente do Iniciador.
O Iniciador está pronto para atender players regulados
Bancos, fintechs, plataformas e demais instituições que já operam ou pretendem operar com Open Finance podem contar com o Iniciador para implementar a Jornada Otimizada dentro da própria operação, com a base técnica já homologada.
Fonte: Open Finance Brasil.