Histórico de mensagens sobre location

:443>
ServerName idelivery.autum.com.br
ServerAlias .idelivery.autum.com.br
DocumentRoot /var/www/autum-idelivery/public

Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
Require all granted


SSLEngine on
#SSLCertificateFile "/etc/apache2/ssl/certificates/idelivery.autum.com.br.crt"
SSLCertificateFile "/etc/letsencrypt/live/idelivery.autum.com.br/fullchain.pem"
#SSLCertificateKeyFile "/etc/apache2/ssl/certificates/idelivery.autum.com.br.key"
SSLCertificateKeyFile "/etc/letsencrypt/live/idelivery.autum.com.br/privkey.pem"
SSLCACertificateFile "/etc/apache2/ssl/certificates/chain-pix-gerencianet-prod.crt"
SSLVerifyClient none


#SSLCACertificateFile "/etc/apache2/ssl/certificates/chain-pix-gerencianet-prod.crt"
SSLVerifyClient require
SSLVerifyDepth 3


ErrorLog ${APACHE_LOG_DIR}/autum-idelivery-error.log
CustomLog ${APACHE_LOG_DIR}/autum-idelivery-access.log combined

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"
),
));

pela documentação do BACEN, bastaria vc cadastrar uma query string vazia no fim, como .../algumarquivo.php?pix= e o request chegaria em .../algumarquivo.php?pix=/pix (aí é só ignorar essa query string que vai chegar como $_GET['pix'] e valor /pix no seu script). mas pelo que o <@!671762828046106646> disse, parece que a GN (que hoje não segue a documentação e tá em busca de se adequar) tá planejando implantar de outro jeito (e o planejado ainda tá fora do padrão.. mas disseram que consultaram o BACEN, então boiei geral), aí só vc tendo controle total sobre os locations e configurando uma rota pra apontar pro seu algumarquivo.php específico...

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

Você poderia utilizar um Location diferente em seu servidor para cada cliente respectivamente, como o Rubens informou.

Isso mesmo, Renato. <@!585695073908293632>, pode ter sim SSL Lets Encrypt.

Neste caso, para que funcione em sua URL, você deve especificar a rota para exigir o certificado somente na rota /webhook. Da forma que está utilizando, irá exigir certificado a qualquer rota da sua URL

Para isso, para configurar utilize:

Equipe GN, calendario.criacao seu valor deve ser alterado em uma atualização (patch) da cobrança Pix? Eu tenho um caso, em que a cobrança foi criada em um datetime A e ao consultar e decodificar o payload (location) é retornado um datetime B

O que volta no location é um dos campos que você vai usar para construir o QR-Code

e no json de retorno para obter o qrcode eu olho o link retornado no campo "location"?

Uma passada rápida só pra divulgar uma mudança substancial no https://pix.ae: agora os QR Codes gerados (tanto pelo site quanto pela API) terão apenas o símbolo do Pix por padrão. Apenas os QR codes dinâmicos (com URL de location) criados pela API e injetados diretamente em sistemas externos continuam com o logo do Pix.ae (o que pode ser negociado para remoção / substituição por outra marca).

Atualizando o caso do calendario.expiracao
O problema da leitura de uma cobrança expirada ocorre da seguinte maneira:
- Existe uma cobrança ATIVA com expiração futura
- Usar a rota PATCH /v2/cob/{txid} para redefinir o tempo de expiração para um tempo passado
- Os bancos leram o qr code, mas não é possível pagar devido a rejeição de recebimento por parte do PSP recebedor (GN)

Obs.: se a cobrança já estiver com expiração vencida antes do PATCH, o leitor nem lê o qr code.
Como não é possível pagar o qr code, vejo como algo irrelevante.
Acredito que seja algo relacionado ao location, pois após o PATCH o location continua o mesmo.

Obs 2: tentei redefinir o expiracao para tempo passado porque estava tentando "excluir" a cobrança, antes do <@!440035527127990273> me alertar sobre a possibilidade de se alterar o status da cobrança via PATCH

Você não vai usar o payload em si. Só o location dele.

Quando você cria o PUT /cob/:txid está criando um QRCode Dinâmico. Ele contém um location que o PSP Pagador usa para pegar o payload da cobrança.

Pessoal uma dúvida, eu poderia no location do br-code passar um endpoint meu que retorna o conteúdo da gerencianet? Assim eu conseguiria ter uma UX mais bacana (detectando a leitura). Isso é permitido?

eu tenho a sensação que o qr dinâmico (e sua cobrança associada) tinha sido pensado para admitir múltiplos pagamentos e, posteriormente, reavaliaram a questão e passaram a tratar de forma mais próxima a um boleto registrado onde o valor pago deve ser igual ou maior (quando houver multa/juros) ao boleto, especialmente depois que mencionaram a ideia do "reuso de location", que serve para o propósito de cobranças recorrentes de um mesmo devedor com valores que podem variar (contas de consumo, por exemplo)

Sim eu entendi, era pra o Magno. De qualquer forma da para configurar no Nginx com o location.

se vc quiser segredo em relação à URL, é só usar um subdomínio não previsível ou um nome diferente de /webhook para o location

vc provavelmente vai precisar fazer assim:
- criar o diretório /webhook/pix e colocar o arquivo dentro, com o nome index.php
- cadastrar a URL https://gn.seusite.com.br/webhook
- o request irá para https://gn.seusite.com.br/webhook/pix (e cairá no index.php, pois já deixei o location /webhook configurado para buscar o index.php dentro dos diretórios solicitados, mesmo quando a URL do request não encerrar em /)

Você pode seguir a ideia do Rubens e informar 2 paths pelo Location, um para as notificações de boletos e outro pelo Pix. As notificações da nossa API seguem um padrão onde você insere em seu servidor um arquivo para consultar o nosso token, veja mais detalhes aqui de como é o arquivo de consulta e exemplos de notificação por aqui https://dev.gerencianet.com.br/docs/notificacoes-recebendo .

Para as configurações da API-Pix é necessário o mTLS para receber as notificações que seguem um padrão diferente, não sendo necessário um arquivo de consulta de token, uma vez que enviamos um objeto pix já com todas as informações.