Histórico de mensagens sobre url

Realmente, como o Renato citou. A URL para o payload é qrcodes-pix-h.gerencianet.com.br/...

Como eu não tinha feito nada de webhook para receber os retornos sem o postman e com o postman, fiz logo direto a geração do BRCode sem postman e agora vou fazer a parte da inclusão da url e do recebimento do retorno do webhook da GN, o que estava parando tudo era o ID 62 que está errado no SDK 😦 E o bendito do error 403 forbidden no dev do payload.

"Se preferir, você pode também receber os dados no formato JSON, bastando incluir o parametro "json=true" na URL:"

o estático tem todas as informações (chave, valor(opcional), descrição(opcional), nome do recebedor(precisa estar presente mas pode ser "Pix"), cidade do recebedor(precisa estar presente mas pode ser "Pix"), txid(opcional).

o dinâmico é associado a uma cobrança gerada via API e só contém o URL de location de onde o PSP do pagador (quando ele ler o QR) vai obter os detalhes da cobrança (outras informações podem estar no QR mas são opcionais e serão descartadas, invariavelmente).

é que o Banco Inter da um explode em br.gov.bcb.pix para pegar a url 😉

É que o reference label é esse campo, essa norma server justamente pra não acessar a url e obter os dados, é uma "eliminiação prelimitar"

o estranho é que quando eu colo no navegador o "location" ele baixa um base64, mas quando uso via curl no PHP ele sempre da forbiden

mas você pode montar o brcode / qrcode sem "ler" a url do payload. é só usar o nome "Pix" nos campos nome/cidade (e o txid, de qualquer forma, tá errado no sdk da GN, deveria ser apenas e não o txid da cobrança recuperado do payload, pois ele estoura o limite EMV para este campo que é 25 caracteres)

Ok, notei agora que é em uma url, lí apenas o codigo de retorno.

seu servidor, fora do país, consegue abrir uma URL de payload?

Pode fazer um curl com while 1 repeat.

o campo 26-25 do QR Code é simplesmente a URL do payload sem "https://"

então, o payload vem da url do payload..

o montaBrCode não devia depender da leitura do url do payload. o QR só precisa ter o payload, nada mais. os demais campos podem ser omitidos ou ter dados 'placebo' quando obrigatórios.

Por isso que penso que pode ser algo de concorrência... talvez leve alguns minutos para que a url fique pronta.

Sim, pegando a url e consultando no mesmo método getPayload, retorna...

Exato, ai voce entrando diretamente na url do payload, baixa normal. Desde Domingo que tento entender isso 😦

Exatamente, ai entrando direto na URL, baixa o .jws e temos os dados, vai entender isso.

você não precisa abrir e ler esse URL do payload do seu lado. apenas o banco do cliente precisa conseguir ler um QR que o contenha.. é só colocar ele no QR e dar pro cliente pagar. o meu cenário é específico e eu preciso conseguir ler por estar fora do fluxo que gera/lê o payload "recebedor -> psp recebedor -> psp pagador" (app externo que gerencia os qr codes e precisa ler os detalhes da cobrança como se fosse um app de PSP recebedor para poder montar a página da fatura) (https://pix.ae) -- no ambiente produção tá funcional, então beleza. o problema é justamente a minha clientela que quer homologar a GN e não tá conseguindo. a fatura não abre pq o payload retorna 403 a partir do meu servidor

<@!671762828046106646> estou tendo esse mesmo erro em homologação. não consigo ler o URL de payload a partir de alguns IPs. da minha conexão local funciona, de um outro IP, também; mas de vários outros que testei, retorna 403. Tá batendo em alguma regra geral que retorna 403 na maioria das vezes. No ambiente de prod não consegui replicar (um mesmo IP que não consegue ler o payload homologação, consegue ler o produção)