Histórico de mensagens sobre webhook em pix

Sim, o pix esta na conta aqui da GN já , porém nao recebi nada via webhook.

Hoje é segunda , fiz pagamento de pix com sucesso e não recebí nada na url cadastrada via webhook, por isso estou na duvida.

#duvida. Mesmo com o processamento de recebimento de pix efetuado com sucesso nas segundas-feiras temos que esperar para a terça-feira para receber a notificação do webhook na nossa url ?

exato, tentei mais de 10 vezes pagar um pix lá, e agora que lembrei que hoje é segunda e a GN não envia webhook hoje de recebimento para a url 😦

#duvida Em qual local posso ver os envios do webhook para a url cadastrada, não consigo achar em API logado online na conta. 😦

@Efí, o erro “A requisição na URL informada falhou com o erro: ERR_TLS_CERT_ALTNAME_INVALID” parece estar relacionado com o certificado da Amazon.

Ele ocorre para os dois cenários a seguir:

Webhook COM mTLS hospedado na Amazon, com certificado HTTPS emitido pela Amazon:
https://mtls.menur.app/vbeta1/establishments/mana/pix

Webhook SEM mTLS hospedado na Amazon, com certificado HTTPS emitido pela Amazon:
https://mtls.api.menur.app/vbeta1/establishments/mana/pix

Entretanto se acessar SEM mTLS com hospedagem no Heroku e certificado Let’s Encrypt o erro que dá é esperado:
https://api.menur.app/vbeta1/establishments/mana/pix

"A autenticação de TLS mútuo não está configurada na URL informada"

E agora? Vocês poderiam verificar o motivo? Obrigado!

Basicamente se você cadastrar:

Olá, @Efí

Ainda na labuta do Webhook em ambiente PaaS. Fiz os seguintes passos e creio estar quase lá:

- Criei uma conta na Amazon para o projeto
- Cadastrei o cartão de crédito
- Provisionei o Amazon API Gateway
- Configurei um custom domain nele
- Configurei o domínio no meu Registrar
- Habilitei o custom domain no API Gateway
- Criei certificado e habilitei o HTTPS
- Baixei o cert webhook da Gerencianet
- Criei uma Trust Store PKCS12
- Coloquei a cadeia da GN lá
- Converti a TS para o formato PEM
- Provisionei um armazenamento Amazon S3
- Subi a TS.pem
- Finalizei a configuração do custom domain
- Ativei o mTLS neste domínio
- Criei uma rota de API para o meu server
- Associei a rota ao custom domain com mTLS

Fui configurando e testando a cada passo. Quase tudo funcionando. A única coisa que não consigo é fazer uma requisição client para testar o mTLS já que não tenho o cert client do webhook.

Então…

- Invoquei o serviço PUT /webhook/{chave} passando no body a url e recebi o seguinte body com o status 400:

{
"nome": "webhook_invalido",
"mensagem": "A requisição na URL informada falhou com o erro: ERR_TLS_CERT_ALTNAME_INVALID"
}

Supus ser algum erro no pem que usei para configurar o mTLS. E já experimentei o seguinte:

- Usei exatamente o CRT que baixei das docs da GN
- Fiz a conversão como citei acima (criando a TS)

Se vocês puderem fazer uma requisição mTLS com o certificado client correto para testar, a UTR é esta:

POST https://mtls.menur.app/vbeta1/establishments/mana/pix

O serviço está retornando 204 fixo para qualquer body json (não obrigatório).

Alguma luz? 🙏

Teve alterações significativas no Webhook?
Algumas transações da sexta-feira passada não obtive o callback da GN, observei algumas alterações no <#🖥changelog>, mas observei apenas algumas adições na última quinta-feira (11).

O webhook só é acionado se for recebido txid, você pagou em qual banco ?

Bom dia, pessoal! Tudo bem? Estou com dificuldades para receber webhook quando realizo pagamento de uma cobrança Pix imediata.
Eu tenho uma chave aleatória Pix cadastrada na GN e utilizei a mesma no cadastro do webhook, chamando a rota PUT /v2/webhook/:chave. Acredito que o cadastro foi bem sucedido, já que a GN fez uma chamada POST no endereço que eu informei.
Criei uma cobrança imediata com essa mesma chave Pix e realizei o pagamento. Verifiquei que o valor da cobrança já foi creditado na conta da GN, mas o webhook não foi disparado. Preciso de ajuda, por favor

https://dev.gerencianet.com.br/v1/docs/api-pix#section-webhook

E só completando aqui a ideia do secret. Não há 2 pessoas envolvidas como você citou. Existe só 1 pessoa. A pessoa cria o secret e ela mesma cadastra o webhook no serviço do PSP. Por isso que o conceito é secret mesmo. Se entrarmos no mérito que alguém do PSP pode acessar a base de dados de cadastro de webhooks aí o negócio começa a ficar extremo, pois da mesma forma poderia ter acesso a outras informações pessoais que teriam muito mais valor que um secret de um webhook. E quem garante que a geração das chaves privadas na CA do PSP, que provavelmente não tem certificação oficial de CA, é mais segura que o acesso às informações privadas de uma base de dados de produção? Comentando aqui só para destrinchar mais o assunto... indo além do tabu.

Se você quiser interagir com o pessoal do BACEN, eles respondem no GitHub, https://github.com/bacen/pix-api/issues . Mas se você pesquisar nos closed issues vai ver que o tema de mTLS é uma reclamação constante lá. E a posição do BACEN de que isso pode ser revisto na v3 (para o webhook, não para o sentido direto da API) também foi postada lá.

...ou qualquer outra pessoa que esteja fazendo uso do webhook

<@!780500321994539068> o server com o webhook que você usa está "deployado" em algum PaaS? Se sim, qual?

Não é apenas não-repúdio, como há informações financeiras em trânsito, há também questões de sigilo bancário. O próprio BACEN parece amigável a que numa versão 3 o webhook contenha menos dados (por exemplo apenas a chave Pix e o txid) e com isso possa ter requisitos menores de segurança, pois a informação bancária só seria transmitida no GET de /pix ou da cobrança que o causou. Mas para a versão 2.x, ficou assim e não vai mudar.

Uma forma também comum no mercado é, quando registrar um webhook, definir também um secret. E fica a cargo do webhook checar o secret. Isso garantiria também que as requisições vem de uma origem confiável e não precisaria fazer grandes mudanças na arquitetura. Uma solução de mercado que é viável em webhook em PaaS.

O mTLS aí está servindo para "garantir" para o meu back-end que quem está chamando e mandando as requisições para meu webhook é um certificado gerado pela CA que está naquele cert disponibilizado no site da Gerencianet. O que estou "propondo", é que não houvesse essa restrição na chamada do webhook. Logo, o payload da requisição poderia não ser de confiança. Por isso, a chamada ao webhook seria apenas como um ping, como um push notification, contendo uma chave para que só então o webhook fosse, ativamente, buscar pela informação. É uma arquitetura diferente da que está. É como o Pag Seguro faz, por exemplo. E é tão seguro quanto, só que menos dependente de configuração junto à infra. Enfim... é só um pensamento. Vou ver como resolver de outra forma.

Então, <@!522899003663450113>, na verdade eu suponho que a spec do webhook poderia ser melhor. Mas aí já é discussão para envolver Bacen tmb.