Termos mais procurados:
<@!780500321994539068>
Sobre ser um endpoint diferente, é algo que traz um maior conforto até na hora de separar os casos de uso. O atual remete a transferências, o outro a pagamentos. Até pelo fato de, em uma transferência, ao enviar TxId, sabe-se lá se outro PSP vai recusar por existir (coincidentemente) uma cobrança lá com o mesmo identificador...
Sobre o acervo de assinaturas de JWT: perfeito, não teriam como validar
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.