Erros comuns e possíveis tratativas
Conheça os possíveis erros que podem ocorrer e como resolvê-los.
Introdução
Sabemos que os erros fazem parte do dia a dia de qualquer integração, mas queremos que este processo seja o menos traumático possível. Por isso, listamos abaixo os possíveis erros a serem retornados pelas nossas APIs, além das suas possíveis causas e formas de resolvê-los.
Códigos de resposta
Durante a integração com as nossas APIs, você poderá se deparar com os seguintes HTTP Status Code:
Status code | Resumo | Descrição |
---|---|---|
200 | OK | A requisição foi bem sucedida. |
201 | Created | A requisição foi atendida e resultou na criação de um ou mais novos recursos. |
202 | Accepted | A requisição foi aceita para processamento, mas este não foi concluído |
203 | Non-Authoritative Information | A requisição foi bem-sucedida, mas o payload incluído foi modificado em relação à resposta 200 do servidor de origem por um proxy de transformação. |
204 | No Content | O servidor atendeu a requisição com êxito e não há conteúdo adicional para enviar no payload da resposta. |
205 | Reset Content | O servidor atendeu à requisição e deseja que o user agent redefina a "visualização do documento", que causou o envio da requisição, ao seu estado original, conforme recebido do servidor de origem. |
206 | Partial Content | O servidor está atendendo com êxito a uma requisição de intervalo para o recurso de destino, transferindo uma ou mais partes da representação selecionada que correspondem aos intervalos satisfatórios encontrados no campo de cabeçalho range da requisição. |
300 | Multiple Choices | O recurso de destino tem mais de uma representação, cada uma com seu próprio identificador mais específico, e informações sobre as alternativas estão sendo fornecidas para que o usuário (ou user agent ) possa selecionar uma representação preferida redirecionando sua requisição para um ou mais desses identificadores. Em outras palavras, o servidor deseja que o user agent se envolva em uma negociação reativa para selecionar a(s) representação(ões) mais apropriada(s) para suas necessidades. |
301 | Moved Permanently | O recurso de destino recebeu uma nova URI permanente e quaisquer referências futuras a esse recurso deverão usar uma das URIs incluídas. Os clientes com capacidade de edição de links devem, sempre que possível, automaticamente vincular novamente as referências à URI da requisição efetiva a uma ou mais das novas referências enviadas pelo servidor. |
302 | Found | O recurso de destino reside temporariamente em uma URI diferente. Como o redirecionamento pode ser alterado ocasionalmente, o cliente deve continuar a usar a URI de requisição efetiva para solicitações futuras. |
303 | See Other | Indica que o servidor está redirecionando o user agent para um recurso diferente, conforme indicado por uma URI no campo do cabeçalho location , que se destina a fornecer uma resposta indireta à requisição original. Um user agent pode executar uma requisição de recuperação direcionada a essa URI (uma requisição GET ou HEAD se estiver usando HTTP), que também pode ser redirecionado e apresentar o resultado eventual como uma resposta à requisição original. Observe que a nova URI no campo de cabeçalho location não é considerada equivalente à URI da requisição efetiva. |
304 | Not Modified | Indica que uma requisição GET ou HEAD condicional foi recebida e teria resultado em uma resposta 200 (OK) se não fosse pelo fato de a condição ter sido avaliada como falsa. Em outras palavras, não há necessidade de o servidor transferir uma representação do recurso alvo porque a requisição indica que o cliente que fez a solicitação. |
307 | Temporary Redirect | Indica que o recurso de destino reside temporariamente em uma URI diferente e o user agent NÃO DEVE alterar o método de requisição se realizar um redirecionamento automático para essa URI. Como o redirecionamento pode mudar com o tempo, o cliente deve continuar usando a URI da requisição original e efetiva para solicitações futuras. |
400 | Bad Request | Indica que o servidor não pode ou não processará a solicitação devido a algo que é percebido como um erro do cliente (por exemplo, sintaxe de requisição malformada, enquadramento de mensagem de requisição inválido ou roteamento de requisição fraudulenta). |
401 | Unauthorized | Indica que a requisição não foi aplicada porque não possui credenciais de autenticação válidas para o recurso de destino. |
403 | Forbidden | Indica que o nosso servidor entendeu a requisição, mas se recusou a autorizá-la. |
404 | Not Found | Indica que o nosso servidor não encontrou uma representação atual para o recurso de destino ou não está disposto a divulgar que existe uma. |
405 | Method Not Allowed | Indica que o método recebido na linha da requisição é conhecido pelo servidor de origem, mas não é suportado pelo recurso de destino. |
406 | Not Acceptable | Indica que o recurso alvo não possui uma representação atual que seria aceitável para o user agent , de acordo com os campos do cabeçalho de negociação proativa recebidos na requisição e o servidor não está disposto a fornecer uma representação padrão. |
407 | Proxy Authentication Required | Indica que o cliente precisa se autenticar para usar um proxy. Este DEVE enviar um campo de cabeçalho Proxy-Authenticate contendo um desafio aplicável a esse proxy para o recurso de destino. |
408 | Request Timeout | Indica que o nosso servidor não recebeu uma mensagem de requisição completa dentro do tempo que estava preparado para esperar. |
409 | Conflict | Indica que a requisição não pôde ser concluída devido a um conflito com o estado atual do recurso de destino. |
410 | Gone | Indica que o acesso ao recurso alvo não está mais disponível no servidor de origem e que esta condição provavelmente será permanente. |
411 | Length Required | Indica que o nosso servidor se recusa a aceitar a requisição sem um Content-Length definido. |
412 | Precondition Failed | Indica que uma ou mais condições fornecidas nos campos do cabeçalho da requisição foram avaliadas como falsas quando testadas no nosso servidor. |
413 | Payload Too Large | Indica que o nosso servidor está se recusando a processar uma requisição porque o seu payload é maior do que o servidor deseja ou é capaz de processar. |
414 | URI Too Long | Indica que o nosso servidor está se recusando a atender a requisição porque o alvo da requisição é maior do que o servidor está disposto a interpretar. |
415 | Unsupported Media Type | Indica que o servidor de origem está se recusando a atender a requisição porque o payload está em um formato não suportado por esse método no recurso de destino. |
416 | Range Not Satisfiable | Indica que nenhum dos intervalos no campo de cabeçalho range da requisição se sobrepõe à extensão atual do recurso selecionado ou que o conjunto de intervalos solicitado foi rejeitado devido a intervalos inválidos ou um excesso de requisições de faixas pequenas ou sobrepostas. |
417 | Expectation Failed | Indica que a expectativa fornecida no campo de cabeçalho Expect da requisição não pôde ser atendida por pelo menos um dos servidores de entrada. |
423 | Locked | O recurso está bloqueado, indicando que a solicitação não pode ser concluída devido a um estado de bloqueio existente no recurso. |
426 | Upgrade Required | Indica que o nosso servidor se recusa a executar a requisição usando o protocolo atual, mas pode estar disposto a fazê-lo após o cliente atualizar para um protocolo diferente. |
429 | Too Many Requests | Indica que a sua aplicação enviou um número excessivo de solicitações em um período determinado. Nosso servidor pode incluir detalhes adicionais, como cabeçalhos de rate limit, para informar ao cliente quando ele pode fazer solicitações adicionais. |
500 | Internal Server Error | Indica que o nosso servidor encontrou uma condição inesperada que o impediu de atender à solicitação. |
501 | Not Implemented | Indica que o nosso servidor não oferece suporte à funcionalidade necessária para atender à requisição. |
502 | Bad Gateway | Indica que o nosso servidor, enquanto atuava como gateway ou proxy, recebeu uma resposta inválida de um servidor de entrada acessado ao tentar atender à requisição. |
503 | Service Unavailable | Indica que o nosso servidor atualmente não consegue lidar com a solicitação devido a uma sobrecarga temporária ou manutenção programada, que provavelmente será aliviada após algum atraso. |
504 | Gateway Timeout | Indica que o nosso servidor, enquanto atuava como gateway ou proxy, não recebeu uma resposta oportuna de um servidor upstream que precisava acessar para concluir a solicitação. |
505 | HTTP Version Not Supported | Indica que o nosso servidor não oferece suporte ou se recusa a oferecer suporte à versão principal do HTTP usada na mensagem de solicitação. |
529 | Site is overloaded | Indica que o nosso servidor está sobrecarregado e não pode processar novas requisições. |
Por padrão, todos os retornos seguem a estrutura do exemplo abaixo:
{
"code": "ERRO_INTERNO",
"title": "Erro interno",
"detail": "Ocorreu um erro interno no sistema. Por favor, aguarde uns instantes e refaça a operação."
}
em que
code:
código único do erro. Verifique a lista de erros abaixo para ver como tratá-lo. | Obrigatório;title:
título do erro. | Obrigatório;detail:
mensagem explicativa sobre a ocorrência do erro. | Obrigatório.
Regras gerais de tratamento
Erros 50x
Recomendamos implementar uma estratégia de espera exponencial automatizada para até cinco novas tentativas.
Para otimizar os intervalos de espera, sugerimos usar um intervalo base de três segundos com um fator de duplicação. Isso resulta na seguinte programação de tentativas de repetição:
- Primeira tentativa: aguarde por três segundos;
- Segunda tentativa: aguarde por seis segundos (2 × 3);
- Terceira tentativa: aguarde por 12 segundos (2 × 6);
- Quarta tentativa: aguarde por 24 segundos (2 × 12);
- Quinta tentativa: aguarde por 48 segundos (2 × 24).
Essa estratégia ajuda a distribuir novas tentativas em intervalos de tempo cada vez maiores, reduzindo a probabilidade de sobrecarga do servidor e aumentando as chances de uma solicitação bem-sucedida em caso de falhas transitórias.
Erros 40x
Não tente reenviar a solicitação, pois isso indica um erro da sua aplicação ou parâmetros de requisição incorretos.
Exceção para o Erro "Too Many Sessions" (429):
Se o erro recebido for especificamente Too Many Sessions, isso indica que você está acessando a conta de outro navegador simultaneamente. Neste caso específico, você pode implementar a mesma política de repetição utilizada para erros da família 50x. Essa abordagem destaca uma resposta cautelosa a erros da sua aplicação, ao mesmo tempo que permite uma exceção específica ao encontrar o erro Too Many Sessions.
Possíveis causas e soluções
400 Cliente Inválido
{
code: "CLIENTE_INVALIDO",
title: "Cliente Inválido",
detail: "Não foi possível validar as informações do cliente autorizado."
}
Causa
Este erro ocorre quando a configuração da API está incorreta no devtools, ou quando o client no authorization server está configurado de forma errada.
Solução
- Verifique se as APIs elegíveis para a proteção via MTLS estão devidamente configuradas;
- Verifique que o ID do Software Statement ou ID da organização está correto no client do authorization server.
400 Assinatura Inválida
{
"code": "ASSINATURA_INVALIDA",
"title": "Assinatura Inválida",
"detail": "A assinatura da requisição JWT não é válida."
}
Causa
Este cenário de erro ocorre quando o certificado BRSEAL está inválido na configuração de certificados da plataforma ou vencido.
Solução
- Verifique se o certificado está corretamente configurado na plataforma Brick Bank;
- Verifique se o certificado está de acordo com a data de validade.
400 Dados inválidos
{
"code": "DADOS_INVALIDOS",
"title": "Dados Inválidos",
"detail": "The 'data.loggedUser.document.identification' field fails to match the required pattern."
}
Causa
Esse erro ocorre quando o CPF do usuário que consta no body request da requisição está contra os padrões de CPF.
Solução
- Visão ITP:
- Verifique se o parâmetro está sendo enviado corretamente no body request da requisição;
- Visão Detentor de Contas:
- Caso o ITP notifique a instituição sobre este erro, verifique se o parâmetro do consentimento está sendo enviado de acordo com os padrões de CPF e CNPJ (se houver).
400 CPF Inválido
{
code: "CPF_INVALIDO",
title: "CPF não está na lista de clientes",
detail: "O cliente não está na lista de clientes disponiveis para consentimento."
}
Causa
Esse erro ocorre em cenários onde há validações por parte do Transmissor de Dados ou Detentor de Contas para disponibilizar as funcionalidades para um cliente disponíveis na lista.
Solução
- ITP ou Receptor de Dados: identifique o
x-fapi-interaction-id
e abra um chamado no Service Desk do Open Finance Brasil para identificar a causa raiz o problema com a outra instituição. - Detentor de Contas ou Transmissor de Dados: verifique se o CPF do consentimento autorizado está disponível da lista de clientes da sua instituição.
400 Erro no fluxo DCR
{
code: "ERRO_FLUXO_DCR",
title: "Erro no fluxo de DCR",
detail: "Ocorreu um erro durante o fluxo de DCR"
}
Causa
Esse erro ocorre durante registro de DCR com outra instituição, a causa raiz pode ser por diversos motivos, entre eles: assinatura inválida, CA inválida, well-known fora do ar, URLs registradas no well-known incorretas, entre outras causas que devem ser analisadas detalhamente.
Solução
- ITP ou Receptor de Dados: identifique o
x-fapi-interaction-id
e abra um chamado no Service Desk do Open Finance Brasil para identificar a causa raiz o problema com a outra instituição. - Detentor de Contas ou Transmissor de Dados: busque no Kibana através do
x-fapi-interaction-id
ou no log da aplicação do Brick Bank ou Brick Insurance o erro indicado durante o fluxo de DCR para identificar a causa raiz e sua determinada correção.
400 Erro no fluxo DCM
{
code: "ERRO_FLUXO_DCM",
title: "Erro no fluxo de DCR",
detail: "Ocorreu um erro durante o fluxo de DCM"
}
Causa
Esse erro ocorre durante a atualização de DCR, a causa raiz pode ser por diversos motivos, entre eles: assinatura inválida, CA inválida, well-known fora do ar, URLs registradas no well-known incorretas, entre outras causas que devem ser analisadas detalhamente.
Solução
- ITP ou Receptor de Dados: identifique o
x-fapi-interaction-id
e abra um chamado no Service Desk do Open Finance Brasil para identificar a causa raiz o problema com a outra instituição. - Detentor de Contas ou Transmissor de Dados: busque no Kibana através do
x-fapi-interaction-id
ou no log da aplicação do Brick Bank ou Brick Insurance o erro indicado durante o fluxo de DCM para identificar a causa raiz e sua determinada correção.
400 Data de Expiração Inválida
{
"code": "DATA_DE_EXPIRACAO_INVALIDA",
"title": "Data de expiração do consentimento inválida",
"detail": "A data de expiração do consentimento não pode ser superior a 12 meses."
}
Causa
Esse erro ocorre no momento da solicitação de consentimento de dados, a data de expiração deve ser em até 12 meses.
Solução
Verifique se a data de expiração no payload do consentimento está com a data de validade de acordo com a regra.
400 Invalid Permissions PF and PJ
{
"code": "PERMISSAO_PF_PJ_EM_CONJUNTO",
"title": "Permissões PF e PJ em conjunto",
"detail": "Não é possível solicitar permissões PF e PJ em conjunto."
}
Causa
Esse erro ocorre exclusivamente para Receptores de Dados durante a solicitação de consentimento. Não é possível realizar a solicitação de consentimento com permissão de acesso a dados de PF e PJ em um único consentimento.
Solução
- Revise o conjunto de permissões definido no body request da solicitação e confira se há permissões de pessoa física e jurídica na mesma solicitação;
- Adicione uma validação no backend da instituição para distinguir os tipos de cliente e suas permissões que podem ser solicitadas para cada tipo.
400 Invalid Permissions
{
"code": "PERMISSOES_INVALIDAS",
"title": "Permissões inválidas",
"detail": "O conjunto de permissões solicitadas não é válido."
}
Causa
Esse erro ocorre exclusivamente para Receptores de Dados durante a solicitação de consentimento. Muitas vezes o conjunto de permissões para aquele consentimento pode estar contra a especificação do Open Finance Brasil.
Solução
Revise o conjunto de permissões definido no body request da solicitação e confira se está de acordo com a especificação da API do Open Finance Brasil.
400 Consentimento Inválido
{
"code": "CONSENTIMENTO_INVALIDO",
"title": "Consentimento inválido",
"detail": "O consentimento não é válido para realizar essa requisição."
}
Causa
Este erro ocorre quando uma chamada é realizada utilizando um consentimento inválido para a ação determinada.
Solução
- Acessar o monitoring do Brick Bank para verificar o log para identificar a causa raiz do problema;
- Consultar o consentimento e verificar o status:
- Se o status for AWAITING_AUTHORISATION, significa que o consentimento não foi autorizado;
- Se o status for REJECTED, significa que o consentimento está expirado ou foi rejeitado.
400 Erro Chamada API
{
code: "ERRO_CHAMADA_API",
title: "Erro na chamada da API",
detail: "Não foi possível chamar a API com sucesso na outra instituição."
}
Causa
Esse erro ocorre no momento em que instituição Receptora de Dados ou Iniciadora de Pagamentos realiza o consumo da API de outra instituição.
Solução
Espere alguns minutos e tente novamente. Se o erro persistir, solicite no Canal de Atendimento ou acesse o monitoring para verificar os logs para identificar o x-fapi-interaction-id
para abrir um chamado no Service Desk do Open Finance Brasil em contato com a outra instituição financeira.
400 Instância não encontrada
{
code: "INSTANCIA_NAO_ENCONTRADA",
title: "Instância não encontrada",
detail: "Não foi possível interpretar a instância da marca com base na requisição"
}
Causa
Esse erro ocorre em cenários de organizações com configuração para multimarcas, a principal causa raiz é configuração incorreta na plataforma.
Solução
Solicite auxílio para o nosso time de operações em nosso Canal de Atendimento para verificar as configurações das marcas da sua instituição.
400 Time Out
{
code: "TIMEOUT_CHAMADA_API",
title: "Timeout na chamada da API",
detail: "Não foi possível chamar a API com sucesso na outra instituição."
}
Causa
Esse erro ocorre no momento em que instituição Receptora de Dados ou Iniciadora de Pagamentos realiza o consumo da API de outra instituição, em que apresenta lentidão até dar time out.
Solução
Espere alguns minutos e tente novamente. Se o erro persistir, procure o Canal de Atendimento ou acesse o monitoring para verificar os logs para identificar o x-fapi-interaction-id
para abrir um chamado no Service Desk do Open Finance Brasil em contato com a outra instituição financeira.
400 Falha no fluxo Refresh Token
{
code: "FALHA_FLUXO_REFRESH_TOKEN",
title: "Falha no fluxo de refresh token",
detail: "Não foi possível realizar o fluxo de refresh token por erro na requisição para a outra instituição."
}
Causa
Esse erro ocorre exclusivamente no fluxo de consumo de dados, no momento em que o token de permissão é renovado na instituição transmissora de dados. Esse problema pode ocorrer devido ao envio de parâmetros incorretos na chamada.
Solução
Verifique se a requisição está enviando o token corretamente. Se o problema persistir, procure o Canal de Atendimento ou acesse o monitoring para verificar os logs para identificar o x-fapi-interaction-id
para abrir um chamado no Service Desk do Open Finance Brasil em contato com a instituição financeira transmissora.
400 Time out no fluxo Refresh Token
{
code: "TIMEOUT_FLUXO_REFRESH_TOKEN",
title: "Timeout no fluxo de refresh token",
detail: "Não foi possível realizar o fluxo de refresh token por erro de timeout para a outra instituição."
}
Causa
Esse erro ocorre exclusivamente no fluxo de consumo de dados, no momento em que o token de permissão é renovado na instituição transmissora de dados. Esse problema pode ocorrer devido ao envio de parâmetros incorretos na chamada.
Solução
- ITP ou Receptor de Dados: verifique se a requisição está enviando o parâmetro token corretamente. Se o problema persistir, procure o Canal de Atendimento ou acesse o monitoring para verificar os logs para identificar o
x-fapi-interaction-id
para abrir um chamado no Service Desk do Open Finance Brasil em contato com a instituição financeira transmissora.
401 Consentimento não autorizado
{
"code": "CONSENTIMENTO_NAO_AUTORIZADO",
"title": "Consentimento não autorizado",
"detail": "O consentimento não está autorizado a acessar este recurso."
}
Causa
O consentimento gerado não está autorizado para realizar a geração do pagamento ou transmissão de dados.
Solução
Consulte o consentimento através do consentId
e verifique o status do consentimento no histórico de eventos deste consentimento. Consentimentos com o status "AWAITING_AUTHOTISATION"
, "REJECTED"
ou "CONSUMED"
, não estão autorizados para realizar nenhum tipo de operação.
401 Token não fornecido
{
"error_description": "token not provided",
"error": "invalid_token"
}
Causa
Esse erro ocorre quando o token de segurança das APIs do Brick Bank e Insurance não está sendo enviado na requisição.
Solução
Verifique se o backend da sua instituição está realizando as etapas de requisições enviando o token de segurança no header das API's do Brick Bank e Insurance.
401 Consentimento Não Autorizado
{
"code": "CONSENTIMENTO_NAO_AUTORIZADO",
"title": "Consentimento não autorizado",
"detail": "O consentimento não está autorizado a acessar este recurso."
}
Causa
Esse cenário ocorre quando a instituição realiza uma requisição de consumo de dados para uma categoria não permitida pelo consentimento.
Solução
Verifique se o consentimento possui a categoria do dado consumido, caso não, desconsidere o consumo de dados para determinado tipo de dado.
401 Token não autorizado
{
code: "TOKEN_NAO_AUTORIZADO",
title: "Token não autorizado",
detail: "O token informado não é válido."
}
Causa
Esse erro ocorre em cenários em que o token informado no header da requisição está expirado ou inválido.
Solução
Verifique se o token foi gerado recentemente ou se o token enviado no header está correto.
401 Token Inativo
{
code: "TOKEN_INATIVO",
title: "Token inativo.",
detail: "O token informado não está ativo."
}
Causa
Esse erro ocorre quando o provedor de identidade não está configurado na plataforma Brick Bank e Insurance.
Solução
Solicite auxílio no Canal de Atendimento para identificar se o provedor de identidade está configurado corretamente na plataforma.
401 Instituição Não Encontrada
{
code: "INSTITUICAO_NAO_ENCONTRADA",
title: "Instituição não encontrada",
detail: "A instituição / marca solicitada não foi encontrada."
}
Causa
Esse erro ocorre no momento da solicitação de consentimento para outra instituição. A causa raiz é o envio do parâmetro "brandId"
incorreto no body request.
Solução
Verifique se o Id da marca que deseja solicitar o consentimento está correto e de acordo com o brandId
definido na lista de participantes do Diretório do Open Finance Brasil.
403 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
404 Not Found
{
"message": "no Route matched with those values"
}
Causa
Há duas possibilidades de causa raiz para este erro:
- O endpoint não está cadastrado na plataforma e no API Gateway;
- O path do endpoint acionado está incorreto.
Solução
- Verifique se o endpoint está cadastrado na plataforma acessando o devtools ou runtime;
- Caso o endpoint desejado não esteja cadastrado, realize o deploy da API no ambiente desejado;
- Caso o endpoint esteja cadastrado, verifique se a variável de ambiente está correta, em seguida, realize o redeploy da API no ambiente desejado;
- Verifique se o endpoint acionado está digitado corretamente em seu backend ou ferramenta de testes.
404 Interação não encontrada
{
"code": "INTERACAO_NAO_ENCONTRADA",
"title": "Interação não encontrada.",
"detail": "Interação não encontrada."
}
Causa
Esse erro é comum para Transmissores de Dados ou Detentores de Contas integrados ao Brick Bank. A causa deste erro é o interactionId
é inexistente ou incorreto.
Solução
Verifique se o backend da sua instituição está captando o interactionId
enviado da URL de redirecionamento corretamente. Faça uma comparação entre o interactionId
gerado pela plataforma e o interactionId
definido na chamada do endpoint.
404 Link Não Encontrado
{
code: "LINK_NAO_ENCONTRADO",
title: "Link não encontrado",
detail: "Não foi possível encontrar o link da API no authorization server."
}
Causa
Esse erro ocorre durante a solicitação de consentimento, quando não há registros da API requisitada no diretório do Open Finance Brasil.
Solução
- ITP ou Receptor de Dados: identifique o
x-fapi-interaction-id
e abra um chamado no Service Desk do Open Finance Brasil para questionar a instituição sobre a disponibilidade do endpoint no Diretório Central. - Detentor de Contas ou Transmissor de Dados: verifique se a API requisitada está devidamente registrada no recursos da API no Diretório Central.
404 Refresh Token não encontrado
{
code: "REFRESH_TOKEN_NAO_ENCONTRADO",
title: "Refresh token não encontrado",
detail: "O refresh token associado ao consentimento não foi encontrado."
}
Causa
Esse erro ocorre em cenários em que o Receptor de Dados solicita a renovação do access_token de acesso aos endpoints e a Transmissora de Dados não localiza os dados de refresh token em sua base.
Solução
Identifique o x-fapi-interaction-id
e abra um chamado no Service Desk do Open Finance Brasil para questionar a instituição transmissora sobre o erro durante a atualização do refresh token.
404 State não encontrado
{
code: "STATE_NAO_ENCONTRADO",
title: "State não encontrado",
detail: "O state solicitado não foi encontrado."
}
Causa
Esse erro ocorre em cenários onde o ITP ou Receptor de Dados não envia o parâmetro "state"
durante a requisição de callback.
Solução
- ITP ou Receptor de Dados: verifique se o body request da requisição de callback está preenchido corretamente com o parâmetro
"state"
.
404 Consentimento Não Encontrado
{
"code": "CONSENTIMENTO_NAO_ENCONTRADO",
"title": "Consentimento não encontrado",
"detail": "O consentimento solicitado não foi encontrado."
}
Causa
Este erro ocorre em momentos de consulta de consentimento no Brick Bank, seja como receptor de dados/iniciador de pagamentos ou transmissor de dados/detentor de contas. A causa é a não existência do consentimento enviado na requisição.
Solução
- Verifique se o ID do consentimento está sendo enviado corretamente dentro dos padrões do Open Finance Brasil;
- Verifique se o ID do consentimento está correto;
- Se o ID do consentimento estiver correto, consulte a Central de Atendimento para verificar a causa raiz do problema.
406 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
407 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
408 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
409 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
410 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
411 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
412 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
413 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
414 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
415 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
416 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
417 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
422 Data de pagamento inválida
{
"code": "DATA_PAGAMENTO_INVALIDA",
"title": "Data de pagamento inválida.",
"detail": "Data de pagamento inválida para a forma de pagamento selecionada."
}
Causa
A data do pagamento no payload da iniciação de pagamentos está incorreta para o tipo de pagamento. Exemplo:
- Pix Instantâneo: a data do pagamento pode estar definida para um dia antes ou um dia depois do dia da iniciação do pagamento;
- Pix Agendado: a data do pagamento pode estar definida para um dia antes ou para o dia da iniciação de pagamento.
Solução
- ITP: verifique se a data do pagamento no body request da solicitação de consentimento está definida de forma correta para o tipo de Pix selecionado na iniciação de pagamentos.
422 Pagamento Divergente do Consentimento
{
"code": "PAGAMENTO_DIVERGENTE_CONSENTIMENTO",
"title": "Divergência entre pagamento e consentimento.",
"detail": "Dados do pagamento divergentes dos dados do consentimento."
}
Causa
Esse erro ocorre em cenários em que o valor do pagamento determinado no body request está divergente do valor do pagamento definido no consentimento anteriormente.
Solução
- ITP: verifique se o valor do pagamento está idêntico ao valor do pagamento no consentimento;
- Detentor de Contas: caso um ITP reporte esse problema, oriente para verificar se o valor do pagamento está idêntico ao valor do pagamento definido no consentimento.
422 Não Informado
{
"code": "NAO_INFORMADO",
"title": "Não informado.",
"detail": "Não reportado/identificado pela instituição detentora de conta."
}
Causa
Esse erro ocorre em cenários de geração do pagamento, onde o valor do cnpjInitiator
no body request da iniciação do pagamento está inválido.
Solução
- ITP: verifique se o campo
cnpjInitiator
está preenchido com o valor do CNPJ do ITP corretamente.
422 Detalhe Pagamento Inválido
{
"code": "DETALHE_PAGAMENTO_INVALIDO",
"title": "Detalhe do pagamento inválido.",
"detail": "Detalhe do pagamento inválido."
}
Causa
Esse erro pode ocorrer em cenários durante a geração do pagamento, em que um ou mais parâmetros em relação ao detalhe do pagamento estão sendo preenchidos incorretamente no body request.
Solução
- ITP: verifique se os valores em cada parâmetro determinado no body request está de acordo com a especificação do Brick Bank ou Brick Insurance.
422 Depende de múltipla alçada
{
code: "CONSENTIMENTO_PENDENTE_AUTORIZACAO",
title: "Consentimento pendente autorização de múltiplas alçadas (status “PARTIALLY_ACCEPTED”).",
detail: "Consentimento pendente autorização de múltiplas alçadas (status “PARTIALLY_ACCEPTED”)."
}
Causa
Esse erro ocorre em cenários de consentimentos de pagamentos com múltipla alçada, onde o ITP realiza uma chamada no endpoint para a geração do consentimento e o status do consentimento consta como PARTIALLY_ACCEPTED
, ou seja, os demais titulares da conta corrente não aprovaram o consentimento.
Solução
- ITP: verifique se o status do consentimento consta como
PARTIALLY_ACCEPTED
. Se sim, é necessário aguardar a aprovação de todos os titulares da conta.
Caso o consentimento esteja com o status AUTHORISED
, identique o x-fapi-interaction-id
e abra um chamado no Service Desk para a instituição portadora do consentimento criado para que verifique a causa raiz do erro retornado.
- Detentor de Contas: verifique se o status do consentimento consta como
PARTIALLY_ACCEPTED
. Se sim, é necessário notificar a necessidade da aprovação de todos os titulares da conta.
422 Limite do período do valor excedido
{
code: "LIMITE_PERIODO_VALOR_EXCEDIDO",
title: "A transação não pode ser realizada pois o valor parametrizado no consentimento foi excedido.",
detail: "A transação não pode ser realizada pois o valor parametrizado no consentimento foi excedido."
}
Causa
Esse erro ocorre apenas na API de Pagamentos Automáticos, em cenários onde o limite de valor de transferência em determinado período definido pelo usuário no consentimento foi excedido pelo ITP.
Solução
- ITP: verifique se o backend da sua instituição está seguindo a regra definida através do consentimento.
- Se as regras estão sendo seguidas de acordo com o consentimento, identique o
x-fapi-interaction-id
e abra um chamado no Service Desk para a instituição portadora do consentimento criado para que verifique a causa raiz do erro retornado.
- Se as regras estão sendo seguidas de acordo com o consentimento, identique o
422 Limite do período da quantidade excedida
{
code: "LIMITE_PERIODO_QUANTIDADE_EXCEDIDO",
title: "A transação não pode ser realizada pois a quantidade parametrizada no consentimento foi excedida.",
detail: "A transação não pode ser realizada pois a quantidade parametrizada no consentimento foi excedida."
}
Causa
Esse erro ocorre apenas na API de Pagamentos Automáticos, em cenários onde a quantidade de geração de pagamentos em determinado período definida pelo usuário no consentimento foi excedido pelo ITP.
Solução
- ITP: verifique se o backend da sua instituição está seguindo a regra definida através do consentimento.
- Se as regras estão sendo seguidas de acordo com o consentimento, identique o
x-fapi-interaction-id
e abra um chamado no Service Desk para a instituição portadora do consentimento criado para que verifique a causa raiz do erro retornado.
- Se as regras estão sendo seguidas de acordo com o consentimento, identique o
422 Consentimento Rejeitado
{
code: "CONSENTIMENTO_EM_STATUS_REJEITADO",
title: "Consentimento em status rejeitado",
detail: "O consentimento está em estado de rejeitado."
}
Causa
Esse tipo de erro ocorre em cenários onde o ITP ou Receptor de Dados pode ter executado uma ação de consumo de APIS, no qual o consentimento consta como status "REJECTED"
.
Solução
- ITP ou Receptor de Dados: verifique se o status do consentimento consta como
"REJECTED"
. Se sim, desconsidere o consumo de dados do consentimento em questão. Caso contrário, abra um chamado no [Service Desk do Open Finance Brasil](ITP ou Receptor de Dados) para questionar a instituição transmissora. - Detentor de Contas ou Transmissor de Dados: verifique se o status do consentimento consta como
"REJECTED"
. Se sim, solicite ao ITP ou Receptor de Dados para que não consuma dados do consentimento em questão. Caso contrário, solicite auxílio no nosso Canal de Atendimento para analisar o motivo o erro retornado.
422 Pagamento não permite cancelamento
{
code: "PAGAMENTO_NAO_PERMITE_CANCELAMENTO",
title: "Pagamento não permite cancelamento",
detail: "Pagamento não permite cancelamento"
}
Causa
Esse erro ocorre em cenários de pagamentos que não permitem cancelamentos, como pagamento Pix instanâneo.
Solução
O cancelamento do pagamento é permitido somente nos seguintes cenários:
- Pix agendado;
- Pix com agendamento recorrente;
- Pix automático.
Portanto, não é permitido o cancelamento de pagamentos de Pix instantâneo.
422 Data de Expiração Inválida
{
code: "DATA_EXPIRACAO_INVALIDA",
title: "Data de expiração do consentimento inválida",
detail: "A data de expiração do consentimento não pode ser superior a 12 meses."
}
Causa
Esse erro ocorre durante a solicitação de consentimento, onde a instituição Receptora de Dados pode estar determinando o expirationDateTime
com um valor superior a 12 meses.
Solução
- Receptor de Dados: verifique se
expirationDateTime
está sendo enviado com a data de expiração de acordo com a especificação técnica do Brick Bank.
422 Depende Múltipla Alçada
{
code: "DEPENDE_MULTIPLA_ALCADA",
title: "Consentimento contem múltiplas alçadas",
detail: "O consentimento foi criado demandando aprovações por múltiplas alçadas."
}
Causa
Esse erro ocorre em cenários de consentimentos de pagamentos com múltipla alçada, onde o ITP realiza uma chamada no endpoint para a geração do consentimento e o status do consentimento consta como PARTIALLY_ACCEPTED
, ou seja, os demais titulares da conta corrente não aprovou o consentimento.
Solução
- ITP: verifique se o status do consentimento consta como
PARTIALLY_ACCEPTED
. Se sim, é necessário aguardar a aprovação de todos os titulares da conta.
Caso o consentimento esteja com o status AUTHORISED
, identique o x-fapi-interaction-id
e abra um chamado no Service Desk para a instituição portadora do consentimento criado para que verifique a causa raiz do erro retornado.
- Detentor de Contas: verifique se o status do consentimento consta como
PARTIALLY_ACCEPTED
. Se sim, é necessário notificar a necessidade da aprovação de todos os titulares da conta.
422 Data Inválida
{
code: "DATA_INVALIDA",
title: "Data invalida do consentimento",
detail: "O consentimento não pode ser criado nessa data."
}
Causa
Esse erro ocorre durante a solicitação de consentimento, onde a instituição Receptora de Dados pode estar determinando o "expirationDateTime"
com um valor superior a 12 meses.
Solução
- Receptor de Dados: verifique se
"expirationDateTime"
está sendo enviado com a data de expiração de acordo com a especificação técnica do Brick Bank.
422 Erro Idempotência
{
code: "ERRO_IDEMPOTENCIA",
title: "Erro idempotência.",
detail: "Erro idempotência."
}
Causa
Esse erro ocorre em cenários de geração de pagamentos através do ITP, em que o parâmetro x-idempotency-key
pode estar sendo enviado incorretamente.
Solução
ITP: verifique no backend da sua instituição se o parâmetro x-idempotency-key
está sendo captado corretamente através do envio pela Detentora de Contas. Se sim, identique o x-fapi-interaction-id
e abra um chamado no Service Desk para a instituição Detentora de Contas identificar a causa raiz do problema.
422 Operação Não Permitida
{
code: "OPERACAO_NAO_PERMITIDA_STATUS",
title: "Operação não permitida.",
detail: "Operação não permitida devido ao status atual do consentimento."
}
Causa
Esse erro pode ocorrer em cenários durante o fluxo de consumo de dados ou de pagamentos, em que o status do consentimento está diferente de authorised
.
Solução
- ITP ou receptora de dados: consulte se o status do consentimento em questão está diferente de
authorised
. Caso contrário, identique ox-fapi-interaction-id
e abra um chamado no Service Desk para a instituição portadora do consentimento criado para que verifique a causa raiz do erro retornado.
422 Parâmetro Não Informado
{
code: "PARAMETRO_NAO_INFORMADO",
title: "Parâmetro obrigatório não informado",
detail: "Parâmetro obrigatório não informado"
}
Causa
Esse erro pode ocorrer em cenários durante a geração do consentimento e durante a geração do pagamento, em que um ou mais parâmetros obrigatórios não estão sendo enviados no body request.
Solução
- ITP ou Receptor de Dados: verifique se os valores em cada parâmetro determinado no body request está de acordo com a especificação do Brick Bank ou Brick Insurance.
422 Parâmetro Inválido
{
code: "PARAMETRO_INVALIDO",
title: "Parâmetro com valor inválido",
detail: "Parâmetro com valor inválido
}
Causa
Esse erro pode ocorrer em cenários durante a geração do consentimento e durante a geração do pagamento, em que um ou mais parâmetros estão sendo preenchidos incorretamente no body request.
Solução
- ITP ou Receptor de Dados: verifique se os valores em cada parâmetro determinado no body request está de acordo com a especificação do Brick Bank ou Brick Insurance.
422 QRCode Inválido
{
code: "VALOR_INVALIDO",
title: "Valor inválido.",
detail: "O valor enviado não é válido para o QR Code informado."
}
Causa
Esse erro ocorre durante a validação do pagamento através da instituição detentora de contas, em cenários onde o valor determinado no QRCode não condiz com o valor determinado no "amount"
do consentimento.
Solução
- ITP: verifique se o seu backend está enviando os dados de pagamentos corretamente de acordo com a especificação do Brick Bank.
423 Locked
{
code: "LIMITE_OPERACIONAL_EXCEDIDO",
title: "Limite Operacional Excedido.",
detail: "Limite Operacional Excedido."
}
Causa
Os limites operacionais fazem parte dos requisitos não funcionais da especificação do Open Finance Brasil. Esses limites são controlados de forma mensal, por endpoint e por cliente através da plataforma Brick Bank. A aplicação desses limites são para todas as APIs de Dados Cadastrais, Transacionais, Consentimento e Recursos.
Solução
- Receptor de Dados: aguarde o próximo período de contagem dos limites operacionais para que a sua instituição possa retornar o consumo de dados de determinada instituição.
426 [ERROR] (Em breve)
{
"code": "",
"title": "",
"detail": ""
}
Causa
Solução
500 Internal Server Error
{
code: "ERRO_NO_FLUXO_OIDC",
title: "Erro no fluxo OIDC",
detail: "Ocorreu um erro no fluxo do OIDC. Por favor, aguarde uns instantes e refaça a operação."
}
Causa
Esse problema pode ocorrer em cenários de solicitação de consentimento com outra instituição, durante o momento de verificações de clients antes do consentimento ser efetivamente gerado.
Solução
- ITP ou Receptor de Dados: identifique o
x-fapi-interaction-id
e abra um chamado no Service Desk do Open Finance Brasil para identificar a causa raiz o problema com a outra instituição. - Detentor de Contas ou Transmissor de Dados: busque no Kibana através do
x-fapi-interaction-id
ou no log da aplicação do Brick Bank ou Brick Insurance o erro indicado durante o fluxo de DCR para identificar a causa raiz e sua determinada correção.
Updated 4 months ago