Histórico de mensagens sobre webhook pix em pix

1- Ao criar uma cobrança, você pode consultar o pagamento pelo endpoint /v2/cob/:txid e verificar se a mesma está com o status CONCLUIDA. Outra alternativa é o webhook para notificarmos o seu sistema de forma automática sempre que ocorrer um pagamento ou devolução de Pix.

2- Cada cobrança(dinâmica) tem obrigatoriamente um txid associada a ela e um E2EID que é retornado quando transita na PACS002, PACS004 e PACS008. Então sim, cada Pix é diferente e tem seu identificador próprio.

3- No momento não tem como "forçar" pagamentos em ambiente de homologação, mas já está em nosso backlog essa funcionalidade.

Certo, solicitei ontem a chave, mas então assim: crio o token. Depois crio a cobrança (onde me retorna o@pix para o@user) depois configuro o webhook para avisar quando pagou, correto? Agora as dúvidas são o seguinte: 1- ao criar a cobrança onde informo um token meu para eu saber quando pagou (qual parâmetro) ? 2- cada pix é diferente para cada pedido?

<@!704694550631022592> Bom dia!
Não se preocupe, este canal é mesmo para tirar suas dúvidas! 😉
Primeiramente, para quaisquer consumo dos endpoints do Pix, é necessário realizar uma autenticação com suas credenciais client_id, client_secret e certificado. Para isso, seu primeiro consumo será na rota POST /oauth/token. Segue exemplos em algumas linguagens: https://dev.gerencianet.com.br/docs/api-pix#section-exemplos-de-autentica-o-utilizando-o-certificado-p12

Após a autenticação, você utilizará o endpoint para criar uma cobrança PUT /v2/cob/{txid}. Documentação: https://dev.gerencianet.com.br/docs/api-pix#section-criar-cobran-a-

Para acompanhar as mudanças de status de um pix, você pode configurar um webhook, que reúne endpoints para gerenciamento destas notificações. https://dev.gerencianet.com.br/docs/api-pix#section-webhook

Utilize também nossa Collection da Gerencianet com todos os endpoints já configurados para o consumo (https://dev.gerencianet.com.br/docs#section-collection-postman-gerencianet-api-pix).
A respeito do seu certificado, logo lhe retornaremos através do ticket.

{
"webhookUrl": "https://pixblack.in"
}

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]

Boa tarde <@!798679248633856000> ! Consegue sim, o webhook é para automatizar o seu sistema, assim vamos notificar sempre que um Pix for recebido ou acontecer uma devolução. O <@!650023651512549427> falou tudo, estamos aqui para tirar dúvidas mesmo.

Não entendi esta:

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/pix?id=0000x22

A possibilidade mais simples de contornar a concatenação do /pix que a documentação força é justamente colocar um ?x= ao fim da URL para ficar ?x=/pix.

então pergunto:

1. qual a razão para agregar o /pix "no meio" da URL que foi definida pelo integrador e não no fim?
2. isso vai contra a documentação atual que diz que o /pix irá (sempre) no fim da URL - e se for pra mudar o conceito, seria melhor que esse /pix fosse retirado.

e sugiro aos integradores que estão lendo agora: não usem query params na URL do webhook conforme esse exemplo (prefiram path params)

No endpoint POST /pix caso a chave do recebedor não exista, você receberá um erro na hora. Isso significa que o webhook nem será acionado pois a solicitação de envio de Pix não funcionou.

Sobre os aplicativos conseguirem indicar contatos cujo telefone/email já estejam cadastrados no Pix, sabemos que estuda-se isso no BC e inclusive nós enviamos há pouco tempo uma proposta relacionada.

Pode ser que em breve seja viável uma "consulta no cache do DICT", de forma que não se gaste as fichas do bucket oficial...

A ideia é conseguir validar a chave antes de enviar o Pix e informar que essa chave não existe para fazer o Pix, por exemplo, sem a necessidade de esperar o webhook ou o processamento da solicitação de envio do Pix.

<@!664563985885954079>, o e2eid você consegue somente depois de pagar o Pix.. Então você pegar ele através do webhook que você recebe ou consultando Pix recebidos

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.

Boa tarde! Você pode consultar o Pix /v2/pix/:e2eId que vai ser retornado um array contendo todas as devoluções, como este:

Isso mesmo, Renato. <@!585695073908293632>, pode ter sim SSL Lets Encrypt.

Neste caso, para que funcione em sua URL, você deve especificar a rota para exigir o certificado somente na rota /webhook. Da forma que está utilizando, irá exigir certificado a qualquer rota da sua URL

Para isso, para configurar utilize:

A gerencia net tem webhook para o pix ?

Renato, agradecemos suas observações e elas serão consideradas...

Mas esclarecendo os pontos, quando você gera o estático, não consome a API, portanto não gera custo. O que gera o custo, é a utilização do webhook, no estático, utilizamos a webhook para o recebimento, porém, como você mesmo pontuou, esta é uma questão que está sendo verificada.

Mas neste momento não é uma preocupação, visto que temos a tarifa zerada até abril de 2021.
No link enviado a informação é que "As transações originadas pela API Pix serão gratuitas até o dia 30/04/2021."

Apenas corrigindo a minha mensagem, é "Pix recebido com valor IGUAL ou superior a R$90,00 = R$0,89" conforme link:

https://gerencianet.com.br/tarifas/

De na hora de ativar o webhook, eles tentarem com /pix?client_id=xxxxx, e fazerem fall-back para o anterior sem /pix se não der certo. Assim eles não precisam fazer uma virada de chave combinada, as pessoas vão migrando.

Ok, precisa ter no servidor o mTLS configurado com este certificado aqui para producao = https://pix.gerencianet.com.br/webhooks/chain-pix-prod.crt

Como citado pelo Rubens, o webhook só é acionado se houver um txid associado ao Pix. No momento as notificações estão ocorrendo somente no Pix dinâmico, mas já estamos trabalhando para ofertar em Pix estático com txid vinculado.

Boa tarde, estou fazendo a questão do webhook, fiquei com algumas dúvidas, o parâmetro "chave" diz respeito a chave pix mesmo ou é o txid?

<@!775350441965649951> , desculpa me intrometer, mas você falou algumas coisas erradas.

1. o GET /pix?txid=xxx é para consultar Pix recebidos (indiferente serem oriundos de QR estático ou dinâmico, tendo txid eles retornam nessa consulta), e não cobranças (que é no GET /cob)

2. pra consultar o(s) Pix recebido(s) por QR estático com um determinado txid ficaria GET /pix?txid=xxx&inicio=data_inicio&fim=data_fim

3. tendo o e2eid (que vem no retorno da consulta acima ou pelo webhook - quando a GN estiver notificando recebimentos oriundos de QR estático), aí pode-se consultar GET /pix/{e2eid}