Histórico de mensagens sobre pix em sugestões

Sugestão seria: No link de pagamento, além do cartão e boleto, a GerenciaNet podia prover recebimento via Pix da conta. Seria fantástico!

Entendi. Então você tá apoiando por que é melhor pro EC e por que vai na linha da API do BACEN, apesar da minha sugestão ter sido motivada, principalmente, pela economia de recursos da GN para processar os dados em um formato que tenha as chaves pix como índice. Apenas motivações diferentes.

é muito mais legível uma estrutura assim:

Você achar mais "entendível" um objeto não ter o seu identificador (a chave Pix) como índice e ser um elemento interno / propriedade do próprio objeto, só demonstra que você está aplicando um argumento válido (o formato deve ser entendível para quem vai consumir a API, concordo) num local onde ele não faz sentido (o formato que escolheram não é o mais entendível e não é prático de se trabalhar, mesmo do ponto de vista do EC).

A minha preocupação foi 0% em relação ao EC. Foi 100% do lado da GN em relação ao desempenho que ela vai ganhar não precisando iterar esse array em todo recebimento. Todo array que depende de um loop que o percorra para que seus elementos internos sejam identificados (e condicionantes sejam aplicadas) é um array "burro". O identificador deve ser a chave do elemento, sempre que possível. Verificar se pix[chaves][123] existe não exige que eu leia todos os elementos em chaves (e muito menos todos os seus valores internos). Ganha-se absurdamente em velocidade e em consumo de memória - e isso mesmo quando só houver 1 elemento no array. Um teste array_key_exists() tem um processamento ínfimo perto de qualquer tipo de loop. Isso pode ser comparado à uma busca em banco de dados em diferentes colunas, uma com índice e a outra sem.

isso no endpoint /gn/config, certo? esse endpoint já está em uso? vi ele ser comentado aqui no <#💭sugestões> mas não me recordo de alguma config que já tenha sido implantada.

se não foi (ou se foi mas ainda não existe esse índice chaves) eu iria sugerir modificar a estrutura interna dele, passando a usar as chaves como índice das configurações que são definidas por chave.

assim vocês ganhariam em desempenho: não iriam precisar iterar o array chaves e ler o valor de chave em cada um deles para encontrar qual se refere à chave 123 onde um pix tenha entrado. bastaria procurar pela existência do elemento pelo seu índice, pix[chaves][123] (assim como __eu acho__ que já é feito para o cadastramento dos webhooks, por exemplo). o ganho é marginal em 1 recebimento mas pode ser significativo em volume.

Pessoal, boa tarde.

Segue a nossa proposta (inclusive já em andamento) que contempla somente, e apenas inicialmente, as travas de recebimentos de Pix sem txid's, bem como eventual bloqueio geral de recebimento a partir de QR Codes Estáticos (esse segundo ponto veio porque vimos ser uma mudança simples e de ampla aplicabilidade).

e o BACEN tá avaliando, inclusive, mudar a especificação BRCode, passando a aceitar a omissão do campo 62, e aí não teria mais o nem nos qr codes. https://github.com/bacen/pix-api/issues/245

o único caso especial possível que não seria coberto apenas com os 2 validadores txidNulo e txidEstatico seria um PSP pagador tratar erradamente o txid como int em algum ponto do seu sistema e acabar enviando "0" na PACS em vez de uma string vazia, ou omitir o campo txid, fazendo a validação da GN testar contra a opção de aceite de Pix via qr estático em vez de testar contra o Pix de txid nulo, o que eu não vi ninguém reportar e acho difícil que aconteça (por ser o txid um campo que acata caracteres a-z também). por isso que acho suficientes essas 2 opções. simples e funcionais. e em último caso, a GN poderia tratar a string "0" como txidNulo em caráter de exceção.

a opção txidEstatico poderia ser tratada, a princípio, com base no comprimento do txid (1-25 = estático). no futuro pode ser alterado (quando estiver disponível na PACS o método de iniciação do Pix).

Não seria melhor:

{
"pix": {
// configuração da conta
"receberSemChave": true, // permite ao EC recusar Pix Manual de titularidade diferente
"chaves": [{
"chave": "[email protected]",
"recebimento": {
"receberSemTxid": true, // Por padrão todas as chaves recebem, quem configurar como false, recusa Pix sem txid
}
}]
}
}

não dá pra entrar com essas 2 configs ao mesmo tempo, já de imediato?

- txidNulo (faltante, vazio ou )
- txidEstatico (1-25 chars)

o teste ficaria exatamente no mesmo local no fluxo de avaliação de aceite do pix entrante, então não deve atrasar literalmente nada o desenvolvimento.

outra sugestão seria aceitar default (ou padrao, outras, enfim) como chave (qualquer chave sem configuração específica, seguiria o definido para o esse default), que eu entendo que poderia ficar pra um segundo passo

Pessoal, sobre a configuração de recebimentos, fizemos o alinhamento com o time e partiremos novamente da configuração mais simples, onde trazemos para vocês a previsão de disponibilidade para o dia 10/03/20201. A estrutura que iremos trabalhar nesse primeiro momento será algo semelhante ao modelo abaixo:

SOCORRO! Alguém pode ler essa minha mensagem de novo e se movimentar? O mercado pede socorro. E a GN tá perdendo a chance de despontar como solução definitiva por falta desse recurso. Não deixem virar bola de neve! Esqueçam o resto das sugestões e implementem, o quanto antes, recusa de Pix sem txid. FIM! Só peço isso.

Esse Flavio Lenz é da GN?
https://github.com/bacen/pix-api/issues/346

Eu gosto do site, mas o Pix não é para dinossauros como eu. 😉

eu teria q fazer uma tela listando as transações PIX para o cliente escolher qual devolver no meu sistema...

Mas as transações estão lá, só fazer GET em /pix.

É possível também criar novas chaves Pix do tipo aleatória e excluí-las também.
https://dev.gerencianet.com.br/docs#section-criar-chave-evp
https://dev.gerencianet.com.br/docs#section-remover-chave-evp