ESTE É UM CONTEÚDO EM DESENVOLVIMENTO E NÃO DEVE SER CONSIDERADO COMO VERSÃO FINAL!
Clique aqui para maiores informações

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

 

 

ESTE É UM CONTEÚDO EM DESENVOLVIMENTO E NÃO DEVE SER CONSIDERADO COMO VERSÃO FINAL!
Clique aqui para maiores informações