Termos mais procurados:
Boa tarde, @Deleted User.
Conforme o Rubens havia mencionado, o txid é gerado pelo recebedor, e o endToEndId é gerado pelo PSP pagador que identifica o pix pago.
O motivo do txid não apresentar nesta consulta, pelo fato do horário/data serem distantes, um do dia 14/12 e outro do dia 19/12, imagina que na geração do QrCode de um foi informado o txid, e do outro não.
Sugiro realizar alguns testes. Se persistir, nos informe que iremos averiguar
E é bom que a URL termine com /pix, para facilitar quando a GN consertar um desvio da especificação
PUT /v2/webhook/:chave
na URL, ":chave" é a sua chave PIX na GN. Você consegue vê-la/gerá-la através do App da Gerencianet. Não é possível vê-la pelo site, somente pelo App
no body
"webhookUrl", você deve informar a url de callback do seu sistema, que irá receber as notificações de alterações de status da cobrança
Aconteceu comigo 6 vezes, mas como faço o tratamento para verificar se a soma dos pix recebidos menos a soma das possíveis devoluções bate com o valor devido, não realizei nenhuma baixa indevida. Você consegue verificar isso através de uma consulta GET /v2/cob e filtrando "inicio=data_inicial&fim=data_final&status=CONCLUIDA". Feito o filtro, faça uma varredura para verificar quais estão sem o array pix. Daí você verifica o txid dessas cobranças no seu sistema para ver se estão marcadas como pagas.
Edit: aconteceu da cobrança mudar o status, não a parte do usuário tentar pagar e dar o erro causando a mudança de status
Para quem precisar, segue o código da verificação extra do CONCLUIDA:
No código parece estar tudo 100%
Ele muda conforme o Status da Consulta na Gerencianet
Por garantia, colocamos mais logs ainda, salvando a Consulta original e uma verificação extra para o Status CONCLUIDA, verificando se tem o array do Pix, valor e se bate com o da cobrança também
Este é o primeiro relato similar que vejo, mas se tivesse acontecido comigo, dividiria a análise do caso em 3 partes.
- certificar se o cliente realmente não foi debitado, uma vez que pelo relato, ele não sabe o saldo anterior e, aparente, não sabe consultar o histórico de movimentações
- certificar se houve mudança de status na GN que justifique a baixa da cobrança
- certificar se o sistema está fazendo baixas apenas com base em notificações realmente pagas, pois nem toda cobrança com status "CONCLUIDA" está de fato paga
Minha impressão é que pode ter ocorrido o seguinte (HIPÓTESE):
Algumas cobranças passam para o status "CONCLUIDA" em determinadas situações, principalmente quando consumimos a rota PUT /v2/cob. Não era pra acontecer, mas acontece. Daí, pode ser que quando o cliente leu o location, a cobrança pode ter mudado de status para "CONCLUIDA". Então, quando ele tentou pagar deu erro, pois a cobrança não estava mais "ATIVA". Uma notificação de mudança de status ocorreu ao alterar para "CONCLUIDA" e o sistema processou a baixa sem verificar se o array de pix estava devidamente preenchido
Pessoal a API tem algum time de geração de pix, por exemplo, só posso gerar pix a cada X segundos? Ou não pode gerar pix do mesmo valor mais de 1 vez?
conhece o https://pix.nascent.com.br/tools/pix-qr-decoder/ ?
testa aí no Neon pra ver se vai funcionar
00020126880014br.gov.bcb.pix2566qrcodes-pix.gerencianet.com.br/v2/50bbdc2cd60146c18d1cd149cf77068552040000530398654041.005802BR5908BRIANITO6006MANAUS620705036304BD97
Isso aqui quebrou um galho absurdo https://github.com/ceciliadeveza/gerarqrcodepix 😆
realmente. por isso estamos pedindo à GN a opção de limitar, chave a chave, o recebimento de pix quando vier sem txid
Consegue, mas você tem que pedir a lista de todos os Pix recebidos num determinado intervalo, eliminar os que você já sabe do que se trata e então tentar adivinhar do que são os outros.
