Pesquisar na Comunidade

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

Bom dia Fizemos os ajustes em nossa aplicação e conseguimos realizar a maioria dos testes. Com relação aos passos 33-34, a venda do passo 33 ocorre normalmente, mas quando ocorre a venda do passo 34 (Transação Pendente), não estamos conseguindo prosseguir. Ao receber esse retorno, deve-se executar o comando CNC ou NCN ? Outro detalhe é que não está sendo possível capturar as informações da Rede, NSU, DataHoraTransacaoHost, ValorTotal e CodigoAutorizacaoTransacao. Geralmente, em cada transação, o Acbr cria um arquivo do tipo .tef , porém nesse caso não está sendo criado. Na mensagem retornada pelo Acbr, é possível identificar apenas o NSU. É possível fazer o desfazimento apenas com essa informação ? Caso sim, por favor, alguém poderia descrever como proceder ? Desde já agradeço a atenção.

Bom dia Srs! Estamos com um problema meio grande rsrsr. Um cliente necessita do TEF para integrar seu aplicativo comercial desktop em duas lojas, com cnpjs diferentes. Porém o mesmo não é homologado e ele detém dos fontes (programação livre customizada). Existe algo para sugerir que integre com essa aplicação e com o TEF sem necessidade de homologar? Ou realmente ele precisará homologar seu Aplicativo na Paygo, Sitef etc? Ele usa o acbrmonitor já há anos, talvez partir para o PayGo seja a solução mais prática? Obrigado por enquanto.

Boa tarde, sou novo no ramo de automação e preciso Homologar minha aplicação com a Pay&Go (Modo discado, troca de arquivos), segui todos os passos do manual, está tudo funcionando certinho. Mas estou perdido por onde começar no processo de homologação, pois em pesquisas eu notei que preciso fazer uma série de testes e depois enviar os arquivos de LOGS para um e-mail especifico. AI vem minhas dúvidas: Onde ou como gero esses logs? Preciso me cadastrar com a Pay&Go antes de tentar enviar esses arquivos? Qual o custo para essa homologação? A partir de quando estarei apto a realizar transações com a Pay&Go? Informações complementares: Estou usando o Pay&Go DEMO versão: 004.001.004.001, Sem PIN-PAD (Digito os dados do cartão durante a simulação). NÃO estou usando nenhuma ferramenta de terceiros, como disponibilizado aqui no ACBR, tudo foi desenvolvimento próprio na questão de comunicação com o TEF discado.

Boa tarde, fiz um ajuste nas units em anexo para poder setar a propriedade "RegistroCertificacao" onde é possivel colocar o numero de registro de certificação da softwerHouse feito junto a PayGo para poder executar o retoiro de testes para hologação. ACBrTEFD.pas ACBrTEFDClass.pas

Bom dia a todos. Estou homologando meu PAF-ECF. Quem já fez esse processo, sabe onde encontro o certificado da NTK (PayGo), pois apenas tenho o meu certificado de homologação do TEF com eles, mas não é esse o que precisa ser apresentado NA HOMOLOGAÇÃO, conforme imagem. Segundo a homologadora eu preciso do certificado da desenvolvedora da solução TEF (com as operadoras de cartão, creio eu). Não recebi outro documento além do meu. Eu enviei email a empresa que estou homologando, mas não me responderam ainda e tenho medo de não responderem em tempo hábil. Que certificado é esse? Varri a internet e não encontrei nada! Alguém tem esse documento? OBS: para registro no estado eu tenho que apresentar o meu certificado de homologação TEF, não tenho dúvidas quanto a isso, a questão apenas é no processo de homologação Se alguém souber de algo, pois estou confuso. Desde já, obrigado a todos