Dúvida - Validação cobv

[b-alencar]

@ninrod na issue 199 foi levantada uma questão que ainda me gera dúvidas. Pegando o texto em que você responde e gostaria de explana-la abaix.

Olá @monise , estruturei a resposta para você:

3 - Se o item 2 for verdadeiro, como que o PSP recebedor vai saber qual código do município e data pretendida o pagador passou ao ler o QR code e iniciar o pagamento?

Em primeiro lugar, precisamos entender que o PSP do pagador efetivamente recebe o valor já calculado do PSP recebedor, no contexto da cobrança com vencimento. Portanto, entendo que está se falando aqui de um zelo, por parte do PSP recebedor, considerando o caso de exceção em que o PSP pagador altera (deliberadamente, ou por erro) o valor da cobrança apresentado e calculado pelo PSP recebedor removendo apenas a parte do valor ligado ao "código do município"; entendo que a "data de pagamento pretendida", no contexto da pacs.008, torna-se a data de pagamento "de fato" que consta na data de recebimento da pacs.008, então quanto à DPP, não há problemas em relação à concilicação: o PSP do recebedor tem todas as condições de inclusive re-calcular o valor da cobrança considerando a data de pagamento da pacs.008.

Em outras palavras, para ficar bem claro, é obrigação do PSP pagador acatar o valor retornado no Payload JSON que representa a cobrança, conforme calculado, gerado e assinado pelo PSP recebedor. Estamos falando aqui sobre um cenário de exceção em que o PSP pagador não acata o valor retornado, por erro, ou deliberadamente, o que não está aderente ao regramento do Pix.

Então o problema que você levanta @monise é que você não teria certeza absoluta se o valor que você está recebendo está aderente considerando-se eventuais feriados municipais ou estaduais. Em particular, o que o PSP recebedor estaria buscando aqui seria justificar um valor "a menor" que seria somente explicado no caso de exceção em que o dia útil anterior caiu em dia teoricamente útil (seg a sex, sem feriados universais ou nacionais), mas na verdade haveria um feriado municipal ou estadual dependendo do codMun, o que poderia ensejar, por exemplo, incidência de multa ou não.

Pode-se empregar uma estratégia para tratar, como um zelo adicional, esse "corner case". O PSP recebedor pode guardar um "log" de valores válidos servidos contra essa cobrança (txid): para esta cobrança, foram servidos QR Codes na data de pagamento d1 para os códigos de município abc, def, e jku, nos valores x1, x2 e x3, respectivamente.

Delineando-se os passos desta estratégia, ficara assim:

chega a pacs.008 observa-se a data de chegada da pacs.008 e observa-se, via txid, que trata-se da cobrança com vencimento tal. observa-se o "log de qr codes servidos e assinados". para estada data, foram servidos qr codes considerando os códigos de municípios tais, tais e tais. os valores possíveis seriam tais, tais e tais. O valor da pacs é diferente de algum destes valores? Se sim, pode-se optar por rejeitar a pacs.008. Se não, em tese, o valor está aderente.

- A busca dessa informação no log deixa margem para alguns problemas, suponhamos que o cliente simulou o pagamento de um mesmo QR Code duas vezes de contas e municípios diferentes. Dado que não há uma chave forte (e2eid, por exemplo) na log o txid estaria gravado duas vezes. Qual deveria conceber como verdadeiro? - a sugestão de recalculo pode gerar divergências, dado que QR Code em casos de arredondamento o valor pode não bater em 100% dos casos e o código de município de recebimento não é enviado na pacs008 - fazer busca em logs de consulta pode gerar um falso positivo, dado que se por erro ou má fé o valor consiga ser alterado nunca será encontrado um log de consulta com o valor do pagamento enviado.

Não realizar a consistência no momento de recepção da pacs008 é deixar o sistema vulnerável a falhas, dado que teríamos que acatar todo e qualquer pagamento de qrcode confiando de que o valor consultado foi integralmente repassado para a mensageria. O que é solicitado pelo manual de experiência, porém, não conseguimos garantir sistemicamente com essa solução de busca em logs.

[ninrod]

bom dia @b-alencar

• A busca dessa informação no log deixa margem para alguns problemas, suponhamos que o cliente simulou o pagamento de um mesmo QR Code duas vezes de contas e municípios diferentes. Dado que não há uma chave forte (e2eid, por exemplo) na log o txid estaria gravado duas vezes. Qual deveria conceber como verdadeiro?

Lembrando que foi apenas uma sugestão de implementação que eu dei para ilustrar que o PSP poderia escrever uma validação mais preciosista da PACS.008 recebida, em termos de checagem de valor. No caso, você teria, "no log", se realmente houver alguma diferença de valor causada por feriados locais entre os dois municípios diferentes, dois valores diferentes. Só isso. Qualquer pacs recebida contra esse txid apresentando os dois valores seria aceita.

• a sugestão de recalculo pode gerar divergências, dado que QR Code em casos de arredondamento o valor pode não bater em 100% dos casos e o código de município de recebimento não é enviado na pacs008

Não sei que sugestão de "re-cálculo" seria essa.

• fazer busca em logs de consulta pode gerar um falso positivo, dado que se por erro ou má fé o valor consiga ser alterado nunca será encontrado um log de consulta com o valor do pagamento enviado.

Não consigo acompanhar. Onde e como haveria alteração?

Não realizar a consistência no momento de recepção da pacs008 é deixar o sistema vulnerável a falhas, dado que teríamos que acatar todo e qualquer pagamento de qrcode confiando de que o valor consultado foi integralmente repassado para a mensageria. O que é solicitado pelo manual de experiência, porém, não conseguimos garantir sistemicamente com essa solução de busca em logs.

O que o PSP recebedor estaria buscando aqui seria justificar um valor "a menor" que seria somente explicado no caso de exceção em que o dia útil anterior caiu em dia teoricamente útil (seg a sex, sem feriados universais ou nacionais), mas na verdade haveria um feriado municipal ou estadual dependendo do codMun, o que poderia ensejar, por exemplo, incidência de multa ou não; o que é bem diferente de "acatar todo e qualquer pagamento de qrcode confiando que o valor consultado foi integralmente repassado para a mensageria".