Termos mais procurados:
Quando uma devolução do Pix acontece com sucesso, realmente tratamos semanticamente como uma devolução. É uma movimentação prevista do arranjo Pix.
Quando você tentou enviar um Pix e não conseguiu (suponha que o PSP do outro lado recusou), nós devolvemos um dinheiro que foi debitado da sua conta mas não chegou do outro lado. Não se concretizou o Pix e, por isso, resolvemos tratar como um estorno em conta. Essa movimentação não existe no arranjo Pix. É um tratamento específico da Gerencianet.
era o que eu ia comentar. Se hoje não existe sequer um comprovante de pagamento verificável, como podemos estar falando em comprovante de devolução emitido pelo PSP? acho que é colocar o carro na frente dos bois
existem PSPs que são participantes indiretos e obtém o acesso ao DICT por meio de outro participante direto (que pode até mesmo nem ser um PSP... dando mais abertura para o Open Banking)
vc não é uma coisa nem outra. PSP é "Prestador de Serviços de Pagamento". a GN é um. e tem participação direta no SFN e acesso ao DICT do Pix
vc não lida com o DICT diretamente.. a documentação tá confusa pq cita um monte de coisa que diz respeito à comunicação entre PSPs e o BACEN
nosso testador oficial é o <@!522899003663450113> , que tem conta em todos os PSPs do sistema solar 😂
pq aí vc teria QR impresso com valor X e cobrança com valor Y (ainda assim, seria um problema só nesses PSPs em particular)
Pessoal, o que me aconselham? Envio o valor no QRCode dinâmico? Vocês possuem muitos relatos sobre PSP's que não fizeram a devida implementação?
Só para eu entender Guilherme, o PSP não deveria estar com esse comportamento. Correto? Quando dinâmico, eu não precisaria enviar o valor no EMV.
Neste caso, o PSP do pagador pode estar com este problema, onde ao ler o Qr Code, mesmo que dinâmico, ele tenta buscar o valor que está no EMV, se não estiver presente o valor fica R$0,00.
Ou seja, resta saber qual é o PSP do pagador. E como o Renato citou, verificar se o PSP está permitindo a edição do valor
Boa tarde Hiago! Se conseguir o nome do PSP, nos informe por favor. Se possível me envie o copie cola ou QRCode para eu fazer um teste aqui
se não permitir edição, aí teria que abrir um outro issue, especificando que o PSP tá deixando o valor zerado (mas não permite pagamento nesse caso)
Bom dia pessoal tudo bem? Alguém já teve problemas com o QRCode dinâmico ser apresentado com o valor zerado em alguma instituição? Um cliente enviou um print onde o valor do QRCode estava zerado... Mas é um PSP estranho, não consegui identificar pelo app para ver na lista de compatibilidade divulgada por vocês... Ainda não obtive retorno do cliente sobre o nome da instituição.
Bom dia pessoal, havia uma lista de PSP's que não estavam lendo o qrcode corretamente ou não o identificavam como dinamico, essa lista foi atualizada ?
Seu EMV tinha o campo 54 com o valor ? Apesar de não obrigatório, ajuda com PSPs com implementação ruim
acho que o status "CONCLUIDA" é reservado para atualização pelo próprio PSP quando recebe um Pix para a cobrança
você pode passar um PATCH com status "REMOVIDA_PELO_USUARIO_RECEBEDOR"
Atualizando o caso do calendario.expiracao
O problema da leitura de uma cobrança expirada ocorre da seguinte maneira:
- Existe uma cobrança ATIVA com expiração futura
- Usar a rota PATCH /v2/cob/{txid} para redefinir o tempo de expiração para um tempo passado
- Os bancos leram o qr code, mas não é possível pagar devido a rejeição de recebimento por parte do PSP recebedor (GN)
Obs.: se a cobrança já estiver com expiração vencida antes do PATCH, o leitor nem lê o qr code.
Como não é possível pagar o qr code, vejo como algo irrelevante.
Acredito que seja algo relacionado ao location, pois após o PATCH o location continua o mesmo.
Obs 2: tentei redefinir o expiracao para tempo passado porque estava tentando "excluir" a cobrança, antes do <@!440035527127990273> me alertar sobre a possibilidade de se alterar o status da cobrança via PATCH
