Termos mais procurados:
Importantes essas considerações de vocês sobre o que trará mais valor no momento.
Vejam se estamos falando disso:
- QR Dinâmico: valida-se se possui cobrança atrelada e o valor está correto
- QR Estático: permite ao EC aceitar ou não TxId nulo
- Pix via Chave: permite ao EC recusar ou não
- Pix Manual: permite ao EC recusar ou não
Em um segundo passo, para QR Code Estático:
- Validações de padrão do TxId
<@!440035527127990273> <@!780500321994539068>
É isso mesmo. Eu só descreveria de outra forma pq sem txid e sem a informação do método de iniciação de pagamento, saber se era um QR dinâmico, um QR estático ou um Pix via chave é impossível... ao menos até que isso venha na PACS.008 como está planejando o BACEN. Acho que só o Pix manual vem diferente.
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.