Termos mais procurados:
Boa noite! Eu estou confuso sobre uma questão... Configurei o meu webhook para ser executado na URL: https://meudominio.com.br/webhook/gerencianet, e portanto, pelo que entendi, eu vou receber as notificações PIX sempre no /webhook/gerencianet/pix. Mas então vi essa imagem acima onde mostra que devemos configurar um alias que irá redirecionar o /pix para /webhook/gerencianet, ai ficou confuso, rs...
obrigado, o webhook aceita portas diferentes? exemplo xpto.com:8443?
Boa noite <@!337383375289712651>. "webhook inválido" é uma resposta esperada dentro da nossa API, como a url respondeu com um código diferente de 200, quer dizer que algum requisito de cadastro do webhook ela não está cumprindo. Verifique na nossa documentação se você está seguindo os passos corretamente: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-configurar-o-webhook-pix
Sugerimos também que verifique a sessão de validação mTLS que é uma etapa importante do cadastro do webhook: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-entendendo-o-padr-o-mtls
Do webhook, é importante ver se o PUT veio com resultado positivo de ativação do webhook. E se o resultado for negativo, aí o conteúdo é importante para diagnóstico.
Você só precisa cadastrar o webhook uma vez por chave, mas se fizer mais cadastros, eles vão só sobrepor o anterior. Por causa da idempotência a resposta sempre vai ser a mesma.
Beleza! Tudo bem? <@!795645731385901076>
Obrigado pela ajuda, segue:
const express = require("express");
const app = express();
const { WebhookClient } = require("dialogflow-fulfillment");
const bodyParser = require("body-parser");
const mysql = require ('mysql');
var logger = require('morgan');
////////////////// HTTPS
const fs = require("fs");
const https = require("https");
const options = {
key: fs.readFileSync("key.pem"),
cert: fs.readFileSync("cert.crt"),
ca: fs.readFileSync("chain-pix-prod.crt"),
minVersion: "TLSv1.2",
requestCert: true,
rejectUnauthorized: false
};
///////////////// HTTPS (FIM)
app.use(logger('dev'));
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));
app.use(express.static("public"));
////////////////// GERENCIANET (PIX)
app.post("/gerencianet", (request, response) => {
console.log('Entrou gerencia-net');
response.status(200).end();
// Verifica se a requisição que chegou nesse endpoint foi autorizada
if (request.socket.authorized) {
response.status(200).end();
} else {
response.status(401).end();
}
});
// Endpoind para recepção do webhook tratando o /pix
app.post("/gerencianet/pix", (request, response) => {
response.status(200).end();
console.log('Entrou gerencia-net');
if (request.socket.authorized){
var body = request.body;
console.log(body);
response.status(200).end();
}else{
response.status(401).end();
}
});
//////////////////GERENCIANET - FIM(PIX)
//////////////////////////// HTTPS
https.createServer(options, app).listen(8000);
console.log('Servido NODE (HTTPS) na Porta: 8000!');
/////////////////////////// HTTPS
Pessoal, boa tarde! Desculpe pela insistência. Alguém aqui já conseguiu criar o webhook no Azure? Depois de publicar, o Docker fica dando erro no ping da porta 8080.
Para definir qual URL será o seu endereço de retorno, você deverá consumir o endpoint PUT /v2/webhook/:chave_pix passando no body da requisição o parâmetro webhookUrl com sua URL.
Complementando, é importante que em seu domínio que representa o seu servidor, esteja configurado a chave pública da Gerencianet para que ocorra a autenticação mútua (mTLS).
Você encontra mais detalhes em: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-webhooks
<@!671763456487325717> Bom dia! Estou criando os certificados para criar o webhook. No Azure, estou usando certificados gratuitos, que não podem ser importados. Vc consegue me orientar como devo proceder para usar esses certificados no webhook?
Bom dia! Está difícil fazer esse webhook funcionar, mas vamos lá... Meu site está hospedado num servidor Linux CentOS 7 rodando Apache 2.4 e estou usando PHP. No diretório onde vou receber as notificações de webhook eu resolvi criar um .htaccess e exigir o certificado CA da seguinte forma: criei no diretório ~/webhooks/notificacoes um .htacess como abaixo:
SSLVerifyClient require
SSLVerifyDepth 3
SSLCACertificateFile /home/certificados/chain-pix-sandbox.crt
Quando tento acessar uma página dentro de ~/webhooks/notificacoes, recebo um erro HTTP 500 e no log do Apache aparece a mensagem:
"/home/meusite/public_html/webhooks/notificacoes/.htaccess: Your SSL library does not have support for per-directory CA"
Esta mensagem quer dizer que meu servidor não vai suportar a autenticação que exige a GerenciaNet?
Agradeço se alguém conseguir me ajudar...
Obrigado pela resposta Rubens! O que você falou no caso se aplica a uma mesma transação Pix, correto? Eu queria também saber como esse comportamento se dá no contexto de várias transações diferentes. Estou integrando com a API Pix da Gerencianet utilizando as credenciais da conta PF que abri e estou fazendo testes utilizando o certificado de produção pra fazer testes devido a dificuldade de testar o retorno do webhook utilizando o de homologação. Estava devolvendo todas as transações PIX que havia pago no dia de hoje testando minha aplicação (várias transações de um centavo) e não consegui realizar uma das devoluções por causa desse limite. Recebi um 422 e um json com uma mensagem "Valor limite da devolução atingido". Contei 9 devoluções, portanto 9 centavos (até estranhei não ser um número redondo, 10 por exemplo) e queria confirmar se esse realmente é o limite. Quando a aplicação for para produção, com certeza usaremos as credenciais de uma conta PJ e é possível que, devido a regra de negócio, o volume de devoluções por dia seja maior que 9 (seriam várias transações Pix, onde cada transação teria apenas uma devolução do valor integral pago). Então já fica mais duas perguntas: há diferente entre esses limites de devolução pra conta PJ e PF? É possível negociar esses limites com a Gerencianet no caso da conta PJ?
Pensando na implementação lógica, o fluxo seria mais ou menos esse:
-> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança (talvez isso até já esteja implementado hoje).
-> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.
se a GN tiver como diferenciar quando o Pix foi enviado via "manual" (informando dados bancários) ou com uso da chave DICT, o ideal seria a configuração de aceitar/não os recebimentos com txid nulo ser por chave + uma configuração extra para bloquear todos os recebimentos manuais (que nunca tem txid associado).
se não tiver como diferenciar, a configuração poderia ser global (por conta transacional), com opção de sobrescrever a escolha para chaves individuais (assim poderia bloquear recebimentos com txid nulo para toda a conta [que seria o comportamento padrão] e autorizar o txid nulo em uma chave particular).
e, futuramente:
-> else (txid é estático), valida conforme as regras de aceite do EC (por regex match ou enviando o request de validação para webhookURL/txidmatch, como sugeri acima).
e esse "futuramente" eu não consigo nem ver uma demanda relevante. o importante são as outras funções.
Bom dia <@!620895261568401428> ! O webhook é acionado no momento em que você realiza a transação. Então esse comportamento pode ser devido a alguma falha na configuração do seu servidor. Fizemos alguns testes e esta funcionando corretamente, sem atraso.
Por enquanto só em produção.
Edit: mas você pode acionar você mesma o webhook para ver como seu sistema se comporta, só precisa fazer isso numa rota sem mTLS.
Testando aqui o funcionamento do webhook de produção. Recebendo pagamentos e fazendo devoluções. Depois de alguns vai-e-volta de centavos comecei a perceber um comportamento estranho. As chamadas no webhook chegam com 1 passo de atraso. Como se a chamada ao webhook estivesse utilizando filas e fica sempre a última transação lá na fila e não vem pro meu webhook na hora certa. Ou seja, quando faço uma transação chega a transação anterior (que não havia chegado antes) e a nova não chega. Só chegará quando eu fizer a próxima. E assim por diante. 🤔 Estou esquecendo algo?
Pessoal, trazendo para cá a discussão sobre devolução por parte do favorecido. Contexto:
Colocando lenha na fogueira, só um parênteses, continuem aí na prosa de vcs pra não embolar os assuntos... Vejo que o debate de flexibilizar o mTLS seria benéfico e cada PSP arbitraria isso junto ao cliente, por exemplo, um contrato adicional de renuncia do mTLS. Nós recomendaríamos então o cliente e vim na Gerencianet a cada Webhook certificar do status, isso é ruim para a infraestrutura, mas tratarmos algum processamento em troca de algum conforto para alguns clientes, pode ser importante para os negócios e plug-ins.
E se o uso de recursos estiver sendo ruim para a Gerencianet, abre-se dialogo com o cliente, situação que ocasionalmente ocorre.
Pessoal, hoje após 5 tentativas o webhook de notificação está sendo desativado. Isso faz com que ele precise de rearme manual; seria melhor o sistema continuar retentando para que ele se rearme automaticamente. Hoje o intervalo máximo entre notificações chega a 80 minutos, e quer seja 80, 120 ou 160 minutos de intervalo após decaimento exponencial, eu sugiro que o sistema continua tentando exatamente para evitar desarme/rearme. Se isso perdurar alguma ação manual por parte da Gerencianet talvez faça mesmo sentido, mas que por padrão o comportamento seja de reestabelecer a notificação é minha forte preferência. Que acha, <@!793123559874494465> ?
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)
para eu tentar contornar enquanto isso, o webhook pode ser em qq porta? (diferente da 443)?
