Fase 3 – Tratativa de erros de validação do QR Code em cenários assíncronos

Fase 3 – Tratativa de erros de validação do QR Code em cenários assíncronos

Para a API Fase 3, detalha-se a seguir o comportamento da validação do QR Code:

Consulta ao QR Code realizada pela detentora é obrigatória quando o localInstrument for igual a QRDN ou QRES. No entanto, ela possui flexibilidade para escolher em que momento a consulta ou validação deverá ser executada:

API DE POST/CONSENTS pode ter a consulta do QR Code

Caso a detentora opte por essa validação, esta deve ser síncrona.

Síncrono: retorno erro HTTP 422, código retornado DETALHE_PGTO_INVALIDO.

API DE POST/PAYMENTS pode ter a consulta do QR Code

Síncrono: retorno erro HTTP 422, código retornado COBRANCA_INVALIDA.

Assíncrono: retorno erro HTTP 201, com status de pagamento PDNG ou PART.

API DE GET/CONSENTS deve prever o erro de validação

Não será previsto retorno (específico para QR Code inválido).

API DE GET/PAYMENTS deve prever o erro de validação

Retorno erro HTTP 200, status REJECTED:

ELEMENT_CONTENT_FORMALLY_INCORRECT - Elemento da mensagem incorreto (CH16).

Comportamento do motor de teste:

Tempo de pooling 30 segundos com tempo máximo de 5 minutos

Além disso, será incluído em 29/11 na planilha de problemas conhecidos Fase 3 o seguinte ponto:

API/Sessão: API Payments / Schema EnumRejectionReasonType

Endpoint: GET /payments/v1/pix/payments/{paymentId}

Campo: rejectionReason

Qual o problema: Não está prevista uma opção específica no domínio de razões de rejeição para o cenário de validação de forma assíncrona da chave no QR Code quando os dados da conta do destinatário enviadas pela iniciadora não corresponderem aos dados da chave pix consultada no QR Code ou chave pix inválida

Como deveria ser: Deveria estar definida uma opção específica no domínio de Razões de Rejeição (EnumRejectionReasonType) para essa situação

Orientação: Utilizar a opção ELEMENT_CONTENT_FORMALLY_INCORRECT para a situação do problema, na validação de forma assíncrona