Histórico de mensagens sobre devolução

Alguém da Efi para me ajudar com um problema na devolução do pix?

Eu acho que refunded é só por devolução iniciada. Para chargeback, seria contested e depois canceled, pelo que diz lá.

Tem sim, chama-se devolução. https://dev.gerencianet.com.br/docs/api-pix-endpoints#solicitar-devolu%C3%A7%C3%A3o

É com destino a conta da Caixa ? Isso tem sempre disponibilidade sub-ótima... inclusive para devolução.

Notar que do envio x recebimento você nem precisa olhar a chave... apesar disso ser prudente por questões de segurança. Mas para recebimento (e devolução de recebimento) mapear o handler de recebimento na configuração do webhook, e no de envio, mapear o de tratamento de eventos de Pix enviados.

De fato. Ainda me parece um pouco invertido o caminho, pois apesar de eu ter salvo no meu bd que uma devolução foi solicitada, o controller que recebe esse payload ainda não sabe disso. Então é como se eu precisasse primeiro hidratar o meu handler com contexto sobre aquele evento antes de poder tratá-lo, agregando dados de uma ou mais tabelas pra daí poder prosseguir (não que isso seja um grande problema). A sugestão que você deu sobre as chaves serem os discriminantes é um exemplo disso: primeiro eu tenho que puxar minhas chaves e aí mapear o evento.
Posso estar complicando demais, pois ainda não comecei a implementação, mas não está muito trivial arquitetar isso com o meu patinho de borracha 😅 .
Por acaso vc conhece algum repo aberto com um exemplo bacana de implementação?

Agora, de devolução o mais simples é o seu handler saber que uma devolução foi solicitada, já que é você que solicita... não vai vir de surpresa uma devolução. Então se o Pix x teve uma devolução solicitada, ou uma nova devolução solicitada (pode haver mais de uma devolução para um mesmo Pix), aí se observa o campo de devolução.

A devolução é uma atualização do mesmo objeto. Antes ele não tinha devolução, agora tem. Notar que uma devolução só acontece quando você pede, não quando o cliente pede... então de qualquer forma você nem precisaria de atualização assíncrona no webhook se a devolução sempre desse certo. Mas como pode não dar certo, por isso há uma notificacão da mudança de estado.

@rubenskuhl , o que quero dizer é que, programaticamente falando, como você diferenciaria um evento de recebimento de um evento de devolução, por exemplo?
Pelos prints, vc pode ver que o conteúdo de um evento de recebimento é um subconjunto do conteúdo de uma devolução, e parece que esse é o único critério que eu consigo usar para diferenciá-los.

O time responsável está já está atuando para trazer essa solução, mas existem algumas outras prioridades que já estavam no backlog da equipe. Qualquer novidade informaremos por aqui!
Uma sugestão seria realizar o procedimento em produção, e solicitar a devolução.
https://sejaefi.com.br/central-de-ajuda/gestao-de-cobrancas/fazer-devolucao-de-pagamento-cartao-de-credito#conteudo

Todos estes registros são retornados:

Um pesquisa ou cria uma cobrança, o outro consulta um Pix que quitou uma cobrança ou inicia uma devolução.

Qualquer critério de valor precisa ser individualizado. O que é pouco dinheiro para um cliente, é um caminhão para outro cliente...

... não é o cartão que tem 7 dias para devolução, é qualquer compra não presencial.

E além disso, o próprio cliente também consegue fazer estornos via banco, e qualquer compra no cartão de crédito tem uma "garantia" de 7 dias pra devolução

Não é possivel realizar a devolução do pagamento de um boleto. Neste caso, você precisaria de pegar informações do seu cliente e realizar uma transferencia

A Efí não tem dupla custódia (requerer dupla autorização para pagamentos e transferências saindo da conta), mas colocou a nosso pedido uma política de segurança na conta aonde só se pode fazer transferências para contas de nossa titularidade. Então endereçamos questão de segurança por aí... isso inclusive precisou ser customizado para que pudéssemos fazer devolução de Pix (que vai para outra titularidade) mas não desse para fazer Pix ou TED para outra titularidade, mesmo tendo senha/autenticador/token.

A gente consegue conciliar os pagamentos recebidos com os valores na conta usando o endpoint de extrato e o de saldo, e qualquer divergência já temos alerta no dia seguinte. É inclusive o que usamos para detectar que um MED (devolução do Pix, em parte comparável ao chargeback do cartão) não foi registrado como deveria (pois ele é sinalizado por e-mail e não pela API).

O custo da devolução é parte da tarifa já paga no recebimento.

A taxa pela transação não é reembolsada. Por outro lado, não há cobrança pela devolução como se fosse um envio de Pix, como há em alguns PSPs.

Sim, existe o MED, Mecanismo Especial de Devolução. Mas seria interessante você se certificar de ser fraude antes de acioná-lo...