Termos mais procurados:
<@!780500321994539068> o manual de segurança diz que o callback deve ser enviado por canal mTLS. mas como o PSP pode garantir que o canal é mTLS? não existe isso. ele envia com certificado e o cliente verifica se ele quiser. não tem como a GN saber se o cliente tá validando.
O não testar não exime o PSP de validar o cumprimento do manual de segurança pelo EC.
não é bem assim. na verdade, a conexão mTLS não tem como ser validada dos dois lados. quem envia o request manda o certificado e o recebedor é responsável por validar, mas não tem como o emissor impedir que o outro lado "consuma" o request sem validar o certificado enviado. então a norma do BACEN, na prática, obriga o PSP a enviar o certificado e dar meios pro cliente verificar (e rejeitar o request se quiser). mas o EC pode simplesmente ignorar a verificação. o que o novo parâmetro faz é desligar a verificação que a GN faz (por iniciativa dela, não por obrigação) enviando um request sem certificado primeiro para testar se o EC valida. então se vc usa esse parâmetro, você poderá receber callbacks depois, que virão com o certificado, e recebe os dados normalmente mesmo que não valide o certificado (ou seja, sem "fechar mTLS").
É uma API capaz de gerar faturas com um QR Code estático (sem necessidade de usar a API de um PSP, a menos que você precise de notificações via webhook), e faturas com um QR Code dinâmico (de cobrança), nesse caso servindo como auxiliar à API do seu PSP (onde você deve criar a cobrança primeiro, para obter o endereço de location que deve constar no QR Code).
Quando você realiza uma devolução o status pode ficar EM_PROCESSAMENTO, pois, necessita da comunicação com o segundo PSP e a transação pode ser aceita ou recusada nesse tempo de análise.
O NAO_REALIZADO é o status que ocorre quando uma tentativa de devolução é feita, porém, o PSP recusa a devolução.
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 😁
a minha pergunta não foi pra cobrar que validem. foi só pra ajudar a fundamentar a tese de que cabe ao PSP oferecer o suporte ao mTLS mas cabe ao EC usar ou não. se não tem como o PSP saber só com um request individual se o EC está exigindo mTLS, acho que bastaria a GN continuar fazendo a validação no momento do cadastro (pro EC saber que tá configurado correto, se quer usar mTLS) e dar a opção de fazer bypass. ou até mesmo inverter o padrão para não exigir o mTLS e só fazer se o teste se o EC passar x-mtls-check: true no PUT
Sim, correto. Mas... o manual transfere para o PSP checar algumas coisas do EC, inclusive aderência a OWASP top-N. Mas isso não precisa ser feito chamada a chamada, pode e é mais usual ser scan regular.
você quer dizer que cabe ao EC o "require" da validação mTLS e o BACEN não diz explicitamente que o PSP deve validar o PUT?
mas o risco é do EC. o PSP não deveria ser obrigado a exigir mTLS. deveria ser obrigado a oferecer como opção, apenas
O mTLS tenta mitigar tanto a introdução de informações falsas por um PSP fake, quanto o vazamento de informações que eram de um EC para o outro.
e qual o risco que existe para o PSP em mandar um request pra uma URL sem mTLS que não existe com o mTLS? é o EC que tem que confiar ou não. tinha que ser opção do EC.
Mudar de JSON para JWT ? Só precisa ver se o povo vai conseguir abrir JWT direito... até os PSPs estão sofrendo.
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.
O BACEN parece bem propenso a continuar com mTLS no webhook na v2. Porém, parece haver espaço para na v3 simplificar as webhook para notificação apenas, e aí em algo que só tenha notificação, se quem mandou o aviso foi o PSP ou o Gasparzinho, dá na mesma.
Eu tenho a sensação de que o POST em v2/pix para envio de Pix e em v2/cob para criação de cobrança com txid gerado pelo PSP estariam melhor posicionados numa rota proprietária da GN, como /gn/pix e /gn/cob. Como está agora, pode acabar colidindo com alguma implementação futura do BACEN.
Benefício esse principalmente para o PSP que terá menos carga...
não tem um com o retorno do txid com o psp da gerencianet ?
Discordo disso. Um teste que fiz com o Paghiper foi o seguinte:
O Paghiper não é PSP e está usando a chave "[email protected]", então peguei o txid de uma transação e tentei enviar um QRCode Estático com o txid (porque ai eu poderia tentar enviar com valor menor da cobrança). O Itaú recusou o Pix porque estava efetuando uma transação manual e não por causa do regex do txid, por exemplo.
Você só pode emitir cobranças através do PSP onde esteja registrada a chave Pix utilizada. Se você está aqui imagino que seja para emitir via Gerencianet, então precisa ter conta na Gerencianet.
