Histórico de mensagens sobre dados

claro.. digo os dados gerados..

Seguindo o sdk da GN eu passo os parametros para o metodo emitirPix, esse método emitePix depois vai em montaBrCode e em montaBrCode ele busca pelo payload $dadosPix["loc"]["location"]

Nesse momento acontece o erro 403.

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

O processo é simples 🙂 Basta pegar o endpoint criar token, depois criar cobrança com os dados do total do carrinho e esperar o webhook mandar o status do cobrança para RECEBIDA, pronto venda relizada com sucesso. Molezinha 🙂 Na duvida se estar paga é só fazer uma consulta no txid.

No extrato, em detalhes da transação, seria interessante exibir a instituição usada para a transação. O app atualmente exibe na notificação, mas no extrato não há essa informação.

É útil pra identificar os problemas, já que não são todos os bancos que estão funcionando 100%. Como o banco Inter, que mesmo o cliente pagando com QR Code, o sistema reconhece como se tivesse sido pago com chave, e os dados acabam não batendo com os da API, precisando fazer a aprovação manual do pagamento.

mas a expiração é "da cobrança", não "dos dados que vieram na leitura do location". o banco do pagador não pode guardar cache disso. o conteúdo fornecido pelo location pode se alterar. inclusive isso é documentado amplamente como "reuso de location"

Bom dia <@!498292925352902657>! As consultas na API são feitas pela cobrança e não pelo cliente. No entanto, você pode armazenar em um banco de dados as cobranças e associa-la ao nome do cliente. Você pode utilizar o endpoint GET /v1/charge/:id ou a forma mais utilizada, a nossa url de notificações

E o Payment token criptografa no navegador do cliente, assim o desenvolvedor não precisa se preocupar com a segurança e armazenamento dos dados

Se a pessoa tiver a sua url e tambem tiver todos os dados da cobrança sem você ter o mTLS, ela pode enviar um POST para a url e se seu sistema validar os dados enviados, vai interpretar que foi pago. Ja que em uma cobrança todos os dados são expostos e são abertos. Por isso a importancia do mTLS com o certificado da GN.

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

o fato da URL de cobrança ser aberta é o que vai permitir soluções como a minha obterem os dados da cobrança e formar uma página de fatura, por exemplo (mesmo eu não tendo criado a cobrança nem tendo as suas credenciais). mas por mais que eu me beneficie disso e faça um uso responsável, acho que foi errado ficar aberto.

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)

Pega esses dados na opção desenvolvimento lá no ainel da API no GN, tá faltando coisa aí, acho que você colou o label e não o conteúdo.

Sistema de Validação de Token efetuado com sucesso sem postman , após dois dias estudando, está pronto e funcional. Pequeno painel informando alguns dados importantes sobre o token 🙂 Mais uma etapa concluida 🙂 Agora é fazer na prática ( sem postman) a criação da cobrança. Novos estudos, o nome do jogo é paciência e persistência 🙂

alguém pode me dizer como faço para usar o PEM no Postman? removi o certificado e estou adicionando os dados do PEM em uma váriavel, mas está dando esse erro: Error: Invalid character in header content ["x-client-cert-pem"]. Segue imagem da variável configurada com o PEM

inseri todos os dados da conta, inclusive como pagador

ou deria os dados que estão dentro dela(o payload)?

eu gostaria de entender como funciona a regra de negocio... tipo: agora, ao invés de eu emitir o boleto, eu vou mandar os dados (que seria para missão de boleto) para o GN e posteriormente retornaria uma chave para meu cliente?

Nunca deixo chave em banco de dados ou codigos, para dificultar.

@Deleted User resumindo, quem tiver acesso ao banco de dados ou arquivo config vai receber a grana, simples assim, é só mudar a chave.