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 codeResumoDescrição
200OKA requisição foi bem sucedida.
201CreatedA requisição foi atendida e resultou na criação de um ou mais novos recursos.
202AcceptedA requisição foi aceita para processamento, mas este não foi concluído
203Non-Authoritative InformationA 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.
204No ContentO servidor atendeu a requisição com êxito e não há conteúdo adicional para enviar no payload da resposta.
205Reset ContentO 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.
206Partial ContentO 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.
300Multiple ChoicesO 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.
301Moved PermanentlyO 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.
302FoundO 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.
303See OtherIndica 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.
304Not ModifiedIndica 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.
307Temporary RedirectIndica 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.
400Bad RequestIndica 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).
401UnauthorizedIndica que a requisição não foi aplicada porque não possui credenciais de autenticação válidas para o recurso de destino.
403ForbiddenIndica que o nosso servidor entendeu a requisição, mas se recusou a autorizá-la.
404Not FoundIndica 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.
405Method Not AllowedIndica que o método recebido na linha da requisição é conhecido pelo servidor de origem, mas não é suportado pelo recurso de destino.
406Not AcceptableIndica 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.
407Proxy Authentication RequiredIndica 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.
408Request TimeoutIndica que o nosso servidor não recebeu uma mensagem de requisição completa dentro do tempo que estava preparado para esperar.
409ConflictIndica que a requisição não pôde ser concluída devido a um conflito com o estado atual do recurso de destino.
410GoneIndica que o acesso ao recurso alvo não está mais disponível no servidor de origem e que esta condição provavelmente será permanente.
411Length RequiredIndica que o nosso servidor se recusa a aceitar a requisição sem um Content-Length definido.
412Precondition FailedIndica que uma ou mais condições fornecidas nos campos do cabeçalho da requisição foram avaliadas como falsas quando testadas no nosso servidor.
413Payload Too LargeIndica 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.
414URI Too LongIndica 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.
415Unsupported Media TypeIndica 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.
416Range Not SatisfiableIndica 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.
417Expectation FailedIndica 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.
423LockedO recurso está bloqueado, indicando que a solicitação não pode ser concluída devido a um estado de bloqueio existente no recurso.
426Upgrade RequiredIndica 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.
429Too Many RequestsIndica 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.
500Internal Server ErrorIndica que o nosso servidor encontrou uma condição inesperada que o impediu de atender à solicitação.
501Not ImplementedIndica que o nosso servidor não oferece suporte à funcionalidade necessária para atender à requisição.
502Bad GatewayIndica 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.
503Service UnavailableIndica 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.
504Gateway TimeoutIndica 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.
505HTTP Version Not SupportedIndica 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.
529Site is overloadedIndica 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

  1. Verifique se as APIs elegíveis para a proteção via MTLS estão devidamente configuradas;
  2. 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

  1. Verifique se o certificado está corretamente configurado na plataforma Brick Bank;
  2. 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

  1. Visão ITP:
    1. Verifique se o parâmetro está sendo enviado corretamente no body request da requisição;
  2. Visão Detentor de Contas:
    1. 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

  1. 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;
  2. 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

  1. Acessar o monitoring do Brick Bank para verificar o log para identificar a causa raiz do problema;
  2. Consultar o consentimento e verificar o status:
    1. Se o status for AWAITING_AUTHORISATION, significa que o consentimento não foi autorizado;
    2. 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:

  1. O endpoint não está cadastrado na plataforma e no API Gateway;
  2. O path do endpoint acionado está incorreto.

Solução

  1. Verifique se o endpoint está cadastrado na plataforma acessando o devtools ou runtime;
    1. Caso o endpoint desejado não esteja cadastrado, realize o deploy da API no ambiente desejado;
    2. Caso o endpoint esteja cadastrado, verifique se a variável de ambiente está correta, em seguida, realize o redeploy da API no ambiente desejado;
  2. 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 interactionIddefinido 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.

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.

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 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.

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.