Histórico de mensagens em pix

Olá, bom dia. Estou tendo problemas ao tentar excluir uma chave pix cnpj

@uppermesh Acredito que esteja tudo ok. Não recebemos nenhum relato sobre isso

Pix esta com problema geral?

Muito obrigado

Dei uma olhada no repo, de cara já ajuda muito por ter as interfaces prontas!

Ah nossa, verdade, tanto faz a chave dentro do payload se eles virão em rotas diferentes.

Notar que do envio x recebimento você nem precisa olhar a chave... apesar disso ser prudente por questões de segurança. Mas para recebimento (e devolução de recebimento) mapear o handler de recebimento na configuração do webhook, e no de envio, mapear o de tratamento de eventos de Pix enviados.

Nunca vi isso num repositório pq me parece uma lógica bem específica de cada aplicação consumindo a API Pix... diferente de uma tema mais comum a qualquer aplicação como Copia-e-Cola e QR-Code, que tem repos como o https://github.com/NascentSecureTech/pix-qrcode-utils .

Não achei nada nas issues do bacen.. talvez mais um indício de que estou complicando demais a coisa heheh

De fato. Ainda me parece um pouco invertido o caminho, pois apesar de eu ter salvo no meu bd que uma devolução foi solicitada, o controller que recebe esse payload ainda não sabe disso. Então é como se eu precisasse primeiro hidratar o meu handler com contexto sobre aquele evento antes de poder tratá-lo, agregando dados de uma ou mais tabelas pra daí poder prosseguir (não que isso seja um grande problema). A sugestão que você deu sobre as chaves serem os discriminantes é um exemplo disso: primeiro eu tenho que puxar minhas chaves e aí mapear o evento.
Posso estar complicando demais, pois ainda não comecei a implementação, mas não está muito trivial arquitetar isso com o meu patinho de borracha 😅 .
Por acaso vc conhece algum repo aberto com um exemplo bacana de implementação?

Agora, de devolução o mais simples é o seu handler saber que uma devolução foi solicitada, já que é você que solicita... não vai vir de surpresa uma devolução. Então se o Pix x teve uma devolução solicitada, ou uma nova devolução solicitada (pode haver mais de uma devolução para um mesmo Pix), aí se observa o campo de devolução.

Hmmm ótima ideia! Certamente é melhor do que checar o formato do payload.
Vou ver se já existe algum tipo de discussão acerca do assunto no foro. Obrigado!

Mas especificamente do seu exemplo, não precisa tratar pix enviado e pix recebido no mesmo handler. Você pode criar uma chave Pix específica para o webhook do envio de Pix e tudo que chegar nele, tem a haver com envio. O que inclusive ajuda na portabilidade pois o envio de Pix não é parte da API Pix padrão.

Você pode dar essa sugestão para o Banco Central... a Efí corretamente segue o padrão de API Pix estabelecido pelo BACEN, e o foro para essa idéia é https://github.com/bacen/pix-api/ .

Aqui usei os exemplos desta seção pra criar o código:
https://dev.gerencianet.com.br/docs/api-pix-endpoints#recebendo-callbacks

Fiz um exemplo pra ilustrar melhor minha questão.
Esse é o método que eu deveria usar pra entregar meu payload para o handler correto dentro da minha aplicação? Pois se não houver um método mais adequado, daí reitero minha sugestão de haver um enum associado a cada evento que descreva melhor o que ele está informando.

A devolução é uma atualização do mesmo objeto. Antes ele não tinha devolução, agora tem. Notar que uma devolução só acontece quando você pede, não quando o cliente pede... então de qualquer forma você nem precisaria de atualização assíncrona no webhook se a devolução sempre desse certo. Mas como pode não dar certo, por isso há uma notificacão da mudança de estado.

@rubenskuhl , o que quero dizer é que, programaticamente falando, como você diferenciaria um evento de recebimento de um evento de devolução, por exemplo?
Pelos prints, vc pode ver que o conteúdo de um evento de recebimento é um subconjunto do conteúdo de uma devolução, e parece que esse é o único critério que eu consigo usar para diferenciá-los.

Esse identificador é o txid, que você definiu na criação do /cob...

Boa noite pessoal.
Estava testando agora a api de cobranças imediatas, e reparei que o webhook que aponta o recebimento do valor (após o devedor realizar o pagamento) não contém nenhuma informação útil para discernir o tipo de notificação recebida.
Os atributos existentes ali não são suficientes para elaborar um uso de estratégia de tratamento da notificação decente, teria que fazer todo tipo de inferência em cima dos atributos recebidos.
Não seria bom termos algum tipo de identificador associado a cada evento?