Paygo desktop; atrás de proxy; tef corporativa

[Milton Souza]

Olá pessoal,

Estou enfrentando dificuldades para instalar e operar o PayGo Desktop (SetupPayGo_full_v5.1.47.2) em um ambiente corporativo que utiliza proxy para controle de tráfego, e gostaria de compartilhar o cenário e ouvir experiências da comunidade.

Cenário técnico

Durante os testes, observei os seguintes pontos:

1. O instalador (aparentemente desenvolvido em Delphi) tenta acessar os endereços listados na documentação oficial
   https://paygodev.readme.io/docs/rede-e-conectividade
   sem respeitar o proxy configurado no sistema operacional.

2. Inicialmente considerei que fosse uma limitação apenas do programa de teste. Para avançar, fiz um bypass temporário (ambiente isolado / “Q.G”) apenas para concluir a instalação.

3. Antes que perguntem:

   • Todas as portas indicadas no manual já estavam liberadas no proxy;

   • Um chamado foi aberto junto ao suporte (SETSIS), mas não houve retorno técnico conclusivo — apenas postergação.

4. Durante a análise de tráfego, identifiquei dois endereços adicionais não documentados, que também são acessados pelo sistema:

   Isso por si só já indica inconsistência ou incompletude da documentação oficial.

   • cef.dfnofd.com.br

   • global.dfnofd.com.br

5. Realizei testes de conectividade via PowerShell, validando todas as portas do manual + os dois endereços acima.
   Resultado: conectividade OK em todos os casos, quando respeitado o proxy.

6. A conclusão técnica foi objetiva:
   o PayGo Desktop não funciona atrás de proxy corporativo.

   Isso levanta alguns pontos críticos:

   • 6.1) O manual não deixa isso explícito;

   • 6.2) A solução parece depender de instalação de componentes adicionais (ex.: Warshall), operando fora de um modelo minimamente seguro — basicamente “libera tudo, instala um antivírus e torce”.

7. Diante dessa controvérsia, a homologação foi encerrada internamente
   (CERTIFICAÇÃO CANCELADA).
   Independentemente do hardware adquirido (ex.: GERTEC), não houve interesse do fornecedor em:

   • corrigir o manual, ou ajustar o comportamento do software.

 

Nota: Mesmo que o cliente opte por realizar um bypass no proxy exclusivamente para os endereços indicados no manual oficial, não há qualquer garantia de estabilidade operacional.

Parte significativa desses endpoints está hospedada em infraestruturas Cloud (Cloudflare / AWS / Azure), cujos endereços IP são dinâmicos e podem ser alterados a qualquer momento, sem aviso prévio.

Isso inviabiliza tecnicamente a criação de regras estáticas de bypass baseadas em IP, pois:

• As regras podem deixar de funcionar de forma imprevisível;

• O PDV pode falhar subitamente em produção;

• O cliente passa a operar em modo reativo, correndo atrás de incidentes;

• Há impacto direto em SLA, suporte e operação.

Em outras palavras, mesmo aceitando a “aberração” de furar o proxy, o cliente não obtém confiabilidade, apenas mais risco operacional e mais manutenção.

Esse modelo transfere para o cliente:

• o ônus da instabilidade,

• a responsabilidade por falhas de conectividade,

• e o risco de interrupção de serviço crítico (meio de pagamento),
  sem qualquer controle técnico real.

Perguntas objetivas

Alguém aqui utiliza PayGo Desktop atrás de proxy corporativo?
Se sim, qual foi a abordagem técnica adotada?

É considerado normal o PDV operar com acesso direto e irrestrito à internet, sem proxy, em ambientes produtivos?

Como justificar esse modelo para clientes de grande porte, com requisitos rígidos de Compliance, Segurança e Auditoria?

Alguém já enfrentou esse cenário em clientes enterprise?
Eles aceitaram essa limitação como “restrição tecnológica” do produto?

É aceitável, do ponto de vista de mercado, operar senha e cartão em uma máquina totalmente liberada para internet?
 

A solução técnica seria simples:
   Liberar geral (PDV fique exposto diretamente à internet inviabiliza completamente a adoção em ambientes corporativos sérios.)
  Corrigir o PayGo - para usar rotinas que respeite o proxy desde que sigam o manual l

Agradeço desde já qualquer relato ou experiência compartilhada.

 

 

Nota: Se já não bastasse, alguns endereços são CloudFare/AWS/Azure (que podem trocar de IP) inviabilizando uma regra de "bypass" para o que está no manual - Gerando transtorno no cliente que aceitar essa abominação

[Daniel Simoes]

Eu confesso que acho pouco provável, eles modificarem algo no instalador ou na Infra, para essa questão do Proxy corporativo...

Mesmo no nosso caso, que já instalamos mais de 15K terminais, essa configuração não é a usual no comercio....

 

Você está homologando com a Parceria do ACBr ? Se SIM, poderíamos interagir, no Ticket criado na Setis...

Você está homologando pela DLL (PGWebLib.dll).. se SIM, poderia usar a versão sem a proteção (Warsaw), que nao requer o instalador, apenas o deploy de 1 DLL

 

[Daniel Simoes]

18 minutos atrás, Milton Souza disse:

Parte significativa desses endpoints está hospedada em infraestruturas Cloud (Cloudflare / AWS / Azure), cujos endereços IP são dinâmicos e podem ser alterados a qualquer momento, sem aviso prévio.

Os endereço que a DLL irá consultar, será informado no processo de instalação do PDC... e caso mude (o que não é comum), basta fazer um novo processo de instalação do PDC, e informar o novo endereço

 

[Milton Souza]

Boa tarde,

   Obrigado pela resposta.

   Mas, não se trata SÓ disso, de mudar IP - o que importa é que PROXY é algo utilizado pelo mercado, para segurança mínima e previsibilidade.
   No seu caso, quando e se, eles trocam IP, vai continuar funcionando, se atualizar a DLL, senão ou até lá, são 15k instalações mandando - informações para IP antigo, que poderá coletar e se divertir com elas.
   
   O maior problema no caso, é que, embora o mercado seja de internet liberada, como você colocaria um cliente seu, que use PROXY, em uma situação que nem a PayGo coloca no manual dela, ou seja,
   não aceita PROXY e teria que passar por FORA dele - e para IPs que mudam (ou podem mudar). Aqui é só condição prévia - porque você teria vendido uma solução - e depois não vai conseguir 

   sustentar ela... é o MAIOR PROBLEMA.

 

  E quanto as 15k, entendo que em nossa terra, facilmente seria 15mi que não se preocupam com a internet - A prova disso é a recomendação expressa de uso do WARSHALL no PDV.

  O fato é que nem mesmo liberando manualmente é seguro, porque diante de IPs que apontam para DNS - em tese dinâimco - a única solução é liberar tudo - o que permite acesso a aplicativos interessantes

  no PornoHub & CIA. Entendo que talvez em clientes grandes o PDV é burro (ou alguém.. huaau)
 

   A propósito - Como usamos APEX - a ideia seria usar o ACBr para fazer a ponte.

[Daniel Simoes]

Todo produto/serviço tem características e limitações... Eu acho que PayGo/Setis não irá mudar o produto, da forma como está concebido... (Creio que a Setis já deva ter respondido isso pelo Ticket)

O TEF PayGo, já é utilizado com sucesso e segurança, em Milhares de Estabelecimentos Comerciais

O Warsaw, aplicado como camada de segurança na DLL.. tem outra finalidade... Ele previne a troca da DLL por outra irregular, mas compatível com os mesmos métodos e assinaturas...

 

O ACBr é Distribuidor dos TEFs: PayGo e Fiserv... 

Se você chegar a conclusão que o TEF PayGo não atende os seus requisitos, podemos lhe apresentar mais sobre o SiTEF da Fiserv

 

[Milton Souza]

Vou dar uma olhada no SITEF da Fiserv.

Com relação a SETIS, eles fecharam o chamado de homologação e não deram bola. Imagina se precisasse algo em cliente...
Não duvido de limitação - Só acho estranho não colocar no manual - Tá la uma lista de endereços para ser habilitados, não 

custava nada colocar - NÃO FUNCIONA COM PROXY - e não que precisa liberar endereços.

 

Além disso, a DLL deles, sem a parafernalha de seguança que já me dava medo, funciona no ACBr ?e usa que tipo de acesso? Se casar com endereços fixos pode ser facitível de usar o ACBr para paygo - vai saber...

Eles parecem não ligar para essa versão de dll. Possivelmente também por causa de segurança, mas pelo menos isso eles tiveram coragem de colocar no site.