Histórico de mensagens sobre webhook em pix

Tenho, pois existe a vulnerabilidade de registro da url do retorno de webhook !

Neste caso para que serve mesmo o webhook ? Se tenho que conferir de novo o STATUS recebido por ele ?

[#duvida] Tendo em vista que todos os certificados emitidos pela GN de validação do mTLS são iguais para todos os utilizadores , isso quer dizer que um outro utilizador pode de má fé tentar registrar uma outra rota de destino do webhook na GN e assim pode também enviar status de "RECEBIDA" para o utilizador atacado. Antes era um meio mTLS, agora serve para que mesmo este mTLS ? Se todas as chaves dadas pela GN são iguais para todos. Basta saber a chave .pem e ter o certificado .pem do atacado. Neste cenário , preciso esconder o máximo o nome da minha url de recebimento e o arquivo .pem gerado do meu .p12 . Correto ? Alguém desenha para que serve o mTLS ?

<@!781134406680838216> Por gentileza, poderiam me enviar todos os retornos possíveis do webhook em json, o que estou utilizando da documentação da GN está sem o array das devoluções, não estou utilizando o postman. Montei aqui um pagador de QRCode para o modo Dev. Obrigado.

Já que fiquei o dia baseado no exemplo de retorno do webhook que não serve para os testes com o postman, alguém tem um retorno válido de webhook que possa postar, por gentileza ( troquem os dados sensíveis), preciso apenas da estrutura do json, tendo em vista que não fiz nada em produção exatamente para poder testar tudo em homologação e depois só trocar o client id client secret e .pem . Esqueci até que ainda tem o error 403 forbidden no modo dev.

<@!671762828046106646> não tem um jeito de vcs oferecerem o ambiente completo em homologação? Não conseguimos enviar callbacks para o ambiente webhook no ambiente de homologação, o que impede testes pra validar o setup mTLS, por exemplo. Eu preferiria não ter que mexer no ambiente produção antes de certificar que o ambiente de homologação funciona. Da forma como está hoje, o ambiente de homologação é bem pouco interessante, pois a criação de cobranças sem possibilidade de testar os callbacks vindos diretamente da GN não tem muita serventia.

No retorno das consultas de cobranças vem no formato array mesmo. Só no exemplo do callback do webhook que notei que tinha um objeto no lugar do array

<@!671762828046106646> como está hoje o retorno do webhook ? Está ainda assim como estou testando? Estou nesta etapa de recebimento aqui no código para salvar no banco. 🙂 .

Embora eu não esteja usando o webhook, vi este exemplo e fiquei com uma dúvida. No exemplo "devolucoes" é um objeto, mas no manual "devolucoes" deveria ser uma array. Portanto, acho que o exemplo da GerenciaNet está errado (ou o manual)

Exemplo para testar a sua url do webook em modo desenvolvimento com php .

#solução para testes do webhook em modo desenvolvimento. Principalmente para quem não fez o mTLS ainda para usar em produção, é só criar um POST , no postman na sua url de recebimento do webhook no servidor e inserir as informações do json que é enviado no Body em raw no postman , este é um exemplo de envio que a GN faz em json abaixo que usei no raw

voce ja pode utilizar o de produção para fazer testes com o webhook, pois com o de homologação não seria possível. Então nesse caso, sugerimos gerar Pix de 0.01 para os testes.

https://gerencianet.com.br/tarifas/ - Nova página de tarifas. Ficou show!

Só me restaram 2 dúvidas:

1. a GN já notifica os pagamentos de QR estático com txid no webhook? (ainda não tenho cert. de produção, solicitei agora)

2. os recebimentos desses QR estáticos gerados sem a API (mas de forma autônoma, sem usar o App da Gerencianet), também serão gratuitos? A página de tarifas ainda não esclareceu esse ponto, citando apenas especificamente os QR estáticos gerados pelo app:

@Arthur estou usando o próprio retorno do webhook, tá rolando

Se não é mais pagável, me parece que não deveria mais ser ativa.. como só existem 4 status, deve trocar para REMOVIDA_PELO_USUARIO_RECEBEDOR e enviar um webhook..

Se o fluxo não for esse e o status também não, peço que a GN esclareça.

A remoção por outros de fato deveria ser sinalizada no webhook, é um evento assíncrono. Se está implementado é pergunta para a GN responder... 😉

Se você remover não tem pq gerar acionamento no Webhook... você já sabe o novo estado da cobrança.

As notificações para o webhook estão sendo enviadas em homologação?

Putz, agora que ví que hoje, não serve para nada implementar os endpoints do webhook em modo dev, pois ainda não tem como brincar de pagar PIX e receber retorno do webhook, vou pular direto para PROD. 🙂

a GN não oferece notificações para o webhook em ambiente de homologação (não entendi porque... limita a eficiência do ambiente de homologação)