Termos mais procurados:
galera eu to confuso com um ponto da documentação,
> Callbacks
> Esse serviço está protegido por uma camada de autenticação mTLS. Os callbacks são enviados pela Gerencianet via POST {$request.body#/webhookUrl}/pix quando há uma alteração no status do PIX.
>
Sugestão: alinhar melhor com a equipe as informações a respeito dos [novos] recursos e exigências [removidas] para consumo da API Pix. Por ex: as informações a respeito da necessidade ou não de mTLS no PUT /webhook, bem como no recebimento dos callbacks, estão desencontradas lá no canal <#❖pix>. Tem membros da equipe GN dizendo A e outros membros dizendo B.
Validar não, mas receber os callbacks sim.
A pergunta ficou dúbia mas o que o @ribas2555 queria saber é se ele vai usar o mesmo certificado que a GN enviou (para consumir a API) na hora de validar os callbacks. Então a resposta é não. Mesmo que o certificado usado pela GN do lado dela seja o mesmo nos dois casos.
Rubens, são certificados diferentes. O que consome a API é individual por cliente e ambiente (dev/produção). O que usamos pra validar o mTLS nos callbacks é diferente (separados apenas por ambiente dev/produção, sendo os mesmos dois para todos os clientes).
esse erro veio no PUT ou no callback recebido?
Faz. Vc precisa ter algo "disponível" para receber o callback.
<@!788954143658082304> valeu, mas isso não muda a ideia de que eu preciso ter um ambiente em pé para receber a notficação do api gateway mesmo ele servindo só como um bypass pro meu app, porque se o o GN manda a notificação para o api gateway eu ainda teria que receber um callback de la pra fazer alguma mudança no meu db e não é possivel localmente, faz sentido?
<@!780500321994539068> mas isso não é determinado no manual. Além disso, quem garante que validando no setup, o EC vai continuar validando quando receber os callbacks efetivos?
<@!780500321994539068> o manual de segurança diz que o callback deve ser enviado por canal mTLS. mas como o PSP pode garantir que o canal é mTLS? não existe isso. ele envia com certificado e o cliente verifica se ele quiser. não tem como a GN saber se o cliente tá validando.
não é bem assim. na verdade, a conexão mTLS não tem como ser validada dos dois lados. quem envia o request manda o certificado e o recebedor é responsável por validar, mas não tem como o emissor impedir que o outro lado "consuma" o request sem validar o certificado enviado. então a norma do BACEN, na prática, obriga o PSP a enviar o certificado e dar meios pro cliente verificar (e rejeitar o request se quiser). mas o EC pode simplesmente ignorar a verificação. o que o novo parâmetro faz é desligar a verificação que a GN faz (por iniciativa dela, não por obrigação) enviando um request sem certificado primeiro para testar se o EC valida. então se vc usa esse parâmetro, você poderá receber callbacks depois, que virão com o certificado, e recebe os dados normalmente mesmo que não valide o certificado (ou seja, sem "fechar mTLS").
Parece ok, conforme documentação mesmo. Eu não testei isso em desenvolvimento/homologação. Tinha visto que os webhooks/callbacks só funcionam em produção. Alguém confirma? <@!775350441965649951> <@!652136709982781470>
não funcionam. não dá pra mandar um callback de webhook fake (ainda)
e o que vc deveria receber? vc só recebe outros callbacks quando uma cobrança for paga ou devolvida
Pra quem tem dificuldades de implementar os webhooks por falta de suporte em hospedagem compartilhada para configurar mTLS, o Pix.ae agora oferece proxy de callbacks com mTLS.
Pra usar é muito simples: é só prefixar o seu domínio com mtls.pix.ae/. Por exemplo:
Para: https://exemplo.com.br/webhookpix
Use: https://mtls.pix.ae/exemplo.com.br/webhookpix
Obs: no ambiente de homologação, prefixe com mtls-h.pix.ae/
Uma otimização seria só revalidar os callbacks idle. Os de quem transação a cada alguns minutos logo terão dados de retorno gerados pelas próprias notificações.
Adianto que estamos pensando em validar esse teste de tempos em tempos, com uma requisição aleatória. (fora do fluxo de callback)
No ato do callback não existe teste prévio.
esclarecendo melhor essa pergunta: é possível saber se o EC tá exigindo o mTLS ou se tá ignorando (no próprio callback individual, não em teste prévio)?
e do lado de vocês, é possível "exigir o mTLS" pra decidir se os dados devem ser enviados (no momento do callback em si)?
