Histórico de mensagens sobre webhook pix

Recebeu Pix no webhook com esse txid
ou
GET no Pix com o txid como parâmetro
ou
GET na Cobrança (/cob) e ver se apareceu um e2eid

Bom dia <@!796583841887420466>, estamos na etapa final de testes do webhook e ainda esta semana será disponibilizado o módulo/plugin para woocommerce com a funcionalidade do Pix

Se quiser melhorar sua segurança, sim. Senão, cai no cenário apontado pelo <@!522899003663450113> em que alguém também com conta GN poderia mandar ativar no seu webhook uma outra chave Pix.

No webhook tem o /pix no final da URL e a chave.

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.

Olá, como funciona a configuração do WebHook para PIX, pos a aprovação devo enviar um WebHook?

que baixei aqui: https://pix.gerencianet.com.br/webhooks/chain-pix-prod.crt

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

As tarifações já tem um preço estabelecido, veja aqui https://gerencianet.com.br/tarifas/. Em relação ao webhook, qualquer cobrança gerada com a sua chave, desde que tenha um webhook cadastrado, será notificado. A única exceção é para Pix oriundos de QRcode estático e que não tenham um txid associado.

Outra duvida é se eu disponibilizar minha chave pix(CNPJ) por exemplo. E receber um pix nessa chave especifica eu serei notificado via webhook? Também tenho duvida se existe tarifa nessa operação já que na parte de tarifas no site fala que pix recebidos pelo aplicativo são gratuitos e somente os recebidos pela api serão tarifados

Pessoal, trazendo para cá a discussão sobre devolução por parte do favorecido. Contexto:

Não acho que o webhook padrão deva ser acionado, pois ele pode conter código que não entenda esse tipo de devolução. Acho que um outro webhook poderia existir, por exemplo /gn/webhooksendpix para configurar, e que mandaria o e2eid apenas. Caberia ao consumidor da API fazer match com o sendpix que teve devolução de algum valor.

Pessoal, uma dúvida sobre devolução de pix.
1. Pix enviado da GN > Chave qualquer. Recebo o webhook com a realização ou não. Tudo certo.
2. A partir da conta "favorecida", faço a devolução do pix.

Essa devolução por parte do "favorecido" deveria ativar o webhook e notificar minha aplicação? Entendo que a devolução esteja atrelada ao e2eid original.

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>

mas isso é particular da GN por que ela notifica os envios no webhook da chave, pois a conta transacional não tem webhook geral. o pix em si não transita com a informação de qual foi a chave que enviou ele.. entende?

Alguem pode me ajudar? A autenticação de TLS mútuo não está configurada na URL informada!

Webhook, pix

Linux centos php

sendo o "webhookUrl/pix" acionado somente no recebimento de Pix e trazendo o txid + valor pago, já possibilitaria muitas integrações. com mTLS não fica tão facilitado, mas ainda perfeitamente possível.

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.

Boa tarde, <@!802052811718262814>!
Tente seguir estes passos, que estão mais detalhados par aconfigurar o Apache.
Primeiramente você deve acessar o arquivo de configuração do apache, geralmente fica em /etc/apache2/mods-enabled
Nele você irá fornecer o caminho da chave privada server_ssl.key.pem e uma pública server_ssl.crt.pem da sua certificadora SSL do seu domínio.

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.