Histórico de mensagens em pix

não estudei a fundo as mensagens PACS, já que isso é da comunicação entre PSPs e BACEN

Mais deixando o BRcode dinamico para ser pago apenas uma vez isso já elimina a possibilidade de dois pagamentos, correto ?

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?

nada 🙂

Sim, eu que não me recordava que se tratava exatamente da duvida que surgiu hoje, valew 🙂

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

Pode ser uma ótima saida, como posso ter a chave, não faria diferença.

Inclusive me recordo de você responder ele...

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

E espero sinceramente que incluam a chave no body.

Putzzzz. Mais por um lado pode ser util, pois posso ser um concentrador de recebimentos de webhook. Que inclusive é o caso aqui 🙂

Por isso que será adicionado o client_id no webhook para você detectar e recusar isso.

Consegue hoje, o <@!522899003663450113> já testou e comprovou.

Ok, bora testar 🙂 Se alguém consegue receber um retorno de webhook cadastrando uma chave de outra conta GN 🙂 Ai valido a duvida 🙂

client_id, client_secret, certificado e chave.

Então em tese, se tenho o client_id e a chave, posso receber webhook de outra conta GN, correto ?

Quem vai ter que checar se é o client_id certo é você. A GN vai passar a mandar o client_id, aí você que não é o seu e rejeita.