Histórico de mensagens em sugestões

O primeiro evento seria algo como "intenção de pagamento", e o 2o. o pagamento efetivo. A GN já comentou que está considerando oferecer essa sinalização na API de boleto, mas que hoje isso não acontece.

eu entendi sua sugestão. a minha é adicional. é que dependendo do cenário, a primeira notificação (pela CIP) é muito útil. dá pra fazer a preparação de pacote pra envio ou até a liberação de um serviço (se não houver prejuízo ou o vendedor quiser assumir o risco, caso não seja compensado com o valor esperado posteriormente)

Ficou meio estranho o seu complemento kkkkk

Na verdade o que eu queria é que fosse aprovado direto quando o boleto fosse pago pelo Gerencianet e o boleto fosse gerado pelo Gerencianet.

sim. mas o PagHiper notifica os 2 eventos. primeiro como "reservado" (CIP) e depois como "aprovado" (quando compensado)

Mas o pagamento da CIP só notifica que foi pago, não da pra saber o valor...

e até mesmo por outros bancos, como faz a PagHiper, com base na informação do comando de pagamento notificado via CIP

Pessoal, eu pago alguns boletos gerado pelo Gerencianet, não seria possível que o pagamento do boleto fosse dado baixa automaticamente quando o boleto fosse emitido pela Gerencianet? Entendo que o boleto foi emitido pelo banco e que tem todo o fluxo bancário, mas seria interessante uma confirmação na hora sempre que pago pelo sistema da Gerencianet.

Contem comigo para pensar em uma solução.

De acordo com o banco central, o favorecido pode devolver um pix em até 3 meses! A quantidade de problemas de contestação/conciliação que isso pode causar é imensa.

O cenário atual da GN não permite consultar um pix sem txid, logo não consigo buscar dados de um pix enviado via POST /v2/pix. Dessa forma, não existem maneiras de saber, via aplicação/integração, quando um pix é devolvido por parte do favorecido.

Resposta da GN:

Pessoal, trazendo para cá a discussão sobre devolução por parte do favorecido. Contexto:

Concordo. Eu estou cuidando da duplicidade do meu lado, mas seria ótimo se a API ajudasse mais neste ponto.

Portabilidade e reivindicação não são problema pq a chave continua existindo. O problema é se for feita uma remoção no outro PSP.

Sobre o pagamento/transferência via POST em /pix, eu acho que ele devia ser mudado para PUT. O POST hoje não tem idempotência, e está sujeita a duplicações... a idempotência seria garantida com um parâmetro id (similar ao id de devolução), diferente do eventual txid (que é do recebedor). Para não ter que criar muitos métodos distintos, acho que poderia ser um único... se não tiver txid ou código, a ação é de transferência. Se tiver txid ou código, é pagamento... mas são mutuamente exclusivos. Ou tem o txid, ou tem o código do Pix Copia e Cola.
No geral fica:
chave mutuamente exclusivo com banco/tipo/agência/conta/cpf , mas um deles é requerido
txid mutuamente exclusivo com código, mas é opcional.
idenvio obrigatório, e garante idempotência. Se receber duplicado, só dá erro se for diferente. <@!793123559874494465>

Pois é, teria que ser um cache do próprio PSP que faz o rateio pra garantir o destino do split. Só que aí vêm questões de portabilidade/reinvindicação que podem invalidar o cache.

Eu tinha pensado em algo para confirmar existência de chave em situações de split e envio de Pix, mas aí não funcionaria para CPF/CNPJ/chave aleatória. 😦

Agora mesmo um cliente nao estava emitindo boleto e tentei por horas atraves das mensagens e não descobrir o que era, até conectar no cliente e perceber que ele nao tinha feito a validação complementar. Não tem como esse tipo de mensagem ser retornado pra mim na api?

<@!780500321994539068> Apenas chaves do tipo EMAIL ou PHONE poderão ser consultadas pelo CheckEntry.