Termos mais procurados:
esta chave https://pix.gerencianet.com.br/webhooks/chain-pix-sandbox.crt devo baixar e utilizar aqui no sistema? ela só deve ser utilizada na requisições ou é obrigatório está no nivel de Servidor apache/nginx, caso queria fazer somente testes em desenvolvimento, sou obrigado a por o sistema online para fazer os testes ou consigo fazer o processo direto no postman??
SSLCACertificateFile /var/www/hwaiter/storage/app/pix/chain-pix-prod.crt
SSLVerifyClient none
SSLVerifyClient require
SSLVerifyDepth 3
O PIX tem WEBHOOK para notificar quando os status de pagamento estilo do boleto?
O Matheus havia citado que não estava conseguindo reproduzir, mas isso geralmente está acontecendo quando há uma edição no Pix e passei a informação pra ele.
Usamos a consulta /v2/cob com o filtro de 1 dia basicamente
Depois pegamos o Status do Reembolsado se tiver ou o Status normal
Colocamos agora uma verificação adicional também:
Boa tarde, <@!236380478955978753>.
Ainda não tivemos nenhum relato de algo parecido. Você possui o print, ou mensagem correta apresentada na falha?
Sugiro certificar se o valor realmente foi debitado, verificando o extrato da conta.
Realizar uma consulta em Pix recebidos, para saber se o valor foi creditado.
Você se refere ao location do QrCode dinâmico?
Consultando o location possui o status da cobrança, ou seja, sendo um QrCode que pode ser pago várias vezes, se você receber um Pix por esta cobrança ela continuará com o status "ATIVA".
Com o webhook cadastrado com sua chave, com as cobranças que possuem txid você é notificado quando um Pix é recebido.
Além disso, pode ser ser realizada a consulta pela rota /v2/pix com os parâmetros inicio=data_da_criação da cobrança, fim=data_atual e o txid da cobrança
Ok muito obrigado, para eu verificar se um Pix foi pago eu devo consultar a url de cobrança?
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
Vem no webhook e vem no pix
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 aonde tem a documentação do webhook do pix?
