Termos mais procurados:
Boa tarde <@!400114559299616769>, como muito bem informado pelo Renato nós continuamos enviando o certificado, o que o x-skip-mtls-checking faz é dar a decisão ao integrador se ele vai ou não verificar o CA na requisição. Fizemos isso para auxiliar clientes que utilizam servidores compartilhados, mas a recomendação é sempre configurar o mTLS.
Bom dia, duas dúvidas:
- sobre o tempo de expiração .. qual o tempo máximo que posso colocar, vi que o default esta 60 minutos.
- alguns clientes demoram e quando vão pagar lendo o qrcode, da link expirado .. tem alguma forma de renovar a cobrança/qrcode com o mesmo txid?
Você já tinha que pedir CPF dos clientes para gerar nota fiscal ou fatura. Já existia uma obrigação tributária.
O problema neste caso é ter que pedir o CPF de todos os clientes, quando no momento podemos apenas conferir o nome do pagador com o nome do cliente cadastrado no site
A checagem de mTLS só foi suprimida para permitir que ela seja feita de outras formas, não para não ser feita. Você pode estar colocando a GN numa fria numa dessas, e ela vai ter que checar mesmo que por auditoria amostral se os clientes estão mesmo checando.
Galera! Pergunta boba, se eu marco como pago em uma API o pagamento cai na conta caso o cliente pague? Eu pergunto pois as vezes os clientes mandam o comprovante e se eu colocar um settle meu sistema já reconhece e destrava o serviço automático
O onboarding é similar a de outras contas digitais: cadastrar no app, mandar documentos, confirmar celular/e-mail, foto etc. Não há custo de setup nem para a conta nem para a API Pix.
Pela experiência que vejo aqui no grupo em alguns dias é usual já ter passado por todos os passos, mas vale checar se as atividades dos clientes não colidem com a lista do item 9.4 de https://gerencianet.com.br/termos-de-uso/
Boa noite, tenho um sistema web para gerenciamento de barbearias /estúdios de beleza , esse sistema comporta múltiplas empresas. Para integrar a api pix, cada empresa teria que se cadastrar no Genrencianet ? Ou seria só um cadastro, e para gerar as cobrança os clientes teriam que configurar o token do pix deles ?
Também lembre de após terminar o teste, desativar o modo sandbox para que as compras reais dos clientes sejam realizadas no ambiente de produção! 🙂
Rubens, são certificados diferentes. O que consome a API é individual por cliente e ambiente (dev/produção). O que usamos pra validar o mTLS nos callbacks é diferente (separados apenas por ambiente dev/produção, sendo os mesmos dois para todos os clientes).
<@!780500321994539068> pra ter alcançado 1m, eles basicamente deixaram o negócio rolar pra não manchar a imagem deles perante os clientes, achando que todos os cordeirinhos fossem devolver o dinheiro numa boa.
Os clientes são diferentes
Talvez uma forma de habilitar cartões internacionais mantendo sustentabilidade da GN e não prejudicar os atuais clientes seja ter uma taxa blend para internacionais, diferente da taxa atual. Ou mudar para Interchange++ que é o que gosto mais, mas que as pessoas não gostam muito por ser menos previsível.
acho que vou deixar assim pra expor para os clientes que o app tem problemas e forçar os caras a se coçarem
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
sslOptions = {
key: fs.readFileSync('./ssl/ssls/pixblack_in.pem'),
cert: fs.readFileSync('./ssl/ssls/pixblack.in.crt'),
ca: fs.readFileSync('./ssl/ssls/chain-pix-prod.crt'),
minVersion: 'TLSv1.2', // força o uso de TLS da versão 1.2 para cima
requestCert: true, // força que o cliente envie um certificado de cliente (mtls)
rejectUnauthorized: false // rejeita clientes que não enviarem certificados válidos
};
So um esclarecimento... dois clientes GerenciaNet (duas cc ) podem estar no mesmo servidor, pois a CA vai ser a mesma pros dois. Correto?
