Termos mais procurados:
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 /)
Mas é melhor já ir trabalhando nisso antes, para já funcionar só com /pix e não /pix/url.php.
está normal na url que cadastrei, não tem um /pix a mais nao.
provavelmente tá indo pra URL exata que vc cadastrou (sem um /pix extra ao fim, como deveria ser segundo a documentação)
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
Isso impediria como a gente poderia contornar o /pix. Pois o PSP enviaria https://example.com/pix?Client_Id=ASDASDA
E se cadastrássemos como https://example.com/webhook.php?varinutil=/pix?Client_Id=ASDASDA
até onde eu sei, ele colocou o /pix na hora de cadastrar (e a GN tá enviando pra URL cadastrada, sem adicionar outro /pix)
então vc leu errado... rsrs
a documentação diz que vc cadastra https://URLX e o PSP deve enviar pra https://URLX/pix (adicionar o /pix ao fim da URL que vc cadastrou). Se vc cadastrar com /pix ao fim, o request iria para /pix/pix
O que diz a do BACEN é que vc coloca webhookUrl e o PSP adiciona o /pix nela.
