v2.0.0 – Problemas conhecidos

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

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	Sim	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	Sim		API Payments	Todos	Não se aplica	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 erro 400: A requisição foi malformada, omitindo atributos obrigatórios, seja no payload ou através de atributos na URL erro 422: A solicitação foi bem formada, mas não pôde ser processada devido à lógica de negócios específica da solicitação	As descrições deveriam explicitar as regras conforme as regras de validações descritas no header da API	Seguir o conteúdo do header da API
BCLOG-F03-V2-003	Sim		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	Sim		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	Sim		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}	Não se aplica	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
BCLOG-F03-V2-007	Sim		API Payments	GET/consents POST/consents	/data/creditor/name	O pattern do referido campo foi padronizado conforme a especificação do campo equivalente no arranjo do Pix, porém no arranjo do Pix existem dois campos para informar o nome do credor, um para pessoa natural e outro para pessoa jurídica sendo que no arranjo do Pix o de pessoa jurídica é mais abrangente em relação aos caracteres aceitos e quando foi construída essa versão da API foi adotado o pattern mais restritivo de pessoa natural, isto está impedindo que o crédito seja realizado para empresas que possuam alguns tipos de caracteres em seu nome	Deve ser adotado o pattern mais abrangente de pessoa jurídica	Adotar o pattern de pessoa jurídica: ^([A-Za-zÀ-ÖØ-öø-ÿ,.@:&*+_<>()!?/\\$%\d' -]+)$
BCLOG-F03-V2-008	Sim		API Payments	PATCH/pix/ payments/ {paymentId}	Não se aplica	Na descrição do endpoint PATCH/pix/payments/{paymentId} está faltando um complemento com relação à data de cancelamento de pagamentos agendados. Atualmente, a descrição é a seguinte: “O cancelamento de pagamento deve ser enviado até 23:59 (Horário de Brasília) do dia anterior à data de efetivação do pagamento”	O cancelamento de pagamento agendado (SCHD) pode ser enviado até 23:59 (Horário de Brasília) do dia anterior à data de efetivação do pagamento	O cancelamento de pagamento agendado (SCHD) pode ser enviado até 23:59 (Horário de Brasília) do dia anterior à data de efetivação do pagamento
BCLOG-FO3-V2-009	Sim		API Payments	GET/pix /payments /{paymentId}	Security profile	security: OAuth2AuthorizationCode: openid payments OAuth2ClientCredentials: payments	security: OAuth2ClientCredentials: payments	Garantir que a API seja acessível apenas a estrutura de segurança: security: OAuth2ClientCredentials: payments A exclusão do modelo de segurança terá testes funcionais, a serem publicados por Sandbox e com orientação das datas de execução pelas instituições publicada em um informe
BCLOG-F03-V02-010	Sim		API Payments	PATCH/pix /payments /{paymentId}	Security profile	Os testes de autenticação para o endpoint PATCH de cancelamento de uma iniciação de pagamento foram implementados via authorization code, porém na especificação está definido para utilizar client credentials	Utilizar apenas client credentials	Serão aceitos client credentials e authorization code para não haver uma quebra abrupta Testes serão criados para o fluxo via client credentials para certificar as detentoras de conta que estão aderentes à especificação e será realizado um informa para aviso as iniciadoras com as orientações necessárias