Histórico de mensagens sobre location em pix

ok, lí agora, realmente, então sobra o retorno do location , como tem o mesmo location , ele tem a expiração da Revisao 0

Quando você muda a expiração em segundos, o location vai mudar tambem, pois gerou outro tempo de expiração, e se estiver expirada não vai aceitar mesmo.

Oi Rubens, o location não mudou, continua o mesmo, consultei na revisao 0 e 1 e se mantiveram.

Exatamente como o Rubens colocou, o location mudou ? E temos expiração, em segundos.

Só um preciosismo: as cobranças imediatas (escopo cob) não tem vencimento, mas sim expiração. Apenas as do escopo cobv (quando suportado) terão vencimento.
Mas falando do problema específico, o location mudou quando você alterou a expiração ?

Boa tarde! O dinâmico precisa do location e seu consumo se faz pela API-Pix, enquanto que o estático não tem essa necessidade e pode ser montado diretamente no QRCode. Você consegue mais detalhes aqui https://gerencianet.com.br/blog/qr-code-estatico-qr-code-dinamico-no-pix/

Se tiver o location é dinamico, senão estatico. E o dinamico precisa ter o id 62.

No meu caso configurei assim:


SSLVerifyClient require
SSLVerifyDepth 1

A principal diferença é a url location, você gerou a cobrança passando quais atributos?

estava refletindo e entendi porque os locations são abertos. para permitir a existência das soluções de "iniciação pix" por parte de empresas que não são instituição de pagamento ou instituição financeira. e aí até faz algum sentido o callback ser obrigatoriamente por um canal mTLS. dá mais controle ao processo, impedindo que eles sejam direcionados a destinos "selvagens" que não foram pre-acordados com o PSP recebedor quando a iniciação também não for via cobranças armazenadas no próprio PSP

<@!440035527127990273> acessa o location que vai baixar o arquivo, baixou aqui aqui normalmente agora.

Com o modo dev. eu consigo criar cobranças normalmente , fiz a consulta deste QR acima e retornou: {
"parametros": {
"inicio": "2020-11-28T16:01:35.000Z",
"fim": "2020-11-29T16:01:35.000Z",
"paginacao": {
"paginaAtual": 0,
"itensPorPagina": 100,
"quantidadeDePaginas": 1,
"quantidadeTotalDeItens": 8
}
},
"cobs": [
{
"calendario": {
"criacao": "2020-11-29T11:43:03.000Z",
"expiracao": 200000
},
"txid": "GSEH5xD2SF3k1KN5KoqXcQMlQxorderid",
"revisao": 0,
"loc": {
"id": "29",
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/3a3fa476e6824db58dd9a3afc1d974e7",
"tipoCob": "cob",
"criacao": "2020-11-29T11:43:03.000Z"
},
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/3a3fa476e6824db58dd9a3afc1d974e7",
"status": "ATIVA",
"devedor": {
"cpf": "12345678909",
"nome": "Francisco da Silva"
},
"valor": {
"original": "124.45"
},
"chave": "fc9a4366ff3d4964b5dbc6c91a8722d18",
"solicitacaoPagador": " Renato Frota Pix ae."
},

Blz, entendi, vou estudar mais aqui , não tem lógica ter que mudar de servidor para receber um arquivo .jws. Coisa que acessando diretamente esta mesma url da location o arquivo é baixado sem precisar de nada, isso que não entendo.

o que eu achei errado foi justamente o location estar desprotegido de mTLS (deveria haver um ponto central de autoridade para obtenção dos dados de uma cobrança quando o QR é lido, para que apenas os PSPs pudessem obter esses dados, não qualquer pessoa com acesso ao QR, assim poderia implantar limitação de consumo, por exemplo) e o webhook estar protegido (esse, não deveria ter essa exigência de mTLS, já que é apenas meramente informativo, e quem define a URL de callback já fez uso das credenciais e do canal mTLS pra isso)

$curl = curl_init();

curl_setopt_array($curl, array(
CURLOPT_URL => "https://api-pix-h.gerencianet.com.br/oauth/token",
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_HTTPHEADER => array(
"x-client-cert-pem: {{X-Certificate-Pem}}",
"Authorization: Basic Q3334f34f34f3g5355gh56hg5w6h457wg457w54w56h7w56f5f6wNzVmZGQxNGU2MDMxMjlhNTMw",
"Content-Type: application/json"
),
));

$response = curl_exec($curl);

curl_close($curl);
echo $response;

boa tarde. alguém tem uma uma URL de location de cobrança que não esteja expirada pra eu testar uma integração minha aqui?

Uma dev do GN fez uma api que retorna o qrcode pronto, vc só passa o "location" retornado na criação da cobrança e alguns outros parametros, dá uma olhada pra ver se te ajuda: https://github.com/ceciliadeveza/gerarqrcodepix

{
"calendario": {
"criacao": "2020-11-26T12:00:47.188Z",
"expiracao": "3600"
},
"txid": "k4BkPnuaJ2bmJoaZ3jpFr8ls4H",
"revisao": 0,
"loc": {
"id": "4",
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/410bac50727b408cb7a7841166beea8f",
"tipoCob": "cob",
"criacao": "2020-11-26T12:00:47.233Z"
},
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/410bac50727b408cb7a7841166beea8f",
"status": "ATIVA",
"devedor": {
"cpf": "12345678909",
"nome": "Clodoaldo Ferreira"
},
"valor": {
"original": "10.50"
},
"chave": "znGXTFizF7hQB66RWrKfnvF497",
"solicitacaoPagador": "Cobrança dos serviços prestados."
}

uma chave alterada num módulo de integração de um ecommerce vai gerar novos pedidos relativos a essa nova chave injetada. com novos locations (dessa nova chave). e novos qr codes com esses novos locations.. entendeu?

Boa tarde! Ontem eu fiz vários testes em homologação e sempre consegui fazer o PUT e pegar a chave, agora está retornado o seguinte erro na hora de acessar o "location" : {
"nome": "erro_aplicacao",
"mensagem": "Ocorreu um erro ao validar a chave"
}