Termos mais procurados:
Seria uma solução para esse caso, ocorreram 5 casos comigo, isso poder ser por um usuário estar utilizando o app desatualizado. Mas o mais bizarro foi Pix recebido via dados bancários. Sendo que esses dados não foram divulgados.
Por isso Isadora, rejeitando todos os pagamentos que não tem txid o usuário terá que usar outro App que informe o txid, o que acontece hoje é que o usuário lê o qrcode, paga, o app não informa o txid mas o usuário pagou..
Existe a possibilidade de não aceitar o pagamento quando não for enviado o txid ou quando o cpf do pagador for divergente do devedor?
- Nesse caso a cobrança continuaria ativa para que o usuário pudesse usar a conta dele para pagar ou usar um app que envie o txid.
mas se forem compras, o certo seria o seu cliente pagar pelo novo qr code gerado, não pelo histórico do app deles
Aqui o usuário fez um pagamento via QRcode primeiro, o segundo foi ou via chave ou via dados bancários.. Mas no comprovante de pagamento não aparece chave nem dados bancários... (ocorreu no bradesco e santader) acredito que o app deles tenha uma funcionalidade para salvar favoritos.. aí nos próximos ja envia para chave..
Sim, eu sei, quando eu gerar a devolução, tudo bem... mas nesse caso, a devolução foi feita no app da GN.. porém o código de transação que aparece no PagBank é diferente.. não consta em devolucoes => []
<@!783359762917752843>, verifiquei sim esta sua demanda.
Realizei vários testes, e constatei que realmente uma devolução realizada através do app, não é possível consultá-la através da rota /v2/pix/:e2eId/devolucao/:id
Acredito que isso acontece para evitar consulta excessiva. Pois para consultar a rota citada acima, necessita saber o id da devolução. Neste caso então, você não terá este id.
Com isso terá primeiro que realizar uma consulta na rota /v2/pix/:e2eId para obter o id da devolução, e nela você já possui todas as demais informações da devolução, não tendo necessidade de realizar outra consulta na rota /v2/pix/:e2eId/devolucao/:id
Mas de qualquer forma, levantamos esta questão para nosso time da API para melhor esclarecimento.
a validação de CRC é importante principalmente nos QR codes estáticos. pois um caractere lido errado pode ocasionar (extrapoladas as probabilidades, mas ainda é possível) um pagamento pro destinatário correto (verificável pelo pagador na tela do app) com txid incorreto (difícil ou até impossível de ser verificado, se não tiver essa referência fora do próprio QR pra ele conferir), ou recebedor + txid correto mas valor incorreto, etc...
nos QR codes dinâmicos o conjunto recebedor + txid + valor vem todo do payload, então se a leitura do QR for errada, vai carregar um conjunto todo diferente, o que é um problema muito menor
E sobre o meu problema? rsrsrrs gostaria de consultar uma devolução.. as devoluções criadas via app não estão disponíveis para consulta?
Consigo criar uma devolução em ambiente de homologação?
Só passando aqui a contribuição da <@!513728938414047232> da falha : The SSL connection could not be established. A solução encontrada foi passar o certificado no HttpClient através de um handler:
Boa tarde pessoal!
Alguém teve erro ao gerar valores com centavos? - Já reportei isso antes, mas não obtive resposta.
Os valores de 1.09, 1.16, etc.. Nos apps (PagBank e Banco Inter) o qrcode é lido corretamente, mas ao pagar ocorre o erro. <@!781134406680838216> conseguem identificar?
Também tive erro na leitura do qrcode no valor de 2000.00, mas nesse caso me parece mais bug do PagBank do que outra coisa..
blz, entao o app do PSP vai estar preparado para dar o get na URL e obter o payload JWS... Entendi, muito obrigado!
<@!781134406680838216> #ficaadica, o banco Inter pelo app da acesso ao banco de imagens dos dispositivos para selecionar uma imagem de BRCode, facilitando muito a UX.
Usei o Curl da Lib PHP, com pequena adição de logs, segue o Curl usado:
