Histórico de mensagens sobre clientes em sugestões

Uma dúvida, apenas para eu testar a API (Sandbox), preciso preencher tb? Pois penso que devo testar, antes de mandar todos os clientes assinarem este formulário ...

mas você ter o mesmo processo de anti-fraude que o app de mobilidade/comida é um benefício pra você, no caso, já que o imediatismo é mais esperado para esses apps do que para você. a garantia do registro o seu cliente já tem, quando chega na etapa de aguardar anti-fraude de pagamento.

quanto a vocês terem recebido um processo por que o registrante não podia mudar registros DNS enquanto pagamento era aprovado: isso aconteceu em 0,(muitos-zeros)1% dos registros, com certeza. A reclamação do cliente acima é de que ele está perdendo muitas vendas pois os clientes cancelam devido à demora do anti-fraude. Muito provavelmente o que ele vende não são domínios e ele tem uma gama muito maior de concorrentes para onde o cliente pode levar o dinheiro dele e adquirir o mesmo produto/serviço.

Nosso adquirente não customiza análise anti-fraude em função de quem somos, é o mesmo serviço "baunilha" que ele aplica a todos os clientes... inclusive os de entrega física como aplicativos de mobilidade e comida. E nossos clientes ficam igualmente bravos enquanto não podem mudar registros DNS ou tem seus cartões negados, já tivemos até processo judicial em função disso.

O sistema de pagamentos por cartão tem muito que melhorar, estou com pagamentos em analise a mais de 1 dia já, muitos clientes reclamando do tempo de analise e de todos os dados estarem corretos e ainda sim a compra ser reprovada. Infelizmente se isso não melhorar vou tem q usar apenas o pix da gn, gosto muito da plataforma mas realmente tá impossivel.

Tô perdendo vendas e clientes

Eu tenho visto bastante gente questionar nos canais técnicos e comerciais sobre aprovação de cartões, e noto que mesmos os clientes Gerencianet desconhecem que a aprovação de cartão de crédito se dá em 2 passos... talvez ter algum material explicando isso, tanto para que haja esse entendimento quanto isso possa ser explicado para os clientes dos clientes ?

Olá, bom dia!! Vejo aqui na empresa que há muita inadimplência devido a esquecimento e os clientes sempre perguntam sobre Debito Automático. Seria uma boa sugestão implementar o debito automático, reduziria a média de inadimplentes não só aqui da empresa como provavelmente de outros clientes da Gerencia Net

Bem observado, Rubens. Essa é a linha de raciocínio que os clientes também precisam ter em mente.

Estou fazendo um tutorial para meus clientes configurarem a conta para ser usada no meu sistema

boa tarde, estou testando o plugin do WooCommerce e gostaria de enviar algumas sugestões:

1º - Puxar o CPF/CNPJ do cliente no momento do Checkout automaticamente em vez de ficar perguntando toda vez qual o CPF
2º - Adicionar um código Copia e Cola abaixo da imagem do QR Code gerado, nem todos clientes fazem o pedido pelo computador
3º - Incompatibilidade com alguns bancos. Cadastrei uma chave de e-mail, configurei tudo no WooCommerce, na hora de pagar recebo o QR Code, mas nem todos bancos conseguem ler a image, como no caso do PicPay, o erro apresentado é que o Pix ainda não está disponível para este código... mas se tento ler com o Nubank por exemplo, funciona
4º - O identificador do Pix poderia ser o número do pedido gerado no site, complementar ao "Nome da fatura" configurado no plugin. Assim ficaria muito mais fácil de identificar o pagamento no painel GN

Esse primeiro deploy traz uma versão mais simples, na qual a Gerencianet resolve tudo. Isso atenderá a alguns perfis de clientes. Lembrando que nós não armazenamos a chave privada.

Mas a sugestão de aceitar um CSR é tão boa que já tá até no Roadmap, neste card: https://www.notion.so/Gera-o-de-certificados-API-Pix-a-partir-de-um-CSR-de6f5650a5d44ed092af81d6b830ed66

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

Podia por os 2. As vantagens do pix.ae:

1. mais fácil usar (muitas mídias não tornam clicáveis - ou sequer aceitam - links que não sejam http(s))
2. é acessível para todos os clientes Pix universalmente, inclusive os clientes de PSPs que ainda não suportam a integração "automática" pelo header x-pix-brcode (abre no navegador e escaneia/copia o brcode)
3. se propagará mais rápido devido às vantagens 1 e 2 😁

Colocando lenha na fogueira, só um parênteses, continuem aí na prosa de vcs pra não embolar os assuntos... Vejo que o debate de flexibilizar o mTLS seria benéfico e cada PSP arbitraria isso junto ao cliente, por exemplo, um contrato adicional de renuncia do mTLS. Nós recomendaríamos então o cliente e vim na Gerencianet a cada Webhook certificar do status, isso é ruim para a infraestrutura, mas tratarmos algum processamento em troca de algum conforto para alguns clientes, pode ser importante para os negócios e plug-ins.

E se o uso de recursos estiver sendo ruim para a Gerencianet, abre-se dialogo com o cliente, situação que ocasionalmente ocorre.

bom, é útil em qualquer um dos dois jeitos. só não entendi o argumento pra ser favorável a ser no PUT e nao no callback.

o argumento a favor de ser no callback é já ficar preparado pra eventual liberação da necessidade do mTLS por parte do BACEN.

outro argumento é permitir que clientes que vão receber callback usando APIs operadas por terceiros (como ERP SaaS) possam adicionar o header quando bem entenderem, sem depender de mudança na API que manda o PUT

tem PSP implementando isso muuuuuito mal.. e ainda tem as opções do tipo "lembrar recebedor" guardam os dados da conta na lista de recebedor e os clientes pagam por ali em vez de ler QR code (não se dão conta de que precisamos do txid para identificar as cobranças)

Sugestão para a incorporação do /pix: no teste de ativação do webhook, testar primeiro com /pix. Se funcionar, já sabe que esse cliente está preparado e usa dessa forma. Se não funcionar, por enquanto ativa sem /pix, vai registrando para notificar os clientes para mudar.

<@!781134406680838216> : minha sugestão é retirar as menções às "PACS" da documentação de vocês. é totalmente irrelevante para os clientes. É detalhe de comunicação entre PSPs e BACEN. melhor ainda seria a documentação do BACEN ser referenciada, por mais que a de vocês seja boa, e deixar apenas menção ao que ainda não está 100% aderente ao BACEN. assim evitaria a necessidade de ficar represando modificações, quando elas tiverem por objetivo se adequar ao BACEN.

"a)Fase 1 – até 01/02/2021: Canais de atendimento, produtos e serviços mais relevantes, como contas de depósito à vista e operações de crédito;

b)Fase 2 – até 15/07/2021: Cadastros e transações de clientes relativas aos produtos e serviços da fase 1;

c)Fase 3 – até 30/08/2021: Serviços de iniciação de transação de pagamentos e encaminhamento de proposta de operação de crédito;

d)Fase 4 – até 15/12/2021: Outros produtos, serviços e transações de clientes, como operações de câmbio, investimentos, seguros e contas-salário."

Eu tenho impressão que na fase 1 tem só a tarifa máxima mesmo. Mas um possível pedido seria seguir o mesmo layout do OpenBanking de tarifas públicas disponível via interface autenticada.

Equipe GN, uma sugestão que acho interessante é vocês fornecerem um endpoint para que seja retornado quais as tarifas relacionadas a conta do cliente (sobre o escopo da API PIX). No webinar falou-se que uma empresa ou outra pode fazer parceiras com o GN e que os valores dessa tarifa podem variar. Isso, para quem fez a integração com a API para vários clientes acaba sendo ruim, pois a alternativa seria o usuário fornecer essas informações em vez do próprio sistema consultar e calcular a despesa gerada pela integração. O sistema podendo recuperar essa info, seria o ouro!