Histórico de mensagens sobre devolução

A devolução aparece no extrato da conta, mas entendo a necessidade do retorno via API. Podemos levar ao canal <#💭sugestões> essas informações debatidas.

Não acho que o webhook padrão deva ser acionado, pois ele pode conter código que não entenda esse tipo de devolução. Acho que um outro webhook poderia existir, por exemplo /gn/webhooksendpix para configurar, e que mandaria o e2eid apenas. Caberia ao consumidor da API fazer match com o sendpix que teve devolução de algum valor.

Boa tarde Rafael, quando ocorre uma devolução de um Pix, que foi feito pelo endpoint de Envio de Pix, não é acionado o webhook mesmo. Por ser um endpoint elaborado pela Gerencianet, a devolução ficou de fora, independente do banco que está "devolvendo".
Eu entendo essa necessidade e vamos discutir como aborda-la.

Pessoal, uma dúvida sobre devolução de pix.
1. Pix enviado da GN > Chave qualquer. Recebo o webhook com a realização ou não. Tudo certo.
2. A partir da conta "favorecida", faço a devolução do pix.

Essa devolução por parte do "favorecido" deveria ativar o webhook e notificar minha aplicação? Entendo que a devolução esteja atrelada ao e2eid original.

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>

Sim, só fique atento a devolução, quando uma é feita nós enviamos uma nova notificação contendo um array de devolução para o mesmo Pix.

Então é aconselhável realizar um loop mesmo, tanto no array "pix", e principalmente em "devoluções", que pode ocorrer de ter mais de uma devolução parcial

Ocorreu um erro ao solicitar devolução
nome: erro_aplicacao

Boa tarde @Deleted User! O status do exemplo 1 refere-se ao status da devolução. No exemplo 2 é o recebimento de um Pix e por isso não tem status.

Neste caso, <@!783359762917752843> deve ser realizada uma nova devolução

No caso do NAO_REALIZADO devo criar uma nova devolução, a GN não tenta devolver outra vez?

Quando você realiza uma devolução o status pode ficar EM_PROCESSAMENTO, pois, necessita da comunicação com o segundo PSP e a transação pode ser aceita ou recusada nesse tempo de análise.

O NAO_REALIZADO é o status que ocorre quando uma tentativa de devolução é feita, porém, o PSP recusa a devolução.

recebemos um estorno de uma devolução.

então o primeiro exemplo foi pago e devolveram, e o segundo exemplo foi apenas pago sem devolução, correto?

Neste caso <@!796357857355890709>, os dois exemplos que citou são referentes a pagamentos confirmados.
O próprio array "pix" é a confirmação do pagamento, onde o endToEndId é o identificador do mesmo.

No caso, o primeiro exemplo como possui o array devolucoes, quer dizer que este Pix foi pago, mas ouve uma devolução, que pode ser parcial ou total.

1- Ao criar uma cobrança, você pode consultar o pagamento pelo endpoint /v2/cob/:txid e verificar se a mesma está com o status CONCLUIDA. Outra alternativa é o webhook para notificarmos o seu sistema de forma automática sempre que ocorrer um pagamento ou devolução de Pix.

2- Cada cobrança(dinâmica) tem obrigatoriamente um txid associada a ela e um E2EID que é retornado quando transita na PACS002, PACS004 e PACS008. Então sim, cada Pix é diferente e tem seu identificador próprio.

3- No momento não tem como "forçar" pagamentos em ambiente de homologação, mas já está em nosso backlog essa funcionalidade.

Me parece que não aceita requisições de devolução seguidas, com menos de 15s de intervalo.

erro_aplicacao - Ocorreu um erro ao solicitar devolução

meu problema é identificar quando há um erro ao fazer a devolução e tentar fazer novamente, mas como não sei quais erros podem ocorrer, poderia cair num loop infinito.. porque o erro pode ser:

{
"nome": "devolucao_id_duplicado",
"mensagem": "O id informado já foi utilizado em outra devolução"
}

só terei uma devolução no valor integral..