Instabilidade no Webhook Validação via Open Finance - IDPay

Update timeline

1. investigating Mar 31, 2026, 04:22 PM UTC

   Prezado Cliente, Identificamos uma instabilidade em nossa funcionalidade de validação via Open Finance. Esse comportamento teve início no dia 25/03, às 23:05, fazendo com que o status das transações afetadas ficasse como pendente. Informamos que a causa principal dessa interrupção foi corrigida às 13:10 de hoje. Neste momento, nossa engenharia já está mobilizada e trabalhando intensamente para reprocessar todos os casos retroativos que ainda estão com a validação pendente. Compreendemos o impacto que esse cenário pode causar em suas operações e lamentamos qualquer transtorno. Estamos dedicando total prioridade para que todas as transações sejam normalizadas o mais rápido possível. Novas atualizações serão enviadas em breve. Equipe Unico.

2. identified Mar 31, 2026, 04:24 PM UTC

   Prezado Cliente, Informamos que a origem da instabilidade na funcionalidade de validação via Open Finance (IDPay) foi devidamente mapeada por nossa equipe técnica. O comportamento sistêmico, que teve início no dia 25/03 às 23:05 e manteve o status das transações como pendente, teve sua causa raiz tratada com sucesso às 13:10 de hoje. Status das Ações: Medidas Corretivas: Com o problema principal sanado, escalonamos nossos recursos operacionais e já iniciamos a execução das medidas corretivas para reprocessar todos os casos retroativos afetados. Prioridade Máxima: Nossa engenharia está atuando com senso de urgência absoluto e dedicação total para garantir a conclusão e a integridade de todas as validações pendentes no menor tempo possível. Reiteramos nosso compromisso com a estabilidade e a segurança de nossas operações. Manteremos você informado sobre a evolução deste cenário e a conclusão do reprocessamento. Equipe Unico.

3. monitoring Mar 31, 2026, 04:29 PM UTC

   Prezado Cliente, Informamos que as ações corretivas referentes à instabilidade na validação via Open Finance (IDPay) foram executadas com sucesso. A falha técnica, que gerava pendências nas transações desde o dia 25/03 às 23:05, foi contornada às 13:10 de hoje, e nosso ambiente de produção já apresenta estabilidade. Neste momento, o serviço já pode ser utilizado normalmente para novas requisições. Paralelamente, nossa engenharia segue focada no reprocessamento de todos os casos retroativos que ficaram com o status de validação pendente. Entramos agora em uma fase de monitoramento rigoroso e acompanhamento assistido. Nossa equipe permanece dedicada e atenta a qualquer oscilação, a fim de garantir a consistência da performance e assegurar que a operação flua sem novos impactos. Agradecemos a paciência e a confiança enquanto garantimos a estabilização completa da plataforma. Novas atualizações serão enviadas conforme a evolução do reprocessamento. Equipe Unico.

4. resolved Mar 31, 2026, 06:27 PM UTC

   Prezado Cliente, Informamos que o incidente relacionado à instabilidade na validação via Open Finance foi mitigado com sucesso, o reprocessamento dos dados foi concluído e o sistema já se encontra totalmente disponível e operando dentro da normalidade. Abaixo, compartilhamos o relatório de fechamento com os detalhes do ocorrido e as ações tomadas por nossa equipe. Resumo Executivo e Impacto A partir das 23:05 do dia 25/03, identificamos uma falha no processamento das validações via Open Finance. Esse comportamento impediu a atualização de status no nosso sistema, fazendo com que as transações de nossos clientes ficassem retidas no status "pendente". A correção principal foi aplicada às 13:10 de hoje e, desde então, nossa engenharia atuou no reprocessamento de 100% dos casos retroativos afetados, normalizando integralmente a operação. Causa Raiz e Resolução A causa raiz do incidente esteve associada a uma atualização recente em nosso gerenciador central de APIs. Essa implementação introduziu uma política de rede que adicionava automaticamente um prefixo aos cabeçalhos de autenticação que não estivessem em um formato padrão predefinido. Como as notificações sistêmicas de atualização de status do nosso provedor parceiro de Open Finance utilizam um formato de token específico e sem prefixo, essa modificação fez com que nossa camada de segurança rejeitasse as conexões por falha de autenticação. A resolução imediata consistiu na reversão dessa atualização (rollback), removendo a política conflitante e restabelecendo o fluxo de comunicação e o processamento correto das validações. Reconhecemos o impacto que instabilidades geram em sua operação e agradecemos a confiança e a parceria durante a resolução deste evento. Continuamos à disposição para quaisquer esclarecimentos adicionais. Equipe Unico.

5. postmortem Apr 27, 2026, 02:34 PM UTC

   **Postmortem: Instabilidade no Webhook Validação via Open Finance - IDPay** ### Resumo Entre os dias 25 e 31 de março de 2026, ocorreu um incidente que afetou nossa integração com o provedor de Open Finance, onde os _webhooks_ recebidos passaram a ser bloqueados com um erro de autorização \(erro 401\). Essa interrupção impediu a conclusão de pagamentos, fazendo com que as transações de nossos clientes ficassem presas no status "aguardando". ### Impacto O impacto direto aos clientes ocorreu entre às 23:05 do dia 25 de março de 2026 e às 13:08 do dia 31 de março de 2026. Durante esse período de aproximadamente cinco dias, um total de 7.101 transações não puderam ser concluídas automaticamente e permaneceram no status "aguardando". Nenhum evento de _webhook_ do nosso provedor parceiro foi processado com sucesso ao longo dessa janela de tempo. ### Causa Raiz A origem do problema foi devido a uma atualização de sistema em nossa camada de _Gateway_ de API, realizada no dia 25 de março por volta das 23:00, que tinha o objetivo de implementar limites de taxa \(_rate limiting_\) para um de nossos clientes corporativos. O _design_ dessa atualização utilizou um caminho de roteamento genérico, o que fez com que a nova política HTTP fosse aplicada a todos os _endpoints_, incluindo a rota específica de recebimento de _webhooks_ do nosso provedor de Open Finance. Essa nova política modificava os cabeçalhos de requisição automaticamente, adicionando o prefixo "Bearer" a qualquer cabeçalho de Autorização que não o possuísse. ‌ Como nosso provedor de integração utiliza um _token_ de acesso opaco e sem prefixo, o sistema modificou a requisição e a camada de segurança tentou validar esse novo formato como se fosse um _token_ JWT padrão. A validação falhou, resultando no erro de acesso negado \(401\). O erro não foi identificado na fase de testes \(ambiente de homologação/UAT\) porque existia uma divergência de configuração: o ambiente de testes possuía tratamentos de exceção para esse caminho específico, configurações estas que estavam ausentes no ambiente de produção. ### Resolução Ao identificar a causa raiz do problema no dia 31 de março, nossa equipe de engenharia executou uma reversão \(_rollback_\) imediata da atualização do _Gateway_ de API para a sua versão anterior. Essa ação removeu a política que alterava os cabeçalhos HTTP, restaurando o processamento normal dos _webhooks_. Logo após a confirmação da estabilidade sistêmica, todas as 7.101 transações afetadas que estavam presas foram reprocessadas e normalizadas com sucesso. ‌ ### Lições Aprendidas Durante a investigação e resolução deste incidente, identificamos oportunidades importantes de melhoria em nossa infraestrutura e processos operacionais: * **Necessidade de Alertas Específicos:** O problema durou dias de forma silenciosa pois não havia uma monitoria sistêmica ou alarmes configurados especificamente para a queda abrupta no volume de recebimento de _webhooks_. Fluxos dependentes de processos assíncronos precisam de mecanismos independentes de detecção de falhas. * **Paridade entre Ambientes:** A diferença de configuração entre os ambientes de teste e produção permitiu que a atualização fosse considerada segura erroneamente. É essencial garantir a paridade estrita entre os ambientes para evitar falsos positivos na validação de implantações. * **Gestão de Políticas Globais:** A utilização de roteamento amplo \(caminhos genéricos\) na aplicação de políticas de segurança introduz o risco de afetar rotas com requisitos de autenticação não padronizados. Exceções sistêmicas devem ser validadas e mapeadas explicitamente em todas as camadas de configuração.