...
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 | 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 | As descrições deveriam | 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 | /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/ | 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:
| security:
| Garantir que a API seja acessível apenas a estrutura de segurança:
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 | ||
| Sim |
|
|
|
|
|
|
...