Histórico de mensagens sobre an

Eu criei um atendimento em nosso canal de # atendimento para que possamos analisar melhor a situação

O cliente está tentando fazer um pagamento e não vai

Vou iniciar um atendimento no canal # atendimento para você

Boa tarde, @wallisonfelipe! Tudo joia?
Você esta tentando excluir a chave através da Conta Digital?

Desculpe, aqui está o link: https://dev.gerencianet.com.br/docs/api-pix-introducao

Alguém sabe onde consigo a API de cobrança do PIX?

sobre open-finance

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.

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.

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.

Boa noite!

Só para mim que o PDF do Boleto é impresso em 2 páginas, sendo que a segunda página é sempre em branco?

Existe alguma configuração para arrumar isso?

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?