Histórico de mensagens sobre Recebimento em pix

através do webhook monitoro o recebimento desse valor no caso, seria isso?

Não, é a Chave Pix da conta que receberá os recursos. O mais usual é criar uma chave aleatória para os recebimentos, mas pode ser qualquer dos tipos de chave Pix existentes.

Por hora, é o jeito <@!780500099788701726> . Dentro da plataforma também dá pra gerar um .csv do extrato, mas exige que você vá lá gerar o arquivo manualmente.
Realmente é um desafio fazer conciliação sem txid. Tanto que já estamos trabalhando uma opção de permitir que o EC recuso Pix sem txid. (entendo que no seu caso você não pode partir pra esse caminho)

Você poderia explicar um pouco mais sobre esse caso de uso?
Não vejo por que não pautarmos soluções como CNAB 750 ou até outro padrão para exportação dos recebimentos.

Boa tarde <@!623926773129936906> ! O webhook serve para automatizar o recebimento/devoluções de Pix gerados com a chave cadastrada em seu webhook. Para configurar e compreender melhor o conceito de webhook sugiro que acompanhe a documentação, em específico nesta secção (https://dev.gerencianet.com.br/docs#section-webhook). No caso você vai cadastrar o webhook e a partir daí vamos enviar as notificações dos Pix para ele.

e a outra, sobre os recebimentos por meio da chave Pix (não associados a cobrança) serem ou não tarifados, que não fica claro na página de tarifas (como já falei diversas vezes, não existe esse negócio de "Pix recebido pelo app"... o Pix é recebido pela conta transacional, não "pelo app" ou "pela api").

Se você receber uma transferência para a sua chave de um outro PSP, o webhook não vai ser acionado, pois, não é considerado uma cobrança Pix. Mas será notificado do recebimento pelo aplicativo Gerencianet

também discordo da forma que está divulgado no site e já apontei isso pra GN algumas vezes (e até me chamaram pra conversar sobre isso no privado, mas ainda sem efeito prático). pelo que eu entendi, se o recebimento tiver txid, é tarifado. assim como se ativar a API Pix (que viabiliza consultas inclusive aos Pix sem txid), perde a gratuidade dos recebimentos (mesmo os que não tenham txid).

Temos novidades, pessoal!
Sabe-se que muitos integradores desejam utilizar Qr Codes estáticos em cenários diversos, em especial envolvendo negócios de pequeno porte, mas que exigem um processo de conciliação dos recebimentos.

Para isto, publicamos uma atualização que irá notificar via Webhook os Pix pagos através de Qr Codes estáticos.
Saiba mais detalhes em nosso <#🖥changelog>

Não tinha entendido que era apenas para recebimento e não para envio...

Como eu faço envio de PIX pela api? Vi que não é possivel.. preciso ativar o envio? Os recebimentos estão vindo normalmente

Lembrando o informativo enviado:

Informativo sobre à adequação do /pix no webhook

Foi estabelecido que ao realizar o cadastro do webhook base pelo integrador, ocorrerá a adição do parâmetro /pix no POST {$request.body#/webhookUrl} pela Gerencianet no momento do disparo das requisições.
Abaixo trazemos alguns exemplos de webhook's e como será a notificação após esta mudança:

Integrador cadastrou a url base https://gerencianet.com.br, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.

Integrador cadastrou a url base https://gerencianet.com.br/pix, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix/pix.

Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/?id=0000x22/pix.

Seguindo então a nossa documentação o serviço será POST {$request.body#/webhookUrl}/pix.

Tal definição foi feita após analisar os feedbacks de integradores, questionamentos ao BACEN e discussões internas.
A data para deploy do novo padrão está alinhada para o dia 08/02/2021. Sendo esta arbitrada a fim de que todos os integradores da API-Pix que utilizam o serviço de webhook possam ajustar seus sistemas e aplicações, e evitar assim falhas ou mal funcionamento do serviço.

Uma sugestão é permitir o recebimento da notificação em ambos os modos: com e sem /pix. Dessa forma, quando virarmos a chave, não haverá problemas.

Quaisquer dúvidas referentes a esta transição, estamos a disposição em nossos canais de comunicação.

O que se cadastra no webhook é a chave Pix, por exemplo [email protected] . Aí todo recebimento para essa chave Pix que tiver txid vai chamar a URL (mais o sufixo /pix a partir de daqui alguns dias).

Então se seus recebimentos são para [email protected] como chave, só precisa configurar webhook uma vez.

Boa tarde @Deleted User! O status do exemplo 1 refere-se ao status da devolução. No exemplo 2 é o recebimento de um Pix e por isso não tem status.

O webhook é "trigado" qto tempo depois do recebimento do pix?

Eu estava observando aqui: a nova documentação de UX do Pix (v3.0) agora determina que é obrigatório as notificações de recebimento Pix (push, sms, email) conterem a descrição digitada pelo pagador e também o txid, quando houver. WOW!

Boa tarde @everyone, sobre à adequação do /pix no webhook, ficou definido que será feito o cadastro do webhook base pelo integrador e a adição do parâmetro /pix no POST {$request.body#/webhookUrl} pela Gerencianet no momento do disparo das requisições.
Abaixo trazemos alguns exemplos de webhook e como será a notificação:

Integrador cadastrou a url base https://gerencianet.com.br/, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.
Integrador cadastrou a url base https://gerencianet.com.br/pix, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix/pix.
Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/?id=0000x22/pix.

Seguindo então a nossa documentação o serviço será POST {$request.body#/webhookUrl}/pix.

Tal definição foi feita após analisar os feedbacks de integradores, questionamentos ao BACEN e discussões internas.
A data para deploy do novo padrão está alinhada para o dia 01/02/2021. Sendo esta arbitrada a fim de que todos os integradores da API-Pix que utilizam o serviço de webhook possam ajustar seus sistemas e aplicações, e evitar assim falhas ou mal funcionamento do serviço.

Uma sugestão é permitir o recebimento da notificação em ambos os modos: com e sem /pix. Dessa forma, quando virarmos a chave, não haverá problemas.

À medida que se aproximar da data de deploy seremos mais assíduos nas notificações. Quaisquer dúvidas estamos a disposição em nossos canais de comunicação. [ATUALIZADO]

a brecha que existe - pouco explorável - é que outros clientes podem definir a sua URL de webhook para as chaves deles, e recebimentos deles acionarem o seu webhook intencionalmente

então o ideal é seu sistema saber o que fazer com a notificação com base no conjunto todo do elemento Pix (consultar a presença de um array de devoluções e os elementos, se houverem), e comparar com a situação anterior da qual que vc já tinha conhecimento. se é um notificação de um e2eid desconhecido pra vc e não tem devoluções, é um recebimento novo

o próprio BACEN que retirou da spec argumentando que um Pix (e2eid) só chega ao cliente quando já está concluído, então você deve se basear na existência ou não de items de devolução dentro do pix pra saber quanto recebeu referente ao e2eid [e quanto foi devolvido, se for o caso] e não num campo de "status", pois um webhook pode ser acionado no momento que uma devolução acontecer, por exemplo e aí o status fica meio dúbio.. deveria ser, ainda, recebimento/recebido (pq o Pix foi recebido) ou devolução/devolvido por ser uma notificação acionada pelo gatilho de devolução? se o Pix for R$ 100 e a devolução for parcial, de R$ 10, fica ainda mais complicado se basear só nesse campo.