ola pessoal ainda estou com a mensagem
"nome": "webhook_invalido",
"mensagem": "A requisição na URL informada falhou com o erro: UNABLE_TO_VERIFY_LEAF_SIGNATURE"

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]

Vendo essa URL aí e o comentário do Renato lá fez sentido pra mim o porquê de vocês pedirem ela no final de tudo mesmo.

e essa aqui <@!671762828046106646> , já sabem como ficaria o resultado da url?

só sei que... "/pix" não será um script ah n ser que você faça um url rewrite

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)

agora o pessoal ta lascado mesmo tendo que escrever url rewrite hahah

galera desculpa pela pergunta simples, mas nao consegui achar uma resposta na documentação. Quando eu crio uma cobrança eu recebo uma url qrcodes-pix.gerencianet.com.br/v2/840c87cd1... e quando acesso ela é feito o download de um arquivo, qual o procedimento para gerar o qr code? Imagino que devo ter que gerar isso do meu lado

<@!797900884436582411>, estava lhe respondendo. Realizei alguns teste neste momento. Agora a requisição que está fazendo está correta! Realizei teste com minha URL e funcionou corretamente. Agora será algo em seu servidor. Estou analisando o que pode ser o erro UNABLE_TO_VERIFY_LEAF_SIGNATURE

Diego, tem como informar como está o path ao seu certificado?
CURLOPT_SSLCERT => ?

a brecha que existe - pouco explorável - é que outros clientes podem definir a sua URL de webhook para as chaves deles, e recebimentos deles acionarem o seu webhook intencionalmente

Bom dia pessoal,

Estou recebendo este erro abaixo na consulta da notificação, o request trava por mais ou menos um minuto e retorna este erro:


504 Gateway Time-out

Rodei o código aqui duas vezes de criar o url de notificações, sem querer, kkk ai só queria saber o comportamento

Só não ficou claro pra mim o envio de duas urls de notificação. Só é permitido o envio de uma e se quiser alterar posteriormente você pode consumir a rota PUT metadata

Você pode definir uma única url de notificação, vamos enviar para elas as atualizações dos status de cada cobrança gerada. Cada uma com um token único

Boa tarde pessoal tudo bem? A url de notificação eu preciso gerar a cada pedido ou apenas uma única vez? Se eu mandar a URL sem querer duas vezes, vou receber duas notificações ou 1 sobrescreve a outra se for igual?

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);
}

nome: developmentCertificate.pem
url: https://api-pix-h.gerencianet.com.br/oauth/token
"sandbox": true

Você está utilizando o certificado de produção ou homologação? Como está a URL da requisição?

Essa url está incorreta, o txid referenciado tem menos de 26 caracteres, isso não é possível devido a regex do dinâmico ^[a-zA-Z0-9]{26,35}$