Histórico de mensagens em sugestões

Seguindo padrão...

kkkkkk

Vale Português ou Inglês pra mim. Só não pode Miguxês. 😉

Ótimo, nesse caso txIdTamMin

E dinâmico que não for cobrança ativa, recusado (como já é).

Uma opção que permitiria isso com baixo risco operacional seria txIdMinLength. Se colocar o do QR-Code dinâmico, aí só vai passar dinâmico.

Isso quando o PACS.008 permitir mais informações

Ele colocou a opção "txIdRegex" "^pix", no QRCode Estático

Ah, o caso que pensei era do cara colocar um txid de propósito. Esse pode acontecer sim, basta colocar um txid de comprimento compatível com o estático. E esse permite o ataque dos centavos, só com mais trabalho.

<@!793123559874494465> uma atenção é: Se uma chave for excluída, a configuração pra ela também? (Isso supondo que seja uma chave diferente de aleatória).

Exatamente, atualmente já é assim, se o txid não existir entre as cobranças, já é recusado.

É por aí mesmo. Pensei em algo sobre txid incompatível com dinâmico(<=25) mas se o txid já não existir entre as cobranças ativas, já vai ser recusado. Então acho que é mais simples não entrar nesse mérito.

Omiti alguns atributos de outras configurações acima para facilitar a compreensão do assunto "recusar txId nulo"

Traduzindo as ideias para o input no endpoint /gn/config

A configuração ser da chave é mais interessante. Inclusive para usar as múltiplas chaves para ter lógicas de cobrança distintas.
A única coisa não vista acima é que um txid de estático poderia ser recusado numa chave configurada para só aceitar dinâmico.

> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.
Estou gostando disso.

> Ah, e sempre com a exceção - nem configurável - de que se a titularidade de origem é a mesma do recebedor, a transação é aprovada.
Perfeito!

> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança
Sim, isso existe!

Ah, e sempre com a exceção - nem configurável - de que se a titularidade de origem é a mesma do recebedor, a transação é aprovada.

Pensando na implementação lógica, o fluxo seria mais ou menos esse:

-> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança (talvez isso até já esteja implementado hoje).
-> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.

se a GN tiver como diferenciar quando o Pix foi enviado via "manual" (informando dados bancários) ou com uso da chave DICT, o ideal seria a configuração de aceitar/não os recebimentos com txid nulo ser por chave + uma configuração extra para bloquear todos os recebimentos manuais (que nunca tem txid associado).

se não tiver como diferenciar, a configuração poderia ser global (por conta transacional), com opção de sobrescrever a escolha para chaves individuais (assim poderia bloquear recebimentos com txid nulo para toda a conta [que seria o comportamento padrão] e autorizar o txid nulo em uma chave particular).

e, futuramente:
-> else (txid é estático), valida conforme as regras de aceite do EC (por regex match ou enviando o request de validação para webhookURL/txidmatch, como sugeri acima).

e esse "futuramente" eu não consigo nem ver uma demanda relevante. o importante são as outras funções.