Termos mais procurados:
vamos lá:
1. o campo solicitacaoPagador é para pedir ao pagador pra digitar alguma coisa. Ele vai ver assim:
Serviço realizado.: ___________________
O que se espera que o cliente digite?! 🤔
2. o campo infoAdicionais, é exibido pro pagador como texto informativo. nesse caso de exemplo ele verá na tela do app ao pagar:
se alguém tiver algum QR dinâmico de outro PSP que não seja a GN eu posso testar. (obs: o MP acabou de atualizar o app, pode ser que estava lendo e parou)
mas é só suposição. a GN poderia confirmar se recebe o request quando tentamos a leitura no app do MP
pois é, eu forcei o meu para maiúsculo porque fiz um teste gerando um diretamente no app do itaú e ele estava maiúsculo. Depois notei que alguns outros estão em minúsculo e resolvi testar
estranho. isso não deveria influenciar.. inclusive os qr codes que gerei no app do NuBank, por exemplo, o domínio veio em maiúsculas e tanto o Inter quanto o Itaú leram
<@!780500321994539068> Acabou que o problema nos testes era a imagem do qrcode. Alguns apps não conseguiam ler o qr se ele não fosse preto e branco. Eu usava um azul bem escuro, mas por não ser preto e branco deu problema.
Nos testes que eu fiz aqui consultando os pixrecebidos pela api sempre vem o endToEndId. e no comprovante dos apps de banco tambem aparece,]
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
provavelmente atualizarão o app e ele vai se comportar igual o qr estático quando valor != 0,00
O App deixa passar por que não sabe o que será passado, e no recebimento, a regra de negocio executa as devidas validações.
Foi o próprio Santander que recusou, mesmo caso do Nubank. O app deixa mandar a transação mas o back-end deles mesmo recusou
Que é o que sugeri. Sabe se foi o Santander ou vocês que recusaram ? Pq no Nubank eu tentei fazer duas devoluções somando mais do que o valor original, e apesar deles deixarem o app mandar a transação, o back-end deles mesmo recusou por regra de negócio.
<@!781134406680838216> No APP da GN tem o campo em azul= Solicitação ao Pagador. Este retorno vem em qual campo do webhook se inserido pelo pagador ?
O APP da GN pode não estar seguindo a exigência do BR Code e aceitando o EMV apesar da falha...
<@!671762828046106646> Está correta sim a geração do BRCode ! Na função montaBrCode . Testei com o copia e cola no APP da GN e está tudo normal ! 🙂
Olá pessoal! Para BRCode dinâmico, este site https://pix.nascent.com.br/tools/pix-qr-decoder não funciona muito bem. Sugiro que, para testarem a geração do QR Code, utilizem a Collection do https://gerarqrcodepix.com.br. link da collection: https://app.getpostman.com/run-collection/98e73bcb5782024ca150
o e2eid do Pix já aparece pro pagador no app dele (na tela de confirmação e/ou no comprovante), acho que não tem nada de mais expôr em mais algum local. seria uma forma do cliente "conciliar" seus pagamentos, inclusive
