Histórico de mensagens sobre url de notificação

Boa tarde <@!305835973474910208>! É possível sim, você consegue mais detalhes de como configurar a url de notificação aqui https://dev.gerencianet.com.br/docs/notificacoes-recebendo.

Mas a melhor forma para verificar se um boleto foi pago, é recebendo as notificação automáticas. As notificações permitem que você seja informado quando uma transação/boleto tiver seu status alterado para pago, por exemplo.
Para isso, quando criar uma cobrança você irá informar o atributo notification_url, e então a Gerencianet dispara um POST para esta URL a cada mudança no status da cobrança.

Neste POST vai conter apenas uma informação: um token de notificação. Ou seja, se a URL cadastrada estiver preparada para ler o token na variável $_POST['notification'] e consultar essa informação, a resposta será todos os dados informativos sobre a alteração sofrida pela cobrança, como por exemplo, o status anterior e atual da cobrança.

Segue o link com mais detalhes sobre este assunto: https://dev.gerencianet.com.br/docs/notificacoes-recebendo

Pelo nosso plugin via woocommerce o cadastro da url é feito de forma automática e o status do pedido já é concluído de forma automática noa a nossa notificação.

Boa tarde, e-mail com pagamento confirmado não é enviado, no entanto, é possível configurar uma url de notificação onde notificaremos de forma automática sempre que uma cobrança for paga em seu sistema. O links são os mesmos que enviei na mensagem acima.

Bom dia <@!796583841887420466>, o plugin está pronto só que foi necessário alterarmos a url de notificação para o padrão /pix e estamos fazendo novos testes, mas a previsão é que esteja tudo certo para o lançamento amanhã

Você poderá definir uma URL que receberá as notificações durante a criação da cobrança. Esta URL irá receber um token quando uma transação sofrer uma alteração de status.

Com este token, sua aplicação poderá realizar uma consulta através da rota GET /v1/notification/:token para obter o status da transação e demais informações da transação.

Neste link, temos exemplos de como receber este token e posteriormente consultar os detalhes da notificação: https://dev.gerencianet.com.br/docs/notificacoes-recebendo#section-2-consultando-detalhes-de-uma-notifica-o

Mas para só o recebimento de notificações bastar, ele precisa ter as informações do recebimento... o que cai em requisitos que muitos acham pesados como mTLS. A simplificação do webhook com apenas (vê aí o que mudou no txid tal) torna a API direta mais necessária do que nunca. A única coisa que poderia atender isso seria não uma URL de notificação, mas o comprovante Pix digitalmente assinado.

No meu ponto de vista o principal entrave de adoção é a dificuldade técnica para o recebimento de notificações. Se fosse simples definir uma URL de notificação e o mercado pudesse ofertar serviços totalmente baseadas em QR estáticos (que são mais que suficientes para negócios cujo pagamento não tem vencimento, estão associados a um checkout imediato, como compras presenciais e e-commerce varejo padrão), sem necessidade de contratação da API por parte dos ECs, a adoção teria bombado.

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.

Bom dia pessoal!
<@!375094642238029824> melhor maneira para verificar o pagamento de uma cobrança é mesmo utilizando o webhook. Com seu webhook cadastrado em sua chave, as cobranças Pix (Por enquanto, QrCode dinâmico) criadas com sua chave que estejam associados a um txid, serão notificados em sua URL.
Exemplo de notificação de um Pix pago:

Olá, <@!801479233360232458>. Boa tarde!
Resumindo, será disparado um POST para sua URL contendo o token de notificação, este que será único para todo o "ciclo de alterações" da transação em questão.
Por segurança, as informações da transação serão enviadas somente quando seu sistema consultá-las utilizando o token de notificação recebido.

Para isso, você precisará enviar um requisição GET passando o token, o que lhe retornará as informações mais atuais da cobrança, todas ordenadas de acordo com os acontecimentos. Toda alteração em status gera uma notificação.

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]

Só não ficou claro pra mim o envio de duas urls de notificação. Só é permitido o envio de uma e se quiser alterar posteriormente você pode consumir a rota PUT metadata

Você pode definir uma única url de notificação, vamos enviar para elas as atualizações dos status de cada cobrança gerada. Cada uma com um token único

Boa tarde pessoal tudo bem? A url de notificação eu preciso gerar a cada pedido ou apenas uma única vez? Se eu mandar a URL sem querer duas vezes, vou receber duas notificações ou 1 sobrescreve a outra se for igual?

se você gerou uma cobrança para uma chave pix que tem a URL de webhook cadastrada e recebeu a notificação de pagamento corretamente, não precisa mais fazer setup de webhook. agora é só se certificar de criar as novas cobranças sempre com essa chave que tem a URL de webhook configurada

a url de callback de notificação do nosso servidor

Porém se desejarem manter o sistema com as cobranças atualizadas, caso haja alguma falha na comunicação, vocês podem utilizar o endpoint GET/charge/:id -https://dev.gerencianet.com.br/docs/playground-transacoes#charge_id . Esse endpoint permite retornar todas as informações de uma transação existente e tem a mesma funcionalidade da notificação que enviamos quando é cadastrado uma url de notificação.

Se eu mudar o webhook da tua conta, apenas a nova url vai receber notificação.. então não serve para nada...

Agora se eu pegar sua url e enviar uma notificação de RECEBIDO, você deve consultar...

Sem um certificado, qualquer um poderia fazer um for com getTxID() e enviar notificação..

Com o certificado, qualquer um que já tenha o certificado...

Putz, então eu passei do paranóico, kkkkkkkkk , a url de notificação mudará de tempo em tempo é ainda será em sha512.