Histórico de mensagens em sugestões

Top isso hein!!!

@everyone compartilho com vocês um link no qual vocês poderão acompanhar os resultados das nossas conversas nesse canal. Ainda não está na melhor visualização, e talvez ainda nem na plataforma ideal, mas já serve para organizar as informações:

https://gnetbr.com/HkglCIXCRv

No caso de acontecer um longo loop, nosso time entraria em contato com o cliente solicitando correção ou pedindo para desabilitar (com autorização do cliente) o Webhook

<@!780500321994539068>

Acho muito válido <@!780500321994539068> ! Meio que a gente aumenta exponencialmente até a 5ª tentativa. Depois continuamos notificando sempre de 2 em 2h.

Pessoal, hoje após 5 tentativas o webhook de notificação está sendo desativado. Isso faz com que ele precise de rearme manual; seria melhor o sistema continuar retentando para que ele se rearme automaticamente. Hoje o intervalo máximo entre notificações chega a 80 minutos, e quer seja 80, 120 ou 160 minutos de intervalo após decaimento exponencial, eu sugiro que o sistema continua tentando exatamente para evitar desarme/rearme. Se isso perdurar alguma ação manual por parte da Gerencianet talvez faça mesmo sentido, mas que por padrão o comportamento seja de reestabelecer a notificação é minha forte preferência. Que acha, <@!793123559874494465> ?

-- isso tudo eu tô deduzindo, com base na sua experiência de se deparar com a recusa do pagamento por parte do Itaú quando você manipulou o QR pra um valor menor, apesar dele ser estático

o que vai totalmente na contramão da determinação do BACEN, diga-se de passagem, pois estão oferecendo isso por uma API proprietária (o PagHiper tá passando pro Itaú o txid e o valor para eles registrarem isso do lado deles, a fim de que possam rejeitar pagamentos cujo valor divergir do esperado para aquele txid)

basicamente.. o Itaú tá usando QR estático para um cenário onde deveria estar usando dinâmico. apenas se pouparam de ter que oferecer a leitura de qr codes via payload. deixaram todos os dados da cobrança a cargo do integrador, guardando somente a associação txid <-> valor, e rejeitando o que não coincidir

Ainda não tô muito convencido, de qualquer forma vou aguardar isso ir para produção e fazer os testes 😄

não dá, pq cobrança é QR dinâmico, não tem como construir à revelia da GN

Já que vai pegar o txid via /cob e verificar que ele existe realmente...

Mas pensando aqui, o cara pode passar o txid de uma cobrança já existente (como foi meu caso com o paghiper) e enviar valor diferente.

Pode ser uma solução...

não vai dar match e vai ser recusado

se vc quer recusar absolutamente tudo que não for cobrança, é só colocar no seu regex qualquer dado impossível de existir em forma de txid, como ^-$ que nunca vai passar por ele.

Ter a opção de recusar tudo que não for do /cob (sem ser por regex) faz total sentido na minha concepção.

Vejo que pode existir uma opção de recusar tudo que não for no /cob. Não importa o que é "aceito" e sim o que você quer recusar, esse é meu ponto.

aí é só barrar o que chegar no seu regex

mas isso já tá previsto pelo fluxo, cara. olha lá, que se a cobrança existir, ela é aceita sem passar pro seu regex