Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

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

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}

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

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

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

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