Histórico de mensagens em pix

Como diria o Silvio Santos, bem bolado, bem bolado!!!

Ótimo, mais uma opção, é que quero deixar o BRCode montado também, para entender todo o fluxo em casos de duvidas em implementações 🙂

ou usa o meu serviço, campeão. é só fazer um POST para https://pix.ae com tipo=dinamico e location=qrcodes-pix.gerencianet.com.br/......... (pode mandar com https:// incluido, o serviço retira) e receber de volta o QR montadinho 🙂

No caso montando com base neste, correto ? = https://github.com/dongri/emv-qrcode

Estoura os 25 caracteres. Põe o txid que é maior do que 25, pois é de dinâmico.

como que a GN monta? sem o campo? ou estoura os 25 caracteres?

Boa notícia: consegui pagar um QR de produção da GN via C6. Já é candidato para colocar na lista de bancos ok, assim que o <@!671762828046106646> nos confirmar que recebeu o txid. Ou que pelo menos não dá erro sempre, caso haja alguma intermitência ainda a ser detectada.
Porém, eu tive que remontar o EMV. Com a imagem gerada pela GN dá problema por causa da validação do BRCode. Montando um EMV com o campo de identificador como funcionou.

E as falhas no qrcodes-pix-h dificultam também a resolução de problemas de interoperabilidade. Um PSP que ainda está recusando GN pediu um código de homologação e eu passei, mas a chance de ter tido problema no download é significativa.

quer dizer.. mesmo que mexam na SDK, eu ainda estou prejudicado

Obrigado pela atenção, Guilherme. Porém, favor esclarecer se você está se referindo a mexer no SDK (que é algo opcional) ou corrigir a disponibiliade do qrcodes-pix-h (que é essencial não apenas para a SDK como está hoje mas também para integradores externos - como euzinho!)

Claro <@!440035527127990273>, entendi. Iremos analisar a sugestão para tais melhorias. Obrigado!

alguém poderia se valer daquele campo do brcode para algum ref-label interno, mas jamais isso poderia constar da documentação

o BACEN complicou mais ainda dando exemplos com txid errado

sim. no dinâmico deveria ser exigido apenas o location, já que ele é a fonte absoluta de informação e os demais conteúdos do qr code devem ser ignorados.

Mas o <@!440035527127990273> tem razão, não seria necessariamente chamar o getPayload para montar o brCode, antes do metodo montaBrCode existe o metodo verficaFalhas() .. não são as mesmas validações?

Sim, seria bom atualizarem e colocar como opcional. Mas o que não pode é colocar com mais de 25 caracteres, violação do BRCode. Que é o problema da função atual da parte acessória da API.

pois significa "obtido de outra fonte" e no estático não tem como ser obtido de outra fonte

pelo menos no caso do estático.

Sim. E deveria aceitar a omissão, no meu ponto de vista. Não atualizar o BR Code foi preguiça, IMHO. 😂

nesse caso, corrigir a leitura dos payloads, por gentileza, pois em ambiente de homologação o sdk que vocês mesmo fornecem, falha na maioria dos casos, pois o qrcodes-pix-h retorna 403 para a maioria dos IPs