Histórico de mensagens em sugestões

O Neon na verdade usa o BV para isso. A GN é uma IP e não uma IF então isso para GN seria bem mais complexo do ponto de vista regulatório.

Olá pessoal da GN, não busquei muito, mas caso não exista, seria legal ter uma folhinha de investimentos dentro do app. Às vezes, queremos que funcione só como uma poupancinha mesmo ou dinheiro guardado, rendendo uma taxa baixa, para não gastarmos acidentalmente. Eu pessoalmente separo várias porcentagens do lucro da microempresa que tenho para uma coisa ou outra e usava no banco Neon para facilitar a distribuição, o que acham?

Eu reportei internamente para vocês e realmente ele ta enfrentando um problema real.
Como a GN faz automaticamente as verificações, acontece que está pegando o PORTE do CNPJ e não o Código e Natureza, baseado nisso está exigido Ato Constitutivo para os CNPJs MEI.

Na tabela de ISPB, tem o nome reduzido e o nome extenso. O nome reduzido provavelmente seja mais fácil de associar:
https://www.bcb.gov.br/pom/spb/estatistica/port/ASTR003.pdf
https://www.bcb.gov.br/pom/spb/estatistica/port/ParticipantesSTRport.csv

Boa tarde Renato, vou verificar estes detalhes com a equipe e já te retorno

as notificações de Pix recebido da GN estão trazendo a razão social dos PSPs pagadores em vez do nome comercial. ex: "boletobancario.com tecnologia de pagamentos ltda." em vez de "Juno"

Repassado internamente, vamos atuar na questão. Obrigado por reportar

imagem da Gerencianet sendo manchada em 3, 2, 1... https://portaldohost.com.br/forum/topic/28049-ja-tem-modulo-pix-para-whmcs/page/7/#comments

Vou pensar nisso. Obrigado!

Interessante essa questão de 2 partes aí <@!780500321994539068>

TxId duplicado só é recusado em QR-Code dinâmico, e um pagamento pode ser estático (com ou sem txid). Eu estava pensando e acho que a API tem que ter 2 passos de forma similar à UX do app:
/gn/pagamento (BRCode[obrigatório], idpagamento[obrigatório], valor[opcional])
retorna o valor do pagamento, as informações do recebedor no DICT (eventualmente mascaradas).
Aí a próxima chamada seria
/gn/confirmapagamento (idpagamento[obrigatório],valor[obrigatório])
Tem que passar de novo o valor e o id de propósito, para dizer "eu sei que vai sair x dinheiros da minha conta".

Na chamada de pagamento, o valor opcional seria passado para caso o QR-Code estático não tenha valor associado.

<@!780500321994539068>
Sobre ser um endpoint diferente, é algo que traz um maior conforto até na hora de separar os casos de uso. O atual remete a transferências, o outro a pagamentos. Até pelo fato de, em uma transferência, ao enviar TxId, sabe-se lá se outro PSP vai recusar por existir (coincidentemente) uma cobrança lá com o mesmo identificador...

Sobre o acervo de assinaturas de JWT: perfeito, não teriam como validar

<@!793123559874494465> então isso não só facilita o trabalho de codificar o pagamento, quanto é a única maneira de implementar seguindo a ferro e fogo o manual de segurança do BACEN.

<@!793123559874494465> o motivo disso é que os clientes não tem acesso ao acervo de assinaturas válidas de JWT, que fica dentro da RSFN.

<@!793123559874494465> eu estava pensando e acho que para o pagamento de Pix é melhor mesmo um endpoint diferente, recebendo o BRCode. Aí se for estático/dinâmico já faz o tratamento devido e o pagamento. O único ponto é que se for de QR-Code estático, precisa de um id como o de devolução para garantir idempotência.

Obrigado, Evanil. No aguardo.

Interessante. Nas próximas horas desenvolveremos o assunto com vocês.

Exato.

E para processar isso em fila torna a experiência cada vez pior quando o problema é retornar o status para o cliente...