Histórico de mensagens sobre Recebimento

Boa tarde pessoal! Liberamos dois novos endpoints para configuração do serviço de recebimento acerca do Pix.
Veja mais informações no canal <#🖥changelog>

Pode confirmar amanhã com os "laranjinhas"(funcionários da Gerencianet) que essa condição existe para o envio de Pix sim, só PJ. Diferente do recebimento.

Além disso, com PJ você pode colocar um nome neutro tipo "Recebimentos para Restaurantes Ltda."

porem, quero gerar um recebimento em pix pelo meu sistema (usando uma linha de codigo para ser recebido pela gerencianet (como é feito no app e nao tem como fazer no desktop)

Não consegui compreender essa parte "gerar codigos para recebimento pix que nao entrarao na cobranca e preciso gerar os devidos links e codigos"

Verifiquei a integracao com a cobranca PIX da gerencianet para gerar os devidos PIXes
Porem, necessito gerar codigos para recebimento pix que nao entrarao na cobranca e preciso gerar os devidos links e codigos, como fazeR?

na Sdk não tem nenhum exemplo também, de recebimento de notificacao de pagamento pix pelo webhook.

Olá Pessoal, bom dia!
Estou seguindo os passos para colocar o recebimento por Pix no meu Marketplace mas preciso viabilizar o custo da transação.
Se eu não entendi errado, meu caso eu recebo um pix na minha conta Gerencianet e precisarei enviar um outro pix para o terceiro envolvido na transação. Correto?

Meu custo então seria 0,99% do valor de cada transação limitado a um teto de R$ 0,89?

No caso essa data seria para todos os bancos se adequarem ao recebimento do pix dinâmico e estático?

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!

Sim, mas eles podem implementar isso no recebimento mesmo que a configuração seja de uma forma menos otimizada.

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.

A estrutura de dados do config e a estrutura de dados do atendedor de recebimentos não precisam ser a mesma. Eles podem fazer essa otimização em uma e não na outra... ou podem fazer nas duas. Mas a transação de config ocorre bem raramente, então dá bem na mesma...
.... porém, sua sugestão me parece mais alinhada com a estrutura da API do BACEN. Então por motivos diferentes, eu também apoio.

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.

E o custo de recebimento de Pix é menor que 89 centavos caso o recebimento seja de valor menor que R$90. Aí entra o 0.99%.

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).

O que eles tinham falado era descontar da conta todo dia, dois pagamentos: um da emissão de cobrança(1 centavo), outro do recebimento de cobrança (0.99% até 89 centavos). Não sei se algo mudou no planejamento.

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
}
}]
}
}

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: