Histórico de mensagens sobre js em sugestões

Um método POST /v2/gn/pix-lote, com o payload abaixo era sucesso:

JSON, CSV e XML são encodings. Aplicações são desenvolvidas com diferentes encodings todo o tempo.

Sobre histórico do mês, isso não escala para contas de muita movimentação.

Entendo, na minha visão seria mais um json com um historico do mes do que entrou e do que saiu excluindo as tarifas, vou ver se consigo formatar do meu jeito com este endpoint.

Uso a sdk do nodejs, mas acho que também não tem esta informação nas outras

Eu gosto do mTLS, digo da ideia pq ainda não implementei, no webhook, já que um medo q eu sempre tive, era o json vir de uma fonte não confiável, e aí eu tinha que ficar fazendo algumas requests para garantir a autenticidade do json...

Usando por mTLS, fica mais confiável da onde está vindo o json/request do webhook...

Pessoal, gostaria de sugerir alguma documentação sobre testes automatizados.
Eu gostaria de mockar as chamadas de api da sdk nodejs da gerencianet, para conseguirmos escrever retornos de funções e validações mais facilmente.
Existe algum tutorial fazendo isso?
Estou suando o framework nestjs, mas algum mock provider convencional também serviria

Sugestão é ter um end-point de status da API Pix (quem sabe demais APIs também). Ele retorna um JSON tipo { token = ok, cob = ok, pix = ok, payload = ok, spi = ok } Onde token significa que o endpoint de token está legal, cob que o /cob está legal dado um token válido, pix que o /pix está ok, payload que o end-point para os outros PSPs buscarem os dinâmicos está ok, spi que a compensação de Pix está ok.

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

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:

Outra coisa... o serviço de geração de token não está aceitando o conteúdo em form-urlencoded. Apenas em JSON. E o padrão form-urlencoded é o utilizado pelos clients visuais e SDKs do OAuth2 para automatizar o gerenciamento do ciclo de vida do Token. Seria importante que o serviço aceitasse ambas.

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.

Oi pessoal da GN! Desculpa tão tarde, mas tive a ideia agora e achei uma boa compartilhar aqui com vocês, eu poderia criar minha própria versão dessa solução mas acho que seria legal para todos é ter como transferir via PIX no internet banking do site da GN. Motivos que me levam a acreditar nisso é:
- GN é o único banco digital que eu vi até agora que tem internet banking, e eu uso muito! Odeio ficar trocando celular computador e a maior parte do tempo é no computador, gostaria de fazer transferencias PIX pelo computador! (:
- Amo o GN por não precisar instalar 10000 módulos de segurança que eu sinto que comem minha RAM loucamente.
- Gosto como extratos são MUITO melhor visualizados no computador e o Internet Banking do Gerencianet faz isso de forma excelente, ou seja, o internet banking se torna uma opção gigantesca para quem faz muitas transações (como comércios e PJs por exemplo)

Eu posso dizer que no caso da nossa API de domínios, a gente é bem taxativo de não usar ambiente compartilhado(precisa ser ao menos um VPS). Mas não é uma aplicação Web, e estamos falando de 100+ canais de registro, não 2 milhões de CNPJs.

Mudar de JSON para JWT ? Só precisa ver se o povo vai conseguir abrir JWT direito... até os PSPs estão sofrendo.

## Objetivo

Permitir que o EC defina algumas configurações:

- Quando aceitar um txid;
- Aceitar ou não Pix Manual;
- Quais notificações receber via webhooks;
- Receber ou não a tarifa no webhook;
- Outras configurações podem surgir.

---

# PUT /gn/config

## Input

Sim. Em tempo vamos pensar em como colocar esses atributos no json da notificação.

a collection do Postman tem corpo "raw", quando poderiam ser elementos json. os exemplos de request ficariam muito mais clean, com content-type adequado e sem aqueles "\r\n" e espaços/tabs desnecessários entre os itens

Report de bug:

Os payloads de cobrança pagas estão retornando um JSON contendo erro: "status_cobranca_invalido", mensagem: "A cobrança não está mais com o status ATIVA". Assim, os apps dos PSPs pagadores estão apresentando "erro ao ler o QR".

O payload deveria continuar sendo retornado no padrão JOSE (com certificado e assinatura, igual as cobrança ativas), com o status alterado para CONCLUIDA, para tratamento adequado, conforme status + possível presença do template 01 com valor 12 (qr code de apresentação única).