Histórico de mensagens sobre webhook pix em pix

e se quiser mais detalhes, depois que já tiver o e2eid (obtido nessa consulta acima, ou por webhook, quando a GN passar a notificar pagamentos via qr estáticos), poderá usar o GET /pix/{e2eid}

Bom dia <@!781944293739986984>, verifique se você trocou o CA para ambiente de produção.

Por gentileza, uma duvida 🙂
Em que situação o webhook envia isso = já para o PIX enviado, temos:
• tipo "SOLICITACAO";
• status possiveis: ["EM_PROCESSAMENTO", "REALIZADO", "NAO_REALIZADO"]

Bom dia! <@!522899003663450113> ontem informamos que houveram mudanças nas notificações de nossos pix.
São elas: nós retiramos o campo tipo e status das notificações de PIX recebidos (seguindo a especificação do BACEN).

já para o PIX enviado, temos:
• tipo "SOLICITACAO";
• status possiveis: ["EM_PROCESSAMENTO", "REALIZADO", "NAO_REALIZADO"]

A mudança no retorno do webhook é para adequar as especificações do BACEN. A principal diferença foi a remoção dos status e tipo do Pix recebido. Um exemplo de como está a notificação de Pix recebido:
{"pix":[{"endToEndId":"E00416965620122145239O7ZcRRTsI88","txid":"fc9a43k6ff39ai84ryP5fd41a9718","valor":"0.01","horario":"2020-12-21T12:39:09.000Z"}]}

aqui eu to fazendo assim:
- assim que a pessoa gera o PIX, eu coloco o qrcode e o pix copia-cola na tela e instruo ele a realizar o pagamento
- enquanto ela vê o PIX, eu rodo uma checagem de 2 em 2segundos analisando se em meu banco de dados o PIX consta como pago
- quando a pessoa paga, no retorno via webhook eu atualizo em meu banco de dados para PAGO...
- assim que a checagem consta como "pix pago", o usuário recebe uma mensagem de confirmação e é redirecionado pra um histórico de pagamentos

como fallback (ainda nao fiz), é bom ter um script pronto pra consultar os pix do dia e ver se nada ficou "esquecido", talvez um cron a cada X minutos (ou horas).

ah sim, não manda mais o "status" (já que webhook só é acionado pelo PSP recebedor quando pix é recebido)

Foi modificado sim o webhook para mandar apenas array pix como previsto na especificação do BACEN.

sim. mas isso você śo pode fazer se souber o e2eid de uma transação da qual quer consultar detalhes. e vc não sabe o e2eid de uma transação até que:
- faça um GET /pix?txid=... e obtenha o e2eid da transação que quer consultar detalhes; ou
- receba um webhook informando o e2eid de uma transação que vc recebeu (o que a GN só está fazendo nos QR dinâmicos, por enquanto);
por isso, se usar QR estático, tem que fazer polling com o GET /pix?txid=... em vez de GET /pix/:e2eid

então.. mas esse E2EID disponibilizado no retorno da solicitação de envio, como ele está disponível antes da conclusão do envio, logo, no meu entender, elementos e2eid podem existir mesmo antes da conclusão do Pix (ele não é "gerado" apenas na efetivação do envio, mas antes disso - ainda que acessível apenas do lado do PSP pagador). no caso de recebimentos, a GN só toma conhecimento do E2EID de um Pix depois que já está efetivado? seria essa a justificativa para não ter status nos webhook (toda notificação sempre se refere a um Pix efetivado e por isso não vemos mais um elemento status no corpo do request)?

Você pode utilizar o endpoint GET /v2/cob​/{txid} ou então cadastrar um webhook, para quando um Pix for pago a notificação chegar de forma automática em seu sistema.

Pix recebido não tem status, quando você recebe um webhook com um valor é porque aquele Pix com o txid informado foi pago. Assim você consegue verificar quais cobranças foram ou não pagas

Bom dia pessoal! A mudança no retorno do webhook é para adequar as especificações do BACEN. A principal diferença foi a remoção dos status e tipo do Pix recebido. Um exemplo de como está a notificação de Pix recebido:

a URL de webhook é definida 1x por chave Pix, e todos os Pix recebidos para aquela chave (que tiverem txid) são notificados na mesma URL, não precisa registrar novamente

mas o webhook, de qualquer forma (com ou sem o campo 01 com valor 12), teria referência somente a esse novo pagamento (pelo menos no caso da GN, que eu me lembre, as notificações são sempre individuais, assim como nos boletos). essa questão de poder unificar mais Pix numa só notificação, eu não sabia nem ser possível (o Rubens que mencionou agora)

aí, tem duas saídas:

1. confiar que o PSP vai acatar sempre apenas 1 Pix por cobrança e que virá só 1 elemento nos webhooks e consultas e tratar apenas a posição zero do array, sempre. consequência possível: o PSP acatar um segundo Pix pra mesma cobrança e vc terá que se matar pra debugar esses casos no futuro...

2. ler o array todo, tratar o elemento da posição zero e, se houver qualquer elemento adicional, acionar um alerta / marcar uma flag de problema / etc...

Pessoal no webhook ele pode retornar mais de um pix? pq segundo a doc vem um array, ou ele retorna sempre um único pix?

vc provavelmente vai precisar fazer assim:
- criar o diretório /webhook/pix e colocar o arquivo dentro, com o nome index.php
- cadastrar a URL https://gn.seusite.com.br/webhook
- o request irá para https://gn.seusite.com.br/webhook/pix (e cairá no index.php, pois já deixei o location /webhook configurado para buscar o index.php dentro dos diretórios solicitados, mesmo quando a URL do request não encerrar em /)

Esse é o problema. Teoricamente a GN deveria ta enviando para:
https://gn.seusite.com.br/webhook/pix/url.php/pix

essa foi a URL que vc enviou? então o request deveria ir para https://gn.seusite.com.br/webhook/pix/url.php/pix

Aqui esta assim