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.

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.

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: 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. 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. 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. 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 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. 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”. 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

Falei com SWEDA e o código 17 só vai ser liberado com a versão 9 do SAT que não tem previsão pelo SEFAZ ainda. Recomenda usar 99 (outros)

Pelo menos no SAT - SWEDA de Homologação também com layout 8 não vai....

Alguém tem um fonte para assinador A3? O que se vê por ai, é um monte de executável, e é deplorável arriscar executar um programa que pega o certificado da empresa e pode até criar uma procuração eletrônica enquanto achamos que esta gerando a chave do Sefaz...