Abertura da certificação da API Payments v2.0.0Fase 3 – Atualização da lista de problemas conhecidos

Abertura da certificação da API Payments v2.0.0

Comunicamos que as certificações da API de Pagamentos v2.0.0 (fase 3) estão abertas para submissão de pedidos.

Os pedidos devem ser submetidos até o dia 01/02/2023. Não há garantias de que pedidos de certificações submetidos após essa data serão processados antes da data do go live, em 15/02/2023. Como os módulos de testes sofreram atualizações recentes, recomendamos que as instituições criem um novo plano de testes e re-executem os módulos assim que possível, para checar se continuam obtendo sucesso nos módulos já concluídos.

Para a submissão, é necessário realizar um novo plano de testes na versão 5.0.8 build: b904a266 ou superior, executado a partir de 23/01/2023.

Pacote de submissão

Todas as instituições devem submeter um único log dos testes.

Para instituições que não possuem temporização nem múltiplas alçadas, o log deve ter sucesso em todos os testes obrigatórios;

Para instituições que possuem temporização e/ou múltiplas alçadas, o log deverá ter sucesso em todos os testes obrigatórios e os respectivos condicionais.

Submissão e processamento da certificação

Os pedidos de certificações deverão ser realizados pelo Service Desk na categoria “Enviar pedido de certificação”, cujo formulário foi atualizado para solicitar:

Informações da certificação;

Informações do contato técnico que está submetendo o pedido de certificação;

Informações do representante legal que assinará o termo “Certificado de Conformidade Funcional”;

Logs das execuções (versão mínima do plano de testes: 5.0.8 build: b904a266);

Observação: não será necessário anexar o termo “Certificado de Conformidade Funcional” assinado.

Após o processamento da certificação, a estrutura enviará por Docusign o termo “Certificado de Conformidade Funcional” para validação do contato técnico e assinatura do representante legal, ambos indicados no formulário.

Concluído o processo de assinatura, o ticket será encerrado e a tabela de certificação funcional será atualizada.

Maiores informações sobre o novo processo de submissão estão disponíveis no Guia de submissão de certificação.

Publicação das APIs de Pagamentos v2.0.0

A publicação da versão 2.0.0 da API de Pagamentos no Diretório de Participantes só poderá ser realizada se a instituição estiver de posse das certificações funcional e de segurança. Orientações para novos entrantes estão disponíveis no Informa #303 (“Orientação de quais versões os novos participantes devem implementar”, enviado em 18/01/2023).

Dúvidas

Para dúvidas, favor abrir um ticket no service desk na categoria: Solicitação de informação > Conformidade > Motor de conformidade.

Clique aqui para acessar o Motor de conformidade

Clique aqui para acessar o Service Desk

Clique aqui para acessar o Guia de certificação

Clique aqui para acessar o Guia de submissão de certificação

Clique aqui para acessar o Informa #303

Fase 3 – Atualização da lista de problemas conhecidos

O Grupo Técnico de Especificações Serviços comunica que foram adicionados dois itens à lista de problemas conhecidos da fase 3, conforme segue:

BCLOG-F03-V02-005

API/Sessão: API Payments

Endpoints: Todos

Campo: iss

Qual o problema: Nas orientações do header da API sobre validações, os itens 1.2.4.1 e 2.1.4.1 estão orientando que erros durante a validação do iss retornem o código HTTP 400. Contudo, 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

Como deveria ser: O código de erro a ser retornado nessas validações deve ser o HTTP 403

Orientação: Retornar o código HTTP 403

BCLOG-F03-V02-006

API/Sessão: API Payments

Endpoint: PATCH/pix/payments/{paymentId}

Campo: -

Qual o problema: 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

Como deveria ser: 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 instituição durante o cancelamento de múltipla alçada sem ferir seus princípios jurídicos

Orientação: 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