Apresentamos neste item orientações para problemas conhecidos da fase 3 do Open Finance Brasil.
Disponibilizamos a lista de problemas conhecidos das especificações da API da Fase 3 na versão 2.0.0, contendo orientações às instituições participantes até que se publiquem as correções.
Esta página poderá ser atualizada conforme novos itens sejam identificados.
Eventuais atualizações serão também comunicadas através dos Informes do Open Finance Brasil.
ID | Solucionado | Crítico | API / Sessão | Endpoint | Campo | Como está? Qual o problema? | Como deveria ser? | Orientação até publicação do ajuste | Comentário |
|---|---|---|---|---|---|---|---|---|---|
BCLOG-F03-V2-001 | Não | API Payments | POST /consents | /errors/code | Foi identificado um erro de digitação nas especificações da v2.0.0 da API de Iniciação de Pagamentos, no qual a orientação é utilizar o ENUM DETALHE_PGTO_INVALIDO, quando deveriamos ter a palavra PAGAMENTO por extenso (DETALHE_PAGAMENTO_INVALIDO) | Deveria ser utilizado DETALHE_PAGAMENTO_INVALIDO ao invés de DETALHE_PGTO_INVALIDO no ENUM da resposta do 422 | Utilizar o ENUM DETALHE_PAGAMENTO_INVALIDO | - | |
BCLOG-F03-V2-002 | API | Todos | Problema na descrição do código de erro 400 e 422 que não estão aderentes as especificações da API de Pagamentos | As descrições deveriam | Seguir o conteúdo do header da API | ||||
BCLOG-F03-V2-003 | API Payments | Todos | x-fapi-interaction-ID | Na documentação de segurança, o x-fapi-interaction-ID não precisa ser gerado pelo consumidor do serviço, o que pode gerar inconsistências na Plataforma de Coleta de Métricas (PCM) na ocorrência de erros de integração entre consumidor e provedor | Alterar a especificação de forma a tornar obrigatório o campo x-fapi-interaction-ID, no header da requisição http, para envio pela Instituição iniciadora de transação de pagamento (ITP) | Informar cabeçalho x-fapi-interaction-id obrigatoriamente na requisição | |||
BCLOG-F03-V2-004 | API Payments | PATCH/pix/payments/ {paymentId} | code, title e detail | Está sendo orientado no Swagger a utilização dos códigos de erro do endpoint de criação de iniciação de pagamento quando deveria ser orientado a utilização de código relativo ao endpoint de cancelamento | code: PAGAMENTO_NAO_PERMITE_CANCELAMENTO title: Pagamento não permite cancelamento detail: Pagamento não permite cancelamento | Utilizar os campos conforme abaixo: code: PAGAMENTO_NAO_PERMITE_CANCELAMENTO title: Pagamento não permite cancelamento detail: Pagamento não permite cancelamento | |||
BCLOG-F03-V2-005 | API Payments | Todos | iss | Nas orientações do header da API sobre validações, os itens 1.2.4.1 e 2.1.4.1 estão orientando erros durante a validação do iss retornem o código HTTP 400, porém nas demais orientações de segurança, por exemplo, como assinar o payload, as orientações são de que o código que deve ser utilizado é o 403 | O código de erro a ser retornado nessas validações deve ser o HTTP 403 | Retornar o código HTTP 403 | |||
BCLOG-F03-V2-006 | API Payments | PATCH/pix /payments /{paymentId} | - | Existem contas cujas regras derivadas do contrato social exigem que o cancelamento de um pagamento agendado seja manifestado por mais de um autorizador, porém a versão 2 da API de Iniciação de Pagamentos não contempla funcionalidade que permita a manifestação de mais de um autorizador | O endpoint de cancelamento de um pagamento agendado precisaria permitir a manifestação por mais de uma pessoa com poderes para cancelar a transação, ou uma alternativa que adeque a IF durante o cancelamento de múltipla alçada sem ferir seus princípios jurídicos | Para estes casos retornar o código de erro 422: code: PAGAMENTO_NAO_PERMITE_CANCELAMENTO title: Pagamento não permite cancelamento detail: O cancelamento desta transação requer mais de um autorizador e poderá ser realizado direto na detentora de conta |