Histórico de mensagens sobre url 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.

Gere a cobrança de cartão em desenvolvimento que o status vai ser alterado para pago e notificar a url informada. Aqui tem alguns exemplos do JSON que enviamos para cada tipo de cobrança: https://dev.gerencianet.com.br/docs/notificacoes-recebendo#section-2-1-exemplos-de-respostas-

<@!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)

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

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: