Termos mais procurados:
Sobre o serviço pra barrar recebimentos sem txid, queria reforçar com vocês que ele já esta sendo trabalhado pelo nosso beckend conforme o roadmap (https://www.notion.so/Endpoint-de-configura-es-0a97faee68f845ab96ec21551862fe6c)
Boa tarde, estou iniciando uma avaliação da solução da GerenciaNet para recebimento de Pix. Inicialmente estou tentando autenticar utilizando a Collection Postaman "OAuth", mas estou recebendo a mensagem "INCORRECT_PASSWORD". Acredito que segui a documentação. Alguma dica?
A taxa de recebimento no cartão de crédito que me assustou um pouco.
Experimente fazer um get em /pix com inicio = minuto do recebimento segundo 0 fim = minuto do recebimento segundo 59
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.
bom dia. voltando à questão do regex para aceitar/não os recebimentos com base no txid. alguém da GN pode me esclarecer quais os cenários específicos onde vocês visualizaram uma necessidade de aceitação com base em regex? que eu me lembre, essa ideia apareceu como como uma evolução da necessidade de barrar recebimentos com txid vazio. porém:
- para recebimentos de cobranças (QR dinâmico) o txid precisa ser correspondente a uma cobrança existente na GN ou ela já poderia ser descartada (independente de qualquer crivo por parte do EC); e
- para recebimentos de QR estático, é perfeitamente compreensível que a GN não tenha ciência prévia dos txid dos recebimentos mas não vislumbro problemas maiores que exijam uma validação do txid com base em critérios definidos pelo EC (somente o problema conhecido de pagamentos entrando sem txid).
então, eu pergunto:
1. já foi implementada a possibilidade de bloqueio de recebimentos de Pix sem txid (seja a nível de chave Pix ou de conta transacional)?
2. se não foi, a evolução dessa funcionalidade para algo baseado em regex (ou outras regras) não está atrasando desnecessariamente a implantação da função de bloqueio de recebimento sem txid?
Lembrando que esse bloqueio é essencial para os EC que precisam de 100% de assertividade na conciliação automática.
6º - Quando apenas o módulo de Pix está ativo no plugin, uma mensagem dizendo que é necessário ativar uma forma de recebimento fica aparecendo
tive uma ideia aqui. e se a GN mandar um request para webhookURL/txidmatch passando o txid recebido, com um timeout de uns 3 segundos, e o EC responde se a GN deve ou não aceitar o recebimento?
talvez o problema seja o BC encasquetar com o prazo de conclusão do recebimento (a média de tempo iria subir)
<@!793123559874494465> uma alternativa seria usar algo como o % do MySQL. Assim, poderíamos ter:
Tipo assim:
Os comecaCom/terminaCom/contem são múltiplos ? Ou seja, poderia ser:
"recebimento": {
"txid": {
"comecaCom": "gnPix",
"comecaCom": "BACEN",
"aceitarVazio": false
}
}
?
Eu acredito que resolveríamos com outra flag, <@!780500321994539068> , algo nesse sentido:
Boa tarde @everyone !
Retomando o assunto endpoint de configurações (https://www.notion.so/Endpoint-de-configura-es-0a97faee68f845ab96ec21551862fe6c).
Nosso time de engenharia observou que existem possíveis situações em que o match do regex com a string do txid pode demorar muitos segundos ou até minutos. Existem situações inclusive de crash da aplicação. Em outras palavras: não é seguro recebermos via input qualquer regex.
Um exemplo que vocês podem testar no browser:
e por isso que ter 2 fluxos de notificações, para pagamentos e recebimentos.
Possivelmente o webhook de pix enviado devesse ser sendpix ao invés de pix. Então vc mandaria exemplo.com.br/webhook na configuração de webhook para aquela chave, e a GN acionaria exemplo.com.br/webhook/pix para os recebimentos e exemplo.com.br/webhook/sendpix para os pagamentos.
um webhook para pagamentos e outro para recebimentos.
Boa tarde <@!783359762917752843>, a resposta já vem no momento da requisição, mas o webhook também é acionado com os dados do envio. Você pode configurar sim, mas neste caso o melhor cenário seria ter uma chave para envio de Pix com um webhook e outra chave com o segundo webhook exclusivo para recebimento, pois, cada chave só pode estar associada a um único webhook.
Bom dia. Seria legal se alguém da GN pudesse esclarecer se a implementação de vocês prevê (e previne) modificações/remoções na cobrança no intervalo entre o início de um processo de recebimento e a sua conclusão, que foi discutido em https://github.com/bacen/pix-api/issues/324
