Histórico de mensagens sobre webhook

Integrador precisa validar por exemplo se o webhook é de test ou transacional para enviar o x-mtls-check da forma correta.

O BACEN parece bem propenso a continuar com mTLS no webhook na v2. Porém, parece haver espaço para na v3 simplificar as webhook para notificação apenas, e aí em algo que só tenha notificação, se quem mandou o aviso foi o PSP ou o Gasparzinho, dá na mesma.

isso dá mais flexibilidade pra um integrador que recebe os webhooks de ligar/desligar o mTLS bypass sem interferência no script que tá fazendo o envio do PUT

ou seja, o header seria enviado pelo script que RECEBE o callback e não pelo script que consume o PUT /webhook

Pelo que entendi o fluxo seria:
PUT /webhook
Headers:["x-mtls-check": false]
----
Webhook de teste é enviado sem certificado e configurado normalmente.
---
Webhook normal é enviado com o certificado.

Mas ai eles enviariam o webhook de teste com o certificado...

a proposta da GN é passar o header x-mtls-check: false na hora de fazer o PUT /webhook. esse header poderia ser enviado pelo servidor/script que recebe os callbacks

A ideia é na hora que for inserir um webhook e você for enviar o PUT /webhook, informar no header que não quer que seja verificado.

sugestão: em vez de mandar o header que determina o bypass no consumo da API (PUT /webhook), esse header poderia ser enviado pela página que recebe o request da GN

Outra dica é se atentar a adição do /pix na url do Webhook.

Inclusive eu já faço uma verificação de se o Webhook está configurado certo...

Eu não entendi o raciocínio. Se na hora da notificação eu tenho que validar o mTLS de qualquer forma, melhor que a validação aconteça no cadastro da URL, mesmo, como está hoje. É um benefício gigante eu não precisar gerar o acionamento de webhooks pra saber se a configuração tá correta!

Eu tenho testado isso, Francisco, mas todas as questões se tornaram necessárias alguma configuração no webserver, por exemplo, dito isso essa integração vale a pena? Hoje como está podemos observar se o Webhook está de fato funcionando ou não...

:443>
ServerName idelivery.autum.com.br
ServerAlias .idelivery.autum.com.br
DocumentRoot /var/www/autum-idelivery/public

Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
Require all granted


SSLEngine on
#SSLCertificateFile "/etc/apache2/ssl/certificates/idelivery.autum.com.br.crt"
SSLCertificateFile "/etc/letsencrypt/live/idelivery.autum.com.br/fullchain.pem"
#SSLCertificateKeyFile "/etc/apache2/ssl/certificates/idelivery.autum.com.br.key"
SSLCertificateKeyFile "/etc/letsencrypt/live/idelivery.autum.com.br/privkey.pem"
SSLCACertificateFile "/etc/apache2/ssl/certificates/chain-pix-gerencianet-prod.crt"
SSLVerifyClient none


#SSLCACertificateFile "/etc/apache2/ssl/certificates/chain-pix-gerencianet-prod.crt"
SSLVerifyClient require
SSLVerifyDepth 3


ErrorLog ${APACHE_LOG_DIR}/autum-idelivery-error.log
CustomLog ${APACHE_LOG_DIR}/autum-idelivery-access.log combined

E se tentar acessar a URL do webhook com curl (linha de comando mesmo), o que acontece ?

E aí pessoal. Boa tarde! Alguém já pegou 403 ao definir o endereço do webhook de uma chave?
"webhook_invalido"
"A URL informada respondeu com o código HTTP 403"

os webhooks precisam de um ambiente de produção pra testa-los ??

olá pessoal, tenho uma duvida sobre o webhook

Vai ser bloqueado, uma boa prática é a utilização do webhook para evitar o polling. Não está estabelecido ainda quais serão os limites de consumo, informaremos no canal quando forem definidos.

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.