Termos mais procurados:
Estou verificando se a propriedade "endToEndId" existe e está preenchida no objeto "pix" e deduzindo as devoluções contidas no objeto para definir se o valor foi pago e, se foi pago, não houve devoluções, conforme este exemplo:
Pessoal da GerenciaNet, uma pergunta. Como vai ficar a questão do acesso ao PIX por sub-clientes? Há alguma maneira de um fluxo OAuth onde minha aplicação transaciona como outro cliente da gerencianet?
Exatamente! Fizemos o teste no Banco do Brasil e funcionou corretamente, o QRCode após o update foi lido. Em algumas instituições isso não ocorreu, por isso vamos reportar para que nossa equipe averigue essa questão
Não necessariamente. Ela pode estar apenas expirada
ao consultar uma cobrança, retornar "CONCLUIDA" significa que aquela cobrança foi paga?
<@!783359762917752843> Normal não é não. Outra pessoa com o BRCode não pagou ?
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.
Verdade <@!780500321994539068>. O Santander ao ler um qr code dinâmico está permitindo esta digitação do valor... Mas realizei um teste, inserindo um valor diferente do original, o PIX não foi pago
Obrigada Matheus, apenas para fins de registro, se eu tento atualizar novamente a cobrança com outra data de expiração, recebo esse erro:
{ "nome": "status_cobranca_invalido", "mensagem": "A cobrança não está mais com o status ATIVA"}
Se tento incorporar o status CONCLUIDA ou ATIVA junto a data de expiração, eu recebo:
{"nome":"json_invalido","mensagem":"Valores ou tipos de campo inválidos","erros":[{"chave":"enum","caminho":".body.status","mensagem":"deve ser igual a um dos valores predefinidos"}]}
Em anexo o body para verificarem que não há erro de sintaxe.
E como isso poderia ser controlado pelo PSP recebedor é com Expires, Cache-Control e Etag:
https://restfulapi.net/caching/
Por isso precisamos no nosso código validar o valor recebido, pois o simples fato de retornar "RECEBIDA" não quer dizer que será 100% baixada, se for menor, o sistema da baixa no valor pago e mostra novo BRCode, com o valor que falta para liquidar a cobrança 🙂
Exato. A única coisa que poderia permitir/negar caching seriam os cabeçalhos HTTP de quando o payload foi servido, não o conteúdo do JWS/JWT que diz que a cobrança expira na data X.
Bom saber <@!780500321994539068> !
Um alerta: PSP pagador (Santander no caso) deixando o cliente alterar o valor pago em QR-Code dinâmico. Algo para a GN e depois PSPs recebedores checarem e rejeitarem o Pix.
https://github.com/bacen/pix-api/issues/219#issuecomment-737253308
Mas eu acredito que não seja cache Renato, pois na revisao 0 li o qr no nubank apenas e ok, ja na revisao 1 li no nubank e deu erro, li no ame e tbm deu erro. Acredito que se fosse cache no ame deveria passar na revisao 1.
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"
A leitura do payload possui exatamente esta informação {"criacao":"2020-12-02T00:52:27.000Z","apresentacao":"2020-12-02T00:57:14.377Z","expiracao":"86400"},"status":"ATIVA", se é o mesmo payload tem a mesma expiração e nao a nova.
Vamos realizar os testes aqui nas instituições financeiras
ok, lí agora, realmente, então sobra o retorno do location , como tem o mesmo location , ele tem a expiração da Revisao 0
Não está Magno, a cobrança foi gerada hoje com 86400 segundos de expiração, só expira amanhã no caso...
