Validações do PSP Recebedor ao receber uma cobrança com vencimento [codMun não presente na pacs.008]

[monise]

Olá! Gostaria de tirar algumas dúvidas sobre o recebimento de um Pix através de um QR code do tipo cobrança com vencimento:

1 - O PSP Recebedor no momento do recebimento, ou seja, quando está processando a PACS.008, deve verificar se o valor do recebimento é o valor esperado para a cobrança que está vinculada ao txId informado?

2 - Se o PSP recebedor no momento do recebimento deve verificar o valor da cobrança, entendemos que os cálculos considerando juros, multa etc também devem ser feitos no momento do recebimento, correto?

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?

4 -  A data de recebimento da PACs.008 é em UTC, correto? Para o PSP recebedor verificar se a cobrança está sendo paga após o vencimento, é necessário converter a data de recebimento para UTC -3 correto?

5 - O PSP pode rejeitar um recebimento que o valor seja diferente da cobrança?

[rubenskuhl]

1 e 5 - Sim, até pq cobrança com vencimento só em QR-Code dinâmico.
2 - Sim, mas condicionado à data em que o pagador imagina pagar (DPP), não à data em que a consulta está sendo feita.
3 - O código de município e a data pretendida de pagamento são passadas pelo PSP pagador no download do payload. O GET do cobv tem 2 parâmetros adicionais, município e data pretendida de pagamento.
4 - Nem toda cidade Brasileira está em UTC-3, mas o código de município pode identificar qual o fuso aplicável numa determinada data num determinado município.

[monise]

@rubenskuhl Minha dúvida continua no item 3, porque uma coisa é fazer o cálculo quando o usuário pagador acessa o payload passando o município e a data pretendida. Outra coisa é realizar o calculo novamente quando estou recebendo a PACS.008 e vejo que o txId está relacionado a cobrança com vencimento. Nesse momento eu vou fazer o cálculo baseado na data que está chegando a PACS.008, não tem como eu saber nesse momento que o pagador passou um município
e uma data diferente. Só que se isso acontecer, o pagador pode ter informado um valor diferente do que o sistema vai calcular no momento de processar o recebimento.

[ninrod]

Olá! Gostaria de tirar algumas dúvidas sobre o recebimento de um Pix através de um QR code do tipo cobrança com vencimento:

1 - O PSP Recebedor no momento do recebimento, ou seja, quando está processando a PACS.008, deve verificar se o valor do recebimento é o valor esperado para a cobrança que está vinculada ao txId informado?

Em regra geral, é o que se espera. Cabe ressaltar que o cálculo do valor a ser recebido para o caso de cobrança com vencimento podem entrar no cálculo: juros, multa, abatimentos, descontos, feriados nacionais, estaduais, municipais e afins.

2 - Se o PSP recebedor no momento do recebimento deve verificar o valor da cobrança, entendemos que os cálculos considerando juros, multa etc também devem ser feitos no momento do recebimento, correto?

É uma liberalidade do PSP recebedor implementar essa funcionalidade da forma como preferir. Tecnicamente "o cálculo" poderia ser feito "no ato" ou poderia ser pré-calculado, uma vez por dia, por exemplo.

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?

Exatamente como o @rubenskuhl mencionou, é responsabilidade do PSP pagador enviar a informação do código do município, se o PSP pagador dispor desta informação. Adicionalmente, o PSP pagador pode enviar a data de pagamento pretendida (DPP) para que o recebedor possa calcular o valor correto a ser pago nesta data (diferentes DPPs podem mudar o valor final da cobrança).

@monise , muito bem apontado, realmente, o problema aqui é que a PACS.008 não admite, na presente versão do catálogo, o envio do código de município. Então, em um primeiro momento, não há como o PSP recebedor realizar a checagem utilizando este parâmetro. Estamos verificando, já respondo.

4 - A data de recebimento da PACs.008 é em UTC, correto? Para o PSP recebedor verificar se a cobrança está sendo paga após o vencimento, é necessário converter a data de recebimento para UTC -3 correto?

Como o @rubenskuhl mencionou, o código do município, se presente, é a informação relevante para efetivar esta validação. Pode-se considerar, adicionalmente, horário de verão.

5 - O PSP pode rejeitar um recebimento que o valor seja diferente da cobrança?

Sim, entra na esfera de liberalidade do PSP recebedor. O PSP recebedor pode entender que o valor está errado considerando os parâmetros de configuração da cobrança e rejeitar a pacs.008 via pacs.002. Entretanto, nem todas as checagens podem ser realizadas, no presente momento, como você bem apontou na questão 03.

[ninrod]

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:

1. chega a pacs.008
2. observa-se a data de chegada da pacs.008 e conclui-se, valendo-se do txid, de que se trata da cobrança com vencimento tal.
3. observa-se o "log de qr codes servidos e assinados". Verifica-se se para estada data, e para este txid, foram servidos QR codes considerando os códigos de municípios "a", "b" e "c". Os valores possíveis seriam "x", "y" e "z".
4. O valor da pacs é diferente de algum destes valores?
5. Se sim, pode-se optar por rejeitar a pacs.008. Se não, em tese, o valor está aderente.

[ninrod]

@monise, a resposta foi suficiente?

[monise]

@ninrod muito obrigada pelo retorno Filipe! A resposta foi suficiente sim.

[franciscotfmc]

@ninrod a questão ficou muito bem respondida e ficou claro que existem alternativas. De qualquer forma, saberia dizer se há uma expectativa de que o catálogo da PACS.008 seja alterado para trafegar o codMun do pagador?

[ninrod]

@ninrod a questão ficou muito bem respondida e ficou claro que existem alternativas. De qualquer forma, saberia dizer se há uma expectativa de que o catálogo da PACS.008 seja alterado para trafegar o codMun do pagador?

@franciscotfmc , bom dia. Não há essa expectativa, no momento.