Termos mais procurados:
Termos mais procurados:
Usei o sdk de vocês, o curl e o postman
Confere se esta enviando algo assim:
CURLOPT_URL => 'https://....',
CURLOPT_PORT => 8443,
CURLOPT_SSLCERT => $codificado,
CURLOPT_SSLKEY => $decodificado,
CURLOPT_CAINFO => $codificado,
CURLOPT_SSL_VERIFYPEER => false,
CURLOPT_SSL_VERIFYHOST => 0,
CURLOPT_FAILONERROR => 1,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => '',
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_CUSTOMREQUEST => 'POST',
Lembrando o informativo enviado:
Informativo sobre à adequação do /pix no webhook
Foi estabelecido que ao realizar o cadastro do webhook base pelo integrador, ocorrerá a adição do parâmetro /pix no POST {$request.body#/webhookUrl} pela Gerencianet no momento do disparo das requisições.
Abaixo trazemos alguns exemplos de webhook's e como será a notificação após esta mudança:
Integrador cadastrou a url base https://gerencianet.com.br, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.
Integrador cadastrou a url base https://gerencianet.com.br/pix, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix/pix.
Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/?id=0000x22/pix.
Seguindo então a nossa documentação o serviço será POST {$request.body#/webhookUrl}/pix.
Tal definição foi feita após analisar os feedbacks de integradores, questionamentos ao BACEN e discussões internas.
A data para deploy do novo padrão está alinhada para o dia 08/02/2021. Sendo esta arbitrada a fim de que todos os integradores da API-Pix que utilizam o serviço de webhook possam ajustar seus sistemas e aplicações, e evitar assim falhas ou mal funcionamento do serviço.
Uma sugestão é permitir o recebimento da notificação em ambos os modos: com e sem /pix. Dessa forma, quando virarmos a chave, não haverá problemas.
Quaisquer dúvidas referentes a esta transição, estamos a disposição em nossos canais de comunicação.
<@!664563985885954079>, tente enviar a requisição passando o body da seguinte forma:
CURLOPT_POSTFIELDS => json_encode([
"webhookUrl" => $url
]),
curl_setopt_array($curl, array(
CURLOPT_URL => $_ENV["PIX_URL_AUTH"], // Rota base, desenvolvimento ou produção
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "POST",
CURLOPT_POSTFIELDS =>"{\r\n \"grant_type\": \"client_credentials\"\r\n}",
CURLOPT_SSLCERT => $arq_certificado, // Caminho do certificado
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_HTTPHEADER => array(
"Authorization: Basic $authorization",
"Content-Type: application/json",
),
));
Bom dia pessoal! Ainda sobre essa questão.
Eu consegui contornar criando um arquivo .php independente, em outro vhost, embora usando o "mesmo arquivo .conf", alterando apenas o subdominio. A conclusão que cheguei, foi a de que, por meu projeto original ser um framework (laravel), o mesmo se utiliza de arquivos .htaccess pra obfuscar a URL. e de alguma forma, isso interfere no processo de handshake da autenticacão mútua.
Então: Criei outro vhost, com certificado proprio no subdominio, recebendo o POST do webhook da GN, e retransmitindo para meu app principal via requisição post. Isso é provisório enquanto descubro o "ponto de falha" entre o framework e o protocolo mTLS.
curl_setopt_array($curl, array(
CURLOPT_URL => "https://api-pix-h.gerencianet.com.br/oauth/token", // Rota base, desenvolvimento ou produção
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "POST",
CURLOPT_POSTFIELDS => '{"grant_type": "client_credentials"}',
CURLOPT_SSLCERT => $config["certificado"], // Caminho do certificado
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_HTTPHEADER => array(
"Authorization: Basic $autorizacao",
"Content-Type: application/json"
),
));
Boa tarde @everyone, sobre à adequação do /pix no webhook, ficou definido que será feito o cadastro do webhook base pelo integrador e a adição do parâmetro /pix no POST {$request.body#/webhookUrl} pela Gerencianet no momento do disparo das requisições.
Abaixo trazemos alguns exemplos de webhook e como será a notificação:
Integrador cadastrou a url base https://gerencianet.com.br/, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.
Integrador cadastrou a url base https://gerencianet.com.br/pix, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix/pix.
Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/?id=0000x22/pix.
Seguindo então a nossa documentação o serviço será POST {$request.body#/webhookUrl}/pix.
Tal definição foi feita após analisar os feedbacks de integradores, questionamentos ao BACEN e discussões internas.
A data para deploy do novo padrão está alinhada para o dia 01/02/2021. Sendo esta arbitrada a fim de que todos os integradores da API-Pix que utilizam o serviço de webhook possam ajustar seus sistemas e aplicações, e evitar assim falhas ou mal funcionamento do serviço.
Uma sugestão é permitir o recebimento da notificação em ambos os modos: com e sem /pix. Dessa forma, quando virarmos a chave, não haverá problemas.
À medida que se aproximar da data de deploy seremos mais assíduos nas notificações. Quaisquer dúvidas estamos a disposição em nossos canais de comunicação. [ATUALIZADO]
Não entendi esta:
Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix?id=0000x22
A possibilidade mais simples de contornar a concatenação do /pix que a documentação força é justamente colocar um ?x= ao fim da URL para ficar ?x=/pix.
então pergunto:
1. qual a razão para agregar o /pix "no meio" da URL que foi definida pelo integrador e não no fim?
2. isso vai contra a documentação atual que diz que o /pix irá (sempre) no fim da URL - e se for pra mudar o conceito, seria melhor que esse /pix fosse retirado.
e sugiro aos integradores que estão lendo agora: não usem query params na URL do webhook conforme esse exemplo (prefiram path params)
function getAccessToken($pix_url_auth, $arq_certificado, $client_id, $client_secret)
{
/
# Esta rotina consome um endpoid POST da Gerencianet para realizar a geração do AccessToken
/
$curl = curl_init();
$authorization = base64_encode("$client_id:$client_secret");
curl_setopt_array($curl, array(
CURLOPT_URL => $pix_url_auth, // Rota base, desenvolvimento ou produção
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "POST",
CURLOPT_POSTFIELDS => '{"grant_type": "client_credentials"}',
CURLOPT_SSLCERT => $arq_certificado, // Caminho do certificado
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_HTTPHEADER => array(
"Authorization: Basic $authorization",
"Content-Type: application/json"
),
));
$response = curl_exec($curl);
curl_close($curl);
return json_decode($response, true);
}
Entendi.
Estou nesta parte do webhook, configurei um arquivo para receber a notificação e verifiquei se meu servidor possui o TLS 1.2 e nesta parte creio que esteja tudo certo. Mas estou com dúvidas sobre o certificado, tentei associar uma url a uma chave pelo postman, porém me respondeu isso:
{
"nome": "webhook_invalido",
"mensagem": "A autenticação de TLS mútuo não está configurada na URL informada"
}
Isso acontece por causa de alguma configuração no meu servidor que estou deixando de fazer?
Supondo que gero um pix, com a chave x, porém eu efetuo o pagamento sem utilizar o brcode, mas a chave continua sendo x; pelo fato do webhookUrl estar vinculado a chave x, a gerencianet enviaria um post para meu servidor ou apenas quando eu efetuo o pagamento utilizando o payload disponibilizado por vocês?
Estou tentando fazer os dois em uma unica URL, ai quero identificar se é boleto ou PIX e trabalhar com o Adapter para resolver o tratamento de dados, nas nao sei como é estes dados que chega do WebHook da GN se alguem tiver um exemplo de JSON do POST do WebHook ajudaria
Verifica a URL se está certa, no Postman tb da para gerar o Curl do PHP ou outra linguagem se preciso para testar
você está passando os dados do Body ?
no php e etc direto pelo curl vc passa o path do certificado, mas no postman ta diferente
tenta utilizar esta url no postman e informe o valor: https://api-pix.gerencianet.com.br/v2/pix/E18236120202012130408s0636219IRW/devolucao/1
Antes de dormir escreva no seu diário "FIZEMOS PROGRESSO" depois de muitos desafios, obstáculos, pedras, erros, deixo registrado na novela "A SAGA DO PIX" mais um capítulo de sucesso 🙂 Agora posso receber em servidor compartilhado , em qualquer sistema que nele esteja e em qualquer pasta e url as notificações da GN, sem precisar de mTLS, certificado, tokens, direto no banco de dados as respostas :). A Luta foi grande, mais ganhamos a batalha, não somos HE-MAN nem SHE-HA, mais temos "A FORÇA" de todos aqui , agradeço muito, sem vocês isso não teria acontecido nesta velocidade, pois cada um tem a sua. Muito Obrigado. Agora é partir para as brincadeiras nos sistemas em qualquer servidor em qualquer lugar com qualquer linguagem para receber os retornos do webhook .
Usei o Curl da Lib PHP, com pequena adição de logs, segue o Curl usado: