Histórico de mensagens sobre pix em pix

Pix não tem status, apenas cobranças e devoluções

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:

https://github.com/bacen/pix-api/releases/tag/2.2.0

Bom dia, pessoal. 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"]

{"rawBody":{"pix":[{"endToEndId":"...","txid":"..","valor":"50.00","horario":"2020-12-21T11:24:58.000Z","tipo":"RECEBIMENTO","status":"RECEBIDO"}]}}

As notificações usam o objeto pix que tem os mesmos valores e atributos do que em GET

se você gerou uma cobrança para uma chave pix que tem a URL de webhook cadastrada e recebeu a notificação de pagamento corretamente, não precisa mais fazer setup de webhook. agora é só se certificar de criar as novas cobranças sempre com essa chave que tem a URL de webhook configurada

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

Pessoal pra cada pix eu preciso criar um webhook ou só preciso criar apenas um e não preciso mais pois ele já vai ficar notificando?

Se ela falhar em negar o 2o/3o. Pix de um mesmo txid, ela tem que te notificar.

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)

Eu havia entendido que como pode vir mais de um Pix na PACS.008 se acontecer de dois ou mais chegarem muito próximos no tempo, que isso pode acontecer no webhook também, mesmo que de cobranças distintas.

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...

o certo é vir apenas um. mas o BACEN por alguma razão que eu não entendo, considera que "problemas podem acontecer" e um Pix adicional ser acatado para uma mesma cobrança e aí o schema estaria pronto para lidar com isso e retornar mais de 1 elemento Pix; obviamente, o mais adequado seria não permitir que esses problemas aconteçam ou tratá-los tão logo identificados para que tudo opere dentro do schema esperado.

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

Aí é torcer para o BACEN padronizar o Authorization Code Flow. Com Client Code Flow você precisa ser o cliente.
Issue sobre isso: https://github.com/bacen/pix-api/issues/83

Você pode acompanhar o issue, Magno: https://github.com/bacen/pix-api/issues/239

Não consigo entender por que não terá um arquivo para ser chamado e sim dentro de uma pasta /pix. Ai sempre teriamos que usar o index.php e não quero usar ele, o nome do arquivo tambem dificulta para a segurança. 🙂

Não é acrescido o /pix ainda...

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 /)