Histórico de mensagens sobre webhook pix

a url aqui cadastrada esta https://url.com.br/webhook/pix/webhook.php consultei via postman

@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? 🙏

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

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.

O mTLS faz sentindo. Ainda mais quando se tem volume de transações, se a sua comunicação com o PSP é segura, não tanta há necessidade de checagem do evento (apesar de ser um item de segurança a mais). A questão toda é que um volume alto de transações iria gerar números altos de Webhook + números altos de checagem de Pix recebido, isso poderia bater no ratelimit do PSP.

da forma que é hoje, eu precisaria de um subdominio exclusivo, ou de um nível extra no path só pra diferenciar os webhooks de pix

mas veja só.. se eu tiver um subdominio webhook.exemplo.com.br, e cadastrar a raiz dele, eu vou receber os requests em /pix. ese eu tiver que trancar a garagem inteira, não vou poder usar /paypal , /pagseguro, etc. se estiver exigindo o mTLS da GN na raiz

mas eu posso exigir o mTLS em /webhook e não em /webhook/pix

faz sentido que eu faça isso? não. assim como também não faz sentido testar a URL que não é efetiva.

ainda assim. se o que vai ser acionado de fato é /webhook/pix porque testar /webhook na hora do cadastramento? entendo que tem solução, mas não vejo sentido. se não vai testar a URL efetiva, não deveria testar nada.

É só colocar o path para frente, se quiser compartilhar.
Ex: exemplo.com.br -> site
exemplo.com.br/webhook -> rota para webhook
exemplo.com.br/webhook/pix -> path acionado para pix

Seu atendedor do webhook já tem um /pix além do que vc passou na URL ?

e picpay não está batendo no webhook, apesar de aparecer nos pix recebidos

A sua URL do webhook já está habilitada com o /pix no final ?

A partir de agora a GN se adequou a API PIX em relação ao Webhook. Basicamente agora em toda requisição do webhook é enviado um /pix no final, independente da URL que você cadastrar. Exemplo:
Se você cadastrar

Lembrando que você cadastra https://providerpixfacil.com.br/pixfacil/v2/webhook e a GN chama https://providerpixfacil.com.br/pixfacil/v2/webhook/pix

URL url = new URL ("https://api-pix.gerencianet.com.br/v2/webhook/" + CHAVE_PIX);
HttpsURLConnection conn = (HttpsURLConnection)url.openConnection();
conn.setDoOutput(true);
conn.setRequestMethod("PUT");
conn.setRequestProperty("Content-Type", "application/json");
conn.setRequestProperty("Authorization", "Bearer =" + authToken);
conn.setRequestProperty("x-skip-mtls-checking", "true");
conn.setSSLSocketFactory(sslsocketfactory);

do webhook do pix

<@!780500099788701726> Pix sem txid não são notificados via webhook, neste cenário teria que ser pelo GET /v2/pix e se você tiver o cpf ou cnpj do pagador poderá usar no filtro