Histórico de mensagens sobre duplicado

Esse também deu o erro, informa duplicado

Retorna que está duplicado pelo Itaú Empresas

Saberiam me informar as causas e como prevenir isso?
Porque com esse erro alguns boletos ficaram duplicados :/

Como são cenários mais raros de acontecer, você pode entrar em contato com a nossa equipe do financeiro que os mesmo vão auxiliar no procedimento de identificar onde está o dinheiro do pagamento duplicado e como solicitá-lo.

Um ponto que pode acontecer é o banco pagador não verificar a CIP, como mencionado pelo Rubens, neste cenário o dinheiro é devolvido e fica retido na instituição que realizou o pagamento duplicado.

Boa tarde, <@!883000147938783272>. No caso não ocorre a duplicidade, pois, quando uma forma de pagamento é utilizada, ocorre a baixa da cobrança e sendo assim a outra forma de pagamento fica inviabilizada. Não tendo assim um recebimento duplicado

Ai eu iria emitir um boleto duplicado

Dá pra transformar o estático em dinâmico comando devolução de tudo que vier duplicado, valor errado etc. Mas aí tem que codar isso.

nao entendi o guid duplicado e nem o do location, pode me dizer aonde deveria estar?

esses: Não devia ter a chave, nem ter GUID duplicado, e o location está no campo errado

Mas tem erro no EMV sim. Não devia ter a chave, nem ter GUID duplicado, e o location está no campo errado.

TxId duplicado só é recusado em QR-Code dinâmico, e um pagamento pode ser estático (com ou sem txid). Eu estava pensando e acho que a API tem que ter 2 passos de forma similar à UX do app:
/gn/pagamento (BRCode[obrigatório], idpagamento[obrigatório], valor[opcional])
retorna o valor do pagamento, as informações do recebedor no DICT (eventualmente mascaradas).
Aí a próxima chamada seria
/gn/confirmapagamento (idpagamento[obrigatório],valor[obrigatório])
Tem que passar de novo o valor e o id de propósito, para dizer "eu sei que vai sair x dinheiros da minha conta".

Na chamada de pagamento, o valor opcional seria passado para caso o QR-Code estático não tenha valor associado.

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>

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"
}

Quando uma devolução é feita utilizando um id associado a outra devolução a mensagem retornada é a:

Pode ser por não ter dado match com o txidRegex, por exemplo, ou ser um pagamento duplicado...

acho que não fui claro. vou detalhar mais.

primeiro cenário, envio de Pix que falhou, eu vejo no extrato (estou colocando em ordem cronológica, inverso de como aparece no app, que é cronológica inversa):

Um comentário disso <@!775350441965649951> é que a recusa de pagamentos duplicados não pode depender do payload. Ela precisa ser feita na ligação com o SPI/PIG.

{"nome":"devolucao_id_duplicado","mensagem":"O id informado j\u00e1 foi utilizado em outra devolu\u00e7\u00e3o"}

Efetuei uma devolução parcial e depois tentei novamente do restante da transação e foi dado como duplicado.