Histórico de mensagens sobre PSP

Mas esse tipo de customização precisa ser feita com cautela, e usada com parcimônia, já que em outro PSP isso não vai existir ou ser diferente.

Boa tarde <@!348725207076175872>! Você se refere ao campo solicitacaoPagador ? Em algus PSPs é ignorado esta informação enquanto que em outros ela aparece. Em qual PSP você está lendo o QRCode?

Boa tarde <@!783359762917752843>! As chaves Pix ficam salvas em um DICT que é consultado no momento do envio do Pix, se este CPF não estiver atrelado a nenhum PSP como chave, então a transação não ocorre. Ym exemplo de retorno ao consumir a rota v2/pix :

<@!522899003663450113> acredito que podemos assumir que, se webhook.notificar.envio for habilitado, a notificação do envio de Pix será enviada com a informação se foi sucesso ou falha. Em caso de falha, irá constar o motivo, que pode ser uma recusa ou timeout do PSP recebedor.

tem PSP implementando isso muuuuuito mal.. e ainda tem as opções do tipo "lembrar recebedor" guardam os dados da conta na lista de recebedor e os clientes pagam por ali em vez de ler QR code (não se dão conta de que precisamos do txid para identificar as cobranças)

Em relação a isso já que implementaram também o envio do Pix e ele é async, seria interessante criar um webhook também pra recusa do PSP recebedor...

seria para quando a Gerencianet recusar um Pix vindo de outro PSP para a sua conta GN

Uma dúvida que me deu agora é: "recusa" é quando um PSP que você enviou um PIX recusou, quando você recebeu um Pix e foi recusado ou os dois?

<@!793123559874494465> txId nas comunicações PSP/Bacen tem essa capitalização (com I maiúsculo) mas entre PSP e EC é sempre todo minúsculo txid na API então acho que ficaria melhor seguir a mesma linha aqui

É necessário que o Pix se comporte de forma alinhada aos recursos que temos no boleto, para que o modelo hibrido seja coeso, como; desconto por pagamento antecipado, vencimento (considerando feriados locais), juros e multas...

Essa coesão já está desenhada pelo Bacen, a questão que precisamos que todos os PSP's leiam as informações corretamente. A Experiência do Pix mostrou que muitos PSP's levam algum tempo para fazerem suas partes. O Bacen sinalizou que em março todos os PSP's devem ter feito seus deveres de casa, momento que a Gerencianet sentirá confortável em disponibilizar a opção de pagamento por Pix em seus boletos.

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

É do seu interesse não usar métodos proprietários que te tragam lock-in de PSP.

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?