Pesquisar na Comunidade

Estou tentando fazer o teste abaixo, mas estou com problemas em relação a mensagem de "Operacao Cancelada", no me teste aparece a mensagem "13 - Operacao cancelada" com o botão OK, e no roteiro de homologação diz que tem que aparecer a mensagem "Operacao cancelada ?" com botões SIM e NÃO. Teste: ------------------ Realizar uma venda de débito ao solicitar a leitura do cartão no PIN Pad pressionar aa tecla "Anula" no PIN Pad deve exibir a mensagem na aplicação "Operação Cancelada ? SIM / NÃO" optar por "NÃO" voltou a solicitar a leitura do cartão, dando sequencia no fluxo ao solicitar a digitação da senha do cartão no PIN Pad pressionar a tecla "Anula" no PIN Pad deve exibir a mensagem na aplicação "Confirma Cancelamento ? SIM / NÃO" optar por "NÃO" voltou a solicitar a digitação da senha o mesmo ocorre quando pressiono o "Cancela" da aplicação. Segundo a Software, eles falaram que está faltando tratar o tipo campo 5013 - Confirmação de Cancelamento. Eles mandaram este log abaixo, referente ao teste deles e nosso. Teste da Software (SE000001) CliSiTef : MAID - LibEmv trata multiplos AIDs = [sIM] (SE000001) CliSiTef : MAID - Pinpad trata multiplos AIDs = [NAO] (SE000001) LibSEPPEmv : RxM - Dados = [Cont=3; Tam=10] (SE000001) LibSEPPEmv : PP_DisplayEx - Sts = 0 (SE000001) CliSiTef : ColetaCampo/C - Comando = [Cmd=20; TipoCampo=5013 (EVENTO_CONFIRMA_CANCELAMENTO); Min=0; Max=1] (SE000001) CliSiTef : ColetaCampo/C - DadosComando = [13 - Operacao Cancelada?] (SE000001) CliSiTefI : CFSI-S - Saida = [Cmd=20; TipoCampo=5013; Min=0; Max=1] (SE000001) CliSiTefI : CFSI-S - pBuffer = [13 - Operacao Cancelada?] (SE000001) CliSiTefI : CFSI - Retorno = 10000 Nosso teste (SE000002) CliSiTefI : CFSI (ContinuaFuncaoSiTefInterativo) - hCliSiTefi = [99bfae0] (SE000002) CliSiTefI : CFSI-E - Entrada = [Continua=0; TamBuf=20001] (SE000002) LibSEPPEmv : RxM - Dados = [Cont=1; Tam=10] (SE000002) LibSEPPEmv : PP_GoOnChip - Sts = 13 (PPCOMP_CANCEL) (SE000002) LibSEPPEmv : RxM - Dados = [Cont=1; Tam=10] (SE000002) LibSEPPEmv : PP_DisplayEx - Sts = 0 (SE000002) CliSiTef : ColetaCampo/C - Comando = [Cmd=22; TipoCampo=-1; Min=1; Max=1] (SE000002) CliSiTef : ColetaCampo/C - DadosComando = [13 - Operacao Cancelada] (SE000002) CliSiTefI : CFSI-S - Saida = [Cmd=22; TipoCampo=-1; Min=1; Max=1] (SE000002) CliSiTefI : CFSI-S - pBuffer = [13 - Operacao Cancelada] (SE000002) CliSiTefI : CFSI - Retorno = 10000 Nesse caso, vocês precisam chamar o tipocampo=5013 e criar o a mensagem de sim ou não. ------------------------------------------------------------------------------------------------------------------------------------------------ Segue abaixo, o log do Clisitef que realizei no TEFDemo -- 01/04 11:37:25:494 - CliSiTef DoExibeMsg: Oper: opmExibirMsgOperador Mensagem: SOLICITE A SENHA -- 01/04 11:37:25:496 - CliSiTef DoExibeMsg: Oper: opmExibirMsgCliente Mensagem: SOLICITE A SENHA -- 01/04 11:37:25:498 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 01/04 11:37:25:990 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 23 TipoCampo = -1 Buffer = Tam.Min = 0 Tam.Max = 0 -- 01/04 11:37:25:991 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 01/04 11:37:26:483 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 23 TipoCampo = -1 Buffer = Tam.Min = 0 Tam.Max = 0 -- 01/04 11:37:26:484 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 01/04 11:37:26:990 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 23 TipoCampo = -1 Buffer = Tam.Min = 0 Tam.Max = 0 -- 01/04 11:37:26:992 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 01/04 11:37:27:483 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 23 TipoCampo = -1 Buffer = Tam.Min = 0 Tam.Max = 0 -- 01/04 11:37:27:483 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 01/04 11:37:27:539 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 22 TipoCampo = -1 Buffer = 13 - Operacao Cancelada Tam.Min = 1 Tam.Max = 1 -- 01/04 11:37:27:539 - CliSiTef DoExibeMsg: Oper: opmOK Mensagem: 13 - Operacao Cancelada -- 01/04 11:37:27:539 - BloquearMouseTeclado: NAO -- 01/04 11:37:29:355 - BloquearMouseTeclado: SIM -- 01/04 11:37:29:357 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 01/04 11:37:29:359 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 0 Buffer = 1 Tam.Min = 0 Tam.Max = 0 -- 01/04 11:37:29:359 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 01/04 11:37:29:360 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 3 TipoCampo = -1 Buffer = Retire o cartao da leitora Tam.Min = 0 Tam.Max = 0

Entendendo o projeto Android - Flutter Criamos um programa exemplo que se integra com o m-SiTef que você pode utilizar como base para o seu sistema Android (Flutter). m-SiTef O m-SiTef é um aplicativo desenvolvido pela Fiserv para a plataforma Android e funciona através da comunicação por Intents, ou seja, os dados são passados de uma aplicação (Programa exemplo) para outra (m-SiTef) pela própria Intent, sem a necessidade de um SDK ou outra solução para essa comunicação. Para entender melhor como funciona a comunicação entre aplicativos android por intents: https://medium.com/@ashfaque-khokhar/intent-in-android-00f7be3197c0. Exemplo de dados sendo transmitidos de Intent para outra intent. Intent intent = new Intent (getApplicationContext(), SecondActivity.class); intent.putExtra( "NAME" , "Ashu" ); intent.putExtra( "ID" , 21 ); startActivity(intent); Para se integrar ao m-SiTef devemos passar os dados da forma como estão descritos no guia de integração, que você pode encontrar completo aqui: https://dev.softwareexpress.com.br/docs/m-sitef/m-SiTef/ Projeto O nosso projeto de integração está no nosso GitHub: https://github.com/Projeto-ACBr-Oficial/acbr-sitef-flutter Antes de clonar o projeto e rodar, não se esqueça de iniciar o SitDemo e estar com o APK do m-SiTef instalado no terminal Android que fará os testes. Saiba mais sobre estes processos: Para conseguir rodar corretamente o nosso programa exemplo você precisa configurar alguns campos passados ao aplicativo do m-SiTef: Endereço IP do SitDemo CNPJ ou CPF CNPJ da Automação Utilize a tela de configuração da aplicação: Entendendo o projeto O Flutter não possui nativamente no lado Dart uma API interna que replique diretamente o comportamento de "mão dupla" das Intents do Android, como o startActivityForResult seguido pelo onActivityResult. Como o Flutter é projetado para ser multiplataforma, ele não expõe nativamente essas entranhas específicas do sistema operacional; por isso, para capturar o retorno de dados de outro aplicativo, você precisa obrigatoriamente recorrer ao MethodChannel. Ele funciona como uma ponte de comunicação essencial, permitindo que você saia do ambiente Dart para executar o comando de busca de dados no Kotlin ou Java e, assim que o sistema Android processar a resposta, essa informação seja transmitida de volta para a sua interface de forma assíncrona. Para entender melhor como funciona o MethodChannel: https://medium.com/kobe-tech/methodchannel-como-executar-código-nativo-no-flutter-8d02f6bb79a3 Por isso, você deverá necessariamente fazer a ponte entre sua aplicação dart e o código nativo (Java ou Kotlin) para a comunicação com a aplicação do m-SiTef. Do lado Dart a classe importante, que chama o lado Kotlin é: lib/data/msitef/msitef_payment_processor.dart Nela chamamos uma função específica do lado kotlin e aguardamos de forma assíncrona a resposta. Do lado Kotlin é onde ocorre a chamada, que no nosso projeto é feito na MainActivity (Tela principal) onde o motor da UI do Flutter atua. android/app/src/main/kotlin/com/mjtech/fintesthub/flutter/fintesthub_flutter/MainActivity.kt É nela que mapeamos os parâmetros passados ao aplicativo do m-SiTef. Fora esta classe, temos: android/app/src/main/kotlin/com/mjtech/fintesthub/flutter/fintesthub_flutter/payment/MSitefPaymentUtils.kt Classe utilizada para as funções auxiliares referentes ao mapeamento de parâmetros. android/app/src/main/kotlin/com/mjtech/fintesthub/flutter/fintesthub_flutter/payment/MSitefPayment.kt Classe de dados criada a partir do mapping vindo do Dart. android/app/src/main/kotlin/com/mjtech/fintesthub/flutter/fintesthub_flutter/payment/MSitefResponse.kt Classe de dados criada a partir da resposta do aplicativo m-SiTef. Menu administrativo O menu administrativo está na tela de configurações e é uma importante funcionalidade que deve ter na sua aplicação para acessar as principais funções como cancelamento, reimpressão, teste de comunicação, etc. O mapeamento dos campos passados para a chamada do menu administrativo fica na tela principal do lado Kotlin: android/app/src/main/kotlin/com/mjtech/fintesthub/flutter/fintesthub_flutter/MainActivity.kt Já a chamada do lado dart e a captura do retorno vindo do lado kotlin é feita na classe: lib/data/msitef/admin/msitef_admin_action.dart Roteiro de pré-homologação Uma etapa importante do processo de desenvolvimento e homologação é o roteiro de pré-homologação. Algumas etapas do roteiro de testes exigem valores exatos como R$25.000 ou R$15,00 e a troca de alguns campos de configurações, foi pensando nestes testes que fizemos este programa exemplo, onde você consegue informar o valor exato na tela de pagamento e modificar os campos de configuração em tempo de execução. Fluxo de pagamento: Esta aplicação já passou pelo roteiro de teste de pré-homologação e você pode utilizar como base para o seu projeto. Em nosso curso -> T.E.F e Meios de Pagamentos, já estão disponíveis as aulas sobre o Pré-Roteiro de Homologação - MSiTef. _________________________________________________________________ Referências - Toda a integração foi guiada pela documentação oficial disponibilizada pela própria Fiserv no link: https://dev.softwareexpress.com.br/docs/m-sitef/m-SiTef/ Estamos disponíveis para qualquer dúvida ou sugestão.

Entendendo o projeto Android - Kotlin Criamos um programa exemplo que se integra com o m-SiTef que você pode utilizar como base para seu sistema Android (Kotlin ou Java). m-SiTef O m-SiTef é um aplicativo desenvolvido pela Fiserv para a plataforma Android e funciona através da comunicação por Intents, ou seja, os dados são passados de uma aplicação (Programa exemplo) para outra (m-SiTef) pela própria Intent, sem a necessidade de um SDK ou outra solução para essa comunicação. Para entender melhor como funciona a comunicação entre aplicativos android por intents: https://medium.com/@ashfaque-khokhar/intent-in-android-00f7be3197c0. Exemplo de dados sendo transmitidos de Intent para outra intent. Intent intent = new Intent (getApplicationContext(), SecondActivity.class); intent.putExtra( "NAME" , "Ashu" ); intent.putExtra( "ID" , 21 ); startActivity(intent); Para se integrar ao m-SiTef devemos passar os dados da forma como estão descritos no guia de integração, que você pode encontrar completo aqui: https://dev.softwareexpress.com.br/docs/m-sitef/m-SiTef/ Projeto O nosso projeto de integração está no nosso GitHub: https://github.com/Projeto-ACBr-Oficial/acbr-sitef-android Antes de clonar o projeto e rodar, não se esqueça de iniciar o SitDemo e estar com o APK do m-SiTef instalado no terminal Android que fará os testes. Saiba mais sobre estes processos: Para conseguir rodar corretamente o nosso programa exemplo você precisa configurar alguns campos passados ao aplicativo do m-SiTef: Endereço IP do SitDemo CNPJ ou CPF CNPJ da Automação Utilize a tela de configuração da aplicação: Entendendo o projeto O core desta integração está na classe fiserv/msitef/src/main/java/com/mjtech/fiserv/msitef/payment/MSitefPaymentProcessor.kt Nesta classe é feito o mapeamento de todos os campos necessários para fazer os pagamentos na função Débito, Crédito (Á vista e parcelado), Pix e Voucher. Outra classe importante é a fiserv/msitef/src/main/java/com/mjtech/fiserv/msitef/payment/MSitefPaymentActivity.kt. Esta classe é responsável por abrir o APP do m-SiTef e receber e mapear o resultado retornado pelo m-SiTef acionando o callback conforme o retorno recebido. Menu administrativo O menu administrativo está na tela de configurações e é uma importante funcionalidade que deve ter na sua aplicação para acessar as principais funções como cancelamento, reimpressão, teste de comunicação, etc. O core do mapeamento dos parâmetros referente ao menu administrativo está nesta classe: fiserv/msitef/src/main/java/com/mjtech/fiserv/msitef/settings/MSitefAdminHandler.kt Já a classe fiserv/msitef/src/main/java/com/mjtech/fiserv/msitef/settings/MSitefAdminActivity.kt é responsável por chamar o aplicativo do m-SiTef passando os parâmetros necessários e responsável por capturar o retorno. Roteiro de pré-homologação Uma etapa importante do processo de desenvolvimento e homologação é o roteiro de pré-homologação. Algumas etapas do roteiro de testes exigem valores exatos como R$25.000 ou R$15,00 e a troca de alguns campos de configurações, foi pensando nestes testes que fizemos este programa exemplo, onde você consegue informar o valor exato na tela de pagamento e modificar os campos de configuração em tempo de execução. Fluxo de pagamento: Esta aplicação já passou pelo roteiro de teste de pré-homologação e você pode utilizar como base para o seu projeto. Em nosso curso -> T.E.F e Meios de Pagamentos, já estão disponíveis as aulas sobre o Pré-Roteiro de Homologação - MSiTef. _________________________________________________________________ Referências - Toda a integração foi guiada pela documentação oficial disponibilizada pela própria Fiserv no link: https://dev.softwareexpress.com.br/docs/m-sitef/m-SiTef/ Estamos disponíveis para qualquer dúvida ou sugestão.

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

Olá, me chamo Eduardo. Trabalho em uma revenda de sistemas de gestão (ERP), e nas regiões que atendemos, quase nenhum cliente utiliza TEF. Sempre que surge uma implantação que exige TEF, precisamos aprender na hora, o que não é muito produtivo e deixa nossa equipe despreparada. Vendo essa dificuldade, há algum tempo venho buscando uma solução que permita emular um TEF, para que possamos testar configurações e treinar a equipe sobre sua configuração e uso. No entanto, ainda não encontrei algo assim sem a necessidade de um equipamento físico. Gostaria de saber se existe alguma ferramenta como essa ou se a ACBr tem algum projeto parecido, similar aos emuladores de balanças de checkout. Desde já, agradeço e ficaria extremamente grato em obter essa ferramenta!

Olá comunidade Gostaria de compartilhar com todos vocês um guia de integração com o m-SiTef da Fiserv no Android. Sobre o ACBr O ACBr é Distribuidor dos produtos e serviços da FISERV Temos condições exclusivas para a comunidade do ACBr, Somos autoridade em TEF. Confira o nosso curso completo, sobre TEF e Meios de Pagamentos Tenha acesso ao nosso Suporte, Demos e Cursos, inscrevendo-se na página: https://projetoacbr.com.br/tef/ Sobre a FISERV A Fiserv é uma líder global em tecnologia para serviços financeiros e pagamentos, presente em mais de 100 países e com mais de 40 anos de atuação. O SiTef (Sistema Inteligente de Transferência Eletrônica de Fundos) é uma solução TEF desenvolvida pela Fiserv para integrar pagamentos eletrônicos diretamente aos sistemas de automação comercial (PDV, ERP, e-commerce). Ele é considerado líder no mercado brasileiro e movimenta bilhões de transações por ano. Sendo o mais aceito, e compatível dos TEFs do mercado Brasileiro O que é o m-SiTef? O m-SiTef é um aplicativo desenvolvido pela Fiserv para a plataforma Android, tanto em celular ou tablet como em POS, que realiza transações (TEF) através do servidor SiTef. https://dev.softwareexpress.com.br/docs/m-sitef/m-SiTef/ Requisitos Mínimos O m-SiTef é compatível com Android versão 4.4ou superior. Características Gerais do m-SiTef Antes de apresentar as formas de integração, descreveremos neste capítulo as características gerais do m-SiTef. Ele disponibiliza para o integrador as mesmas funcionalidades da CliSiTef, descritas no documento "SiTef - Interface Simplificada com a aplicação", na Tabela de códigos de funções. Para executar as funções, é obrigatório enviar 4 parâmetros ao m-SiTef: empresaSitef, enderecoSitef, modalidade e CNPJ_CPF. Para a modalidade 0, também é obrigatório o parâmetro valor. data class MSitefConfig( val empresaSitef: String, val enderecoSitef: String, val modalidade: String, val cnpjCpf: String, val valor: String? = null // obrigatório para modalidade 0 ) { fun toIntent(): Intent { return Intent("br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF").apply { putExtra("empresaSitef", empresaSitef) putExtra("enderecoSitef", enderecoSitef) putExtra("modalidade", modalidade) putExtra("CNPJ_CPF", cnpjCpf) valor?.let { putExtra("valor", it) } } } } Importante: Todos os parâmetros apresentados neste documento em trechos de código são apenas ilustrativos e devem ser substituídos por valores válidos. A seguir, estão listados todos os parâmetros aceitos na aplicação. Tabela 1 - Parâmetros de entrada do m-SiTef Parâmetro Tipo Descrição empresaSitef Obrigatório Empresa SiTef. Tamanho de 8 dígitos alfanuméricos. enderecoSitef Obrigatório Endereço dos servidores do SiTef. Pode conter 1 a 3 endereços separados por ;. Formato: IP, IP:PORTA ou NOME:PORTA. Porta padrão: 4096. Não informar URL. terminalSitef Opcional Número de terminal SiTef. Se não informado, o m-SiTef usará o número de série do APOS ou o UUID do aparelho Android. modalidade Obrigatório Funcionalidade da CliSiTef. Ex: 0 = Pagamento, 200 = Cancelamento, 114 = Reimpressão. CNPJ_CPF Obrigatório CNPJ ou CPF do estabelecimento, sem caracteres especiais. valor Obrigatório p/ pagamento Valor da venda. Numérico até 12 dígitos, sendo os 2 últimos decimais. operador Opcional Código do operador. Alfanumérico até 20 caracteres. Data Obrigatório Data fiscal no formato AAAAMMDD. Hora Obrigatório Hora fiscal no formato HHMMSS. numeroCupom Obrigatório Número do cupom fiscal. Alfanumérico até 20 caracteres. numParcelas Opcional Número de parcelas em caso de compra parcelada. restricoes Opcional Opções de pagamento que não aparecerão no fluxo. Formato: <Opção>;<Opção>;... transacoesHabilitadas Opcional Opções de pagamento que serão habilitadas. Formato: {<Func1>;<Func2>;...} comExterna Obrigatório Define qual serviço TLS será usado: 0 = Sem TLS, 1 = TLS Software Express, 2 = TLS WNB Comnect, 3 = TLS Gsurf, 4 = TLS GWP (Fiserv). isDoubleValidation Obrigatório p/ TLS SE 0 = validação simples, 1 = validação dupla. cnpj_automacao Obrigatório CNPJ da empresa que desenvolveu a automação comercial. cnpj_facilitador Obrigatório CNPJ do Facilitador (Van). timeoutColeta Opcional Tempo de timeout em segundos para coletas. Padrão: 60s. Valor 0 ou negativo desativa o timeout. pinpadMac Opcional MAC Address Bluetooth do Pinpad. Formato: 00:00:00:00:00:00. tipoPinpad Obrigatório p/ USB ANDROID_USB = pinpad USB. ANDROID_BT = pinpad Bluetooth. acessibilidadeVisual Opcional 0 = desabilitado (padrão), 1 = habilitado. Ativa fontes maiores, alto contraste e text-to-speech. otp Opcional Código obrigatório quando utilizada comunicação com TLS GSurf. dadosSubAdqui Opcional Informações complementares para personalizar o que será impresso na fatura do comprador. tipoCampos Opcional Permite informar valores pré-determinados para campos solicitados pela CliSiTef. Formato JSON: {"campo1":"val1", "campo2":"val2"}. clsit Opcional Para adicionar, atualizar ou remover campos do arquivo de configuração CLSIT. Público-Alvo Parceiros que desenvolvam para Android, e desejam se integrar com o SiTef via m-SiTef, usando Intents. Como iniciar? Possuímos programa exemplo para Android Nativo (Kotlin) e Flutter de onde partiremos para explicarmos o passo a passo de como integrar o m-SiTef em seu projeto/solução. Etapas Para que você consiga testar em nossos programas exemplos siga as etapas abaixo primeiramente. Integração O primeiro passo é instanciar um objeto Intent passando o nome da aplicação como argumento: br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF. Através dessa informação, o Android buscará automaticamente o m-SiTef entre os aplicativos instalados no dispositivo. Em seguida, devem ser configurados os parâmetros obrigatórios através da função putExtra(String, String). Por fim, é executada a função startActivityForResult(Intent, int) passando o objeto Intent e um número inteiro arbitrário como ID (neste documento usaremos 1234). Menu Administrativo: val intent = Intent("br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF").apply { putExtra("empresaSitef", "00000001") putExtra("enderecoSitef", "127.0.0.1") putExtra("modalidade", "110") putExtra("CNPJ_CPF", "12345678912345") } startActivityForResult(intent, 1234) Exemplo Pagamento: val intent = Intent("br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF").apply { putExtra("empresaSitef", "00000001") putExtra("enderecoSitef", "127.0.0.1") putExtra("operador", "0001") putExtra("data", "20140312") putExtra("hora", "150000") putExtra("numeroCupom", "1") putExtra("modalidade", "0") putExtra("valor", "9000") putExtra("CNPJ_CPF", "12345678912345") putExtra("timeoutColeta", "30") putExtra("comExterna", "0") } startActivityForResult(intent, 1234) Exemplo Pagamento Débito à vista: val intent = Intent("br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF").apply { putExtra("empresaSitef", "00000001") putExtra("enderecoSitef", "127.0.0.1") putExtra("operador", "0001") putExtra("data", "20140312") putExtra("hora", "150000") putExtra("numeroCupom", "1") putExtra("modalidade", "2") putExtra("valor", "9000") putExtra("restricoes", "TransacoesHabilitadas=16") putExtra("CNPJ_CPF", "12345678912345") putExtra("timeoutColeta", "30") putExtra("comExterna", "0") } startActivityForResult(intent, 1234) Exemplo Pagamento Crédito à vista: val intent = Intent("br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF").apply { putExtra("empresaSitef", "00000001") putExtra("enderecoSitef", "127.0.0.1") putExtra("operador", "0001") putExtra("data", "20140312") putExtra("hora", "150000") putExtra("numeroCupom", "1") putExtra("numParcelas", "1") putExtra("modalidade", "3") putExtra("valor", "9000") putExtra("restricoes", "TransacoesHabilitadas=26") putExtra("CNPJ_CPF", "12345678912345") putExtra("timeoutColeta", "30") putExtra("comExterna", "0") } startActivityForResult(intent, 1234) Exemplo Pagamento Crédito parcelado: val intent = Intent("br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF").apply { putExtra("empresaSitef", "00000001") putExtra("enderecoSitef", "127.0.0.1") putExtra("operador", "0001") putExtra("data", "20140312") putExtra("hora", "150000") putExtra("numeroCupom", "1") putExtra("numParcelas", "3") putExtra("modalidade", "3") putExtra("valor", "9000") putExtra("restricoes", "TransacoesHabilitadas=27") putExtra("CNPJ_CPF", "12345678912345") putExtra("timeoutColeta", "30") putExtra("comExterna", "0") } startActivityForResult(intent, 1234) Exemplo Transação PIX: Opção 1 - Pelo menu carteiras digitais (Modalidade 0) val intent = Intent("br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF").apply { putExtra("empresaSitef", "00000001") putExtra("enderecoSitef", "127.0.0.1") putExtra("modalidade", "0") putExtra("CNPJ_CPF", "12345678912345") putExtra("cnpj_automacao", "12345678912345") putExtra("transacoesHabilitadas", "7;8;") } startActivityForResult(intent, 1234) Opção 2 - Chamando PIX diretamente (Modalidade 122) val intent = Intent("br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF").apply { putExtra("empresaSitef", "00000001") putExtra("enderecoSitef", "127.0.0.1") putExtra("modalidade", "122") putExtra("CNPJ_CPF", "12345678912345") putExtra("cnpj_automacao", "12345678912345") putExtra("transacoesHabilitadas", "7;8;") putExtra("restricoes", "CarteirasDigitaisHabilitadas=027160110024") } startActivityForResult(intent, 1234) Exemplo Cancelamento: val intent = Intent("br.com.softwareexpress.sitef.msitef.ACTIVITY_CLISITEF").apply { putExtra("empresaSitef", "00000001") putExtra("enderecoSitef", "127.0.0.1") putExtra("modalidade", "200") putExtra("CNPJ_CPF", "12345678912345") } startActivityForResult(intent, 1234) O campo cnpj_automacao é de extrema importância — é através dele que a Fiserv reconhece o estabelecimento para o repasse financeiro. Retorno do m-SiTef Após a execução, o m-SiTef retorna ao app que o acionou através do método onActivityResult. O resultCode indica o status: RESULT_OK (-1) = sucesso ou RESULT_CANCELED (0) = cancelado. Tabela 2 - Parâmetros de saída do m-SiTef Parâmetro Descrição CODRESP Código de resposta da transação. COMP_DADOS_CONF Dados para confirmação da transação na CliSiTef. CODTRANS Código da transação: 00 = Cheque, 01 = Débito, 02 = Crédito. TIPO_PARC 00 = À vista, 01 = Pré-Datado, 02 = Parc. Estabelecimento, 03 = Parc. Administradora. REDE_AUT Rede autorizadora da transação. BANDEIRA Bandeira do cartão utilizado. NSU_SITEF NSU do servidor SiTef. NSU_HOST NSU do Host Autorizador. COD_AUTORIZACAO Código de autorização (somente crédito). NUM_PARC Quantidade de parcelas. Ausente ou 0/1 = à vista. VIA_ESTABELECIMENTO Cupom da via do estabelecimento. VIA_CLIENTE Cupom da via do cliente. VLTROCO Valor aprovado para troco (quando aplicável). TIPO_CAMPOS JsonObject com todos os campos da transação CliSiTef. Tabela 3 - Valores do CODRESP CODRESP Descrição 0 Sucesso. 1 Endereço IP inválido ou não resolvido. 2 Código da loja inválido. 3 Código de terminal inválido. 6 Erro na inicialização do Tcp/Ip. 7 Falta de memória. 8 CliSiTef não encontrada ou com problemas. 9 Configuração de servidores SiTef excedida. 10 Erro de acesso na pasta CliSiTef. 11 Dados inválidos passados pela automação. 12 Modo seguro não ativo. Outro positivo Negada pelo autorizador. -1 Módulo não inicializado. -2 Operação cancelada pelo operador. -3 Modalidade inexistente ou inválida. -4 Falta de memória no PDV. -5 Sem comunicação com o SiTef. -6 Operação cancelada pelo usuário no pinpad. -10 Parâmetro obrigatório não informado. -15 Operação cancelada pela automação comercial. -20 Parâmetro inválido. -40 Transação negada pelo servidor SiTef. -41 Dados inválidos. -43 Problema na execução de rotina no pinpad. -50 Transação não segura. -100 Erro interno do módulo. Outro negativo Erros detectados internamente. Exemplo de tratamento do retorno: override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) { super.onActivityResult(requestCode, resultCode, data) if (requestCode == 1234) { if (resultCode == RESULT_OK) { println("CODRESP: " + data?.extras?.getString("CODRESP")) println("COMP_DADOS_CONF: " + data?.extras?.getString("COMP_DADOS_CONF")) println("CODTRANS: " + data?.extras?.getString("CODTRANS")) println("TIPO_PARC: " + data?.extras?.getString("TIPO_PARC")) println("REDE_AUT: " + data?.extras?.getString("REDE_AUT")) println("BANDEIRA: " + data?.extras?.getString("BANDEIRA")) println("NSU_SITEF: " + data?.extras?.getString("NSU_SITEF")) println("NSU_HOST: " + data?.extras?.getString("NSU_HOST")) println("COD_AUTORIZACAO: " + data?.extras?.getString("COD_AUTORIZACAO")) println("NUM_PARC: " + data?.extras?.getString("NUM_PARC")) println("VIA_ESTABELECIMENTO: " + data?.extras?.getString("VIA_ESTABELECIMENTO")) println("VIA_CLIENTE: " + data?.extras?.getString("VIA_CLIENTE")) } } } 🛜 Ambiente Para realizar as transações no m-SiTef você necessita de um endereço SiTef que pode ser emulado em sua máquina via SitDemo e o próprio m-SiTef instalado no terminal Android. Será necessário instalar o Emulador de SiTef em sua máquina, o SitDemo Se você já preencheu o formulário em https://projetoacbr.com.br/tef/ nossa equipe já lhe respondeu com um e-mail, com as instruções de como Baixar o SitDemo Acompanhe o processo de instalação do SitDemo, através desse vídeo abaixo: Após a instalação estar concluída, abra o SitDemo. APK do m-SiTef O APK do m-SiTef também será enviado a você pela equipe do ACBr, após o início da Parceria. É importante você nos informar, em qual dispositivo irá instalar o APK. Exemplos: Sumni P2 GPOS700 PAX A920 Newland N910 Ingenico DX8000 PDV D2 Mini com PinPad USB Os dispositivos do tipo SmartPOS, ou seja, com leitura de Cartão/Chip integrado, possuem segurança PCI. E isso requer que os aplicativos (APKs) sejam assinados com chaves específicas para poderem ser instalados nesses terminais. Por isso, existe uma versão específica de m-Sitef, para cada dispositivo SmartPOS Com o APK em mãos você deve instalar no terminal que irá fazer os testes... Projeto Atualmente possuímos exemplos de integração com o m-SiTef para Android Nativo com Kotlin e Flutter. Android (Kotlin) Clone o programa exemplo disponível no nosso GitHub: https://github.com/Projeto-ACBr-Oficial/acbr-sitef-android Após clonar o projeto em sua máquina, abra o na sua IDE (Android Studio, VS Code, etc.). Entendendo a integração: Flutter Clone o programa exemplo disponível no nosso GitHub: https://github.com/Projeto-ACBr-Oficial/acbr-sitef-flutter Após clonar o projeto em sua máquina, abra o na sua IDE (Android Studio, VS Code, etc.). Entendendo a integração: Rodar o projeto Após essas etapas e configurações você consegue rodar nosso programa exemplo integrando com o m-SiTef em um terminal Android. Roteiro Pré-Homologação m-SiTef Em nosso curso -> T.E.F e Meios de Pagamentos, já estão disponíveis as aulas sobre o Pré-Roteiro de Homologação - MSiTef. Referências - Toda a integração foi guiada pela documentação oficial disponibilizada pela própria Fiserv no link: https://dev.softwareexpress.com.br/docs/m-sitef/m-SiTef/ Estamos disponíveis para qualquer dúvida ou sugestão.

Olá comunidade ! Não, o título deste tópico não é um "click-bait". A partir de 03/11/2025, todos os pagamentos com saldos de PAT, cartões embandeirados Elo, Mastercard e Visa deverão ser transacionados exclusivamente com o novo trilho Voucher. Transações que se enquadrem nessa categoria feitas pelo trilho Crédito serão rejeitadas Afinal, o que é a Trilho Voucher? Em 2017, com a entrada das fintechs no mercado de transações de pagamento, surgiu um desafio para evitar o desvirtuamento das funções originais do trilho de crédito é débito. Começaram a ocorrer situações, em que transações de crédito ou débito que supostamente deveriam ser pagas utilizando recursos de uma finalidade específica (vale refeição, por exemplo) estavam fugindo de sua concepção original. Isso causava confusão e abria margem para concorrências desleais. Visando resolver esses problemas, foi criado o novo trilho Voucher para ser utilizado apenas nessas situações específicas. O que eu como Software House ou usuário final do TEF devo fazer? A maior parte do processo e das atualizações foram feitas do lado que recebe e processa as transações de pagamento. Do lado da software house e do cliente final é importante que: Caso utilize PGWindows ele seja a partir da versão 5.1.43.4 Caso utilize DDL ela seja a partir da versão 4.1.43.10

Olá pessoal! No dia 04/09/2025 foi publicada a Instrução Normativa nº 1608/2025-GSE. Essa norma regulamenta a vinculação dos meios de pagamento ao respectivo documento fiscal eletrônico por meio de integração sistêmica, abordando o tema em sete artigos. O Artigo 1 estabelece que deve haver integração sistêmica entre o documento fiscal eletrônico emitido e seu respectivo pagamento eletrônico nas operações de circulação de mercadoria realizadas por contribuintes do ICMS, detalhando em seus incisos que: Será considerado interligação tecnológica a comunicação direta, imediata e integrada entre o sistema de pagamento e o software emissor do DFe, sem intervenção humana; Contribuintes MEI estão dispensados dessa obrigatoriedade; Já o Artigo 2 torna essa vinculação obrigatória tanto para a Nota Fiscal Eletrônica (NF-e, modelo 55) quanto para a Nota Fiscal de Consumidor Eletrônica (NFC-e, modelo 65) nas operações cujo pagamento foi feito através de: Cartões de crédito, de débito, de loja ("private label") ou pré-pagos; Transferência eletrônica de recursos via Sistema de Pagamento Instantâneo - PIX; Ele defina ainda, os casos em que a obrigatoriedade não se aplica a operação, sendo eles: Operações em que é dispensada a emissão do documento fiscal. Nota fiscal emitida no regime Nota Fiscal Fácil (NFF); Venda realizada com entrega e pagamento em domicílio (delivery). Não presencial intermediada em site ou plataforma de terceiros. Vale reforçar que para os casos mencionados acima que estão dispensados da obrigatoriedade, não estão isentos de preencher as informações necessárias conforme o MOC. No Artigo 3 é definido que no comprovante de pagamento dessas operações deve constar no mínimo: CNPJ e Nome Empresarial para pessoa jurídica ou CPF e nome cadastral podendo mascarar alguns caracteres para pessoa física. O código de autorização ou identificação do pedido. A data e hora. O valor da operação. O identificador do terminal em que ocorreu a transação nos casos em que se aplica. É estabelecido no Artigo 4 que deve constar no arquivo XML do respectivo documento fiscal, as informações correspondentes ao pagamento no grupo "YA - Informações de pagamento". É definido também em parágrafo único, que nos pagamentos posteriores a emissão do documento, as informações de pagamento devem ser vinculadas ao mesmo através do evento de conciliação financeira - ECONF. O Artigo 5 veda o uso e permanência de equipamento no recinto de atendimento ao público que permita o registro e processamento de operações sujeitas ao ICMS sem a vinculação do pagamento ao documento fiscal por meio de integração sistêmica. O cronograma de implantação é estabelecido no Artigo 6 explicando que para aplicação do mesmo deve ser considerada a soma da receita de todos os estabelecimentos do contribuinte localizados no estado: Por fim o Artigo 7 menciona que a Instrução em questão entra em vigor na data de sua publicação. Leia a Instrução Normativa nº 1608/2025-GSE na íntegra [AQUI] Vale reforçar para aqueles que usam as soluções ACBr: Componente nativo para Delphi/Lazarus, ACBrMonitorPLUS e ACBrLib, já estão prontos para receber essas informações que são requisitadas para vincular os meios de pagamento ao documento fiscal eletrônico, estando de acordo não só com esta requisição, mas também com RS, MT e CE. Os membros da comunidade ACBr que são Corporativo e PRO, possuem acesso aos cursos disponibilizados pelo ACBr, o que inclui o Integração dos Meios de Pagamento aos Documentos Fiscais Eletrônicos e o E-Conf: Integrações de Pagamentos O Projeto ACBr pode ajudar com a solução do TEF, veja mais [AQUI]

Bom dia pessoal! Tivemos um caso que aconteceu no cliente. Ocorre o seguinte: Foi realizado o pagamento via VERO, porém, o cliente usou um cartão indevido e deseja cancelar esse e pagar com outro cartão por exemplo, então resolveram fazer o cancelamento desse pagamento. Mas aparece a caixa de diálogo em tela solicitando o EC. Eis que começa o problema, pois o EC só temos ao finalizar a venda, e emitir o comprovante, até a impressão do mesmo, não temos o código do EC, sendo assim, não é possível cancelar o pagamento. Obs1: Utilizando a DEMO, em teste local, não solicita o EC. Obs2: No log de componente temos a informação PWINFO_VIRTMERCH que guarda o EC, porém, onde devo alimentar essa informação para não solicitar em tela. Obs3: Tentei conversar com o pessoal do Discord, mas sem sucesso, pois confundiram desfazimento com cancelamento, ou que solicita o EC para não haver cancelamento indevido, mas creio que não deveria ficar a cargo de nossos clientes informar esse código e sim o sistema alimentar isso no cancelamento do pagamento. Agradeço a ajuda. comms_250812.log log componente.log

Olá pessoal! Foi publicado no Diário Oficial do Estado do Ceará no dia 22/05/2025 o Decreto Nº 36633 de 19/05/2025. Este decreto possui dois artigos que estabelecem a obrigatoriedade da vinculação dos meios de pagamento eletrônico ao seu respectivo documento fiscal eletrônico mediante interligação tecnológica com o programa emissor do mesmo para NF-e e NFC-e. É preciso mencionar, no entanto, que os prazos de implementação propriamente ditos não foram definidos no decreto, portanto, é de entendimento geral que uma regulamentação mais detalhada é necessária, então espera se a publicação de uma nova portaria ou ato normativo trazendo informações como previsões de casos de aplicação, os prazos de implementação e outros detalhes. Leia o Decreto na íntegra AQUI. O mesmo pode ser encontrado no Diário Oficial do Estado AQUI, na página 3.

O TEF por API/DLL, PayGoWeb, é muito rápido e simples de instalar... Mas você deve tomar alguns cuidados para que ele funcione corretamente nos seus clientes Finais Se você está recebendo alguma das msgs de erro abaixo: SEQUENCIA INVALIDA DO NUMERO DE SOLICITACAO ERRO DE AUTENTICACAO DO PONTO DE CAPTURA A causa desse problema, pode ser o Fato de sua aplicação, que carrega a DLL da PayGoWeb, estar sendo executada em várias instâncias, ao mesmo tempo, na mesma máquina... Ou seja, o Operador executou a aplicação duas ou mais vezes, e está operando o TEF em várias janelas da sua mesma aplicação... Isso gera uma série de problemas, e deve ser evitado... O PinPad não poderá ser acessado em modo compartilhado, por várias instâncias da DLL da PayGoWeb, ao mesmo tempo, e você pode receber erros de acesso ao PinPad As tabelas internas da PayGoWeb, que ela cria em sua Pasta de Trabalho podem perder o sincronismo, pois agora temos várias instâncias da DLL da PayGoWeb gravando nas mesmas tabelas... Portanto, devemos evitar que a aplicação de Frente de Caixa, possa ser aberta várias vezes, na mesma máquina... Uma das técnica para fazer isso, é usar a API do Windows, com o método CreateMutex Veja um exemplo, abaixo, usando Delphi. program SeuPrograma; uses Interfaces, sysutils, IniFiles, Windows, Dialogs, Forms, .... ; {$R *.res} var Ini : TIniFile; UmaInstancia : Boolean; begin Ini := TIniFile.Create( ExtractFilePath(Application.ExeName)+ 'Config.ini' ) ; try UmaInstancia := Ini.ReadBool('Config', 'Uma_Instancia', false); finally Ini.Free; end; Application.Initialize; if UmaInstancia then begin CreateMutex(nil, True, 'NomeDoSeuPrograma'); // <--------------- AQUI ------------- if GetLastError = ERROR_ALREADY_EXISTS then begin MessageDlg('NomeDoSeuPrograma','O programa já está em execução', mtError, [mbOK], 0); Application.Terminate; exit ; end; end; Application.CreateForm(TFrmMain, FrmMain) ; Application.Run; end. Ou Seja, o Primeiro Mutex será criado com sucesso... Mas quando a segunda aplicação for executada, haverá um erro na criação do Mutex, e isso forçará a entrada no IF que aborta a execução do programa, fechando a segunda instância...

Boa tarde Estou implementando a integração com o TEF Scope por API. Estou tendo um problema para comunicar com o Pinpad onde ao passar pela primeira vez em ScopeConsultaPP recebo o retorno 65431 e o fluxo é interrompido. Conforme instruído por @Daniel Simões de Almeida no Discord, entrei em contato com o pessoal da Scope onde fui informado que a função em questão está obsoleta e a mesma não consta mais no manual. Fui instruído pelo pessoal da Scope a usar a função ScopePPGetCOMPort, caso queira buscar a porta ou então caso já tenha a porta, conectar diretamente com ScopePPOpenSecure. Verificando a função reparei que isso já é feito na função ConfigurarPortaPinPad que é chamada dentro de AbrirPinPad. Então fiz a remoção da validação inicial e ai funciona perfeitamente pra mim. Ou seja, quando chamar ConfigurarPortaPinPad, caso a mesma não seja passada, irá chamar o ScopePPGetCOMPort para localizar e caso já tenha sido passada ele pula e vai direto para o ScopePPOpenSecure. Vou enviar a função aqui para ver se vocês acham que é valida essa mudança para aplicar ao fonte: procedure TACBrTEFScopeAPI.AbrirPinPad; var ret: LongInt; bConfig, bExclusivo, aPorta, bPorta: Byte; Canal: Word; endereco: AnsiString; begin FecharComunicacaoScope; GravarLog('AbrirPinPad'); GravarLog('ScopeValidaInterfacePP( '+IntToStr(PP_INTERFACE_LIB_COMPARTILHADA)+' )'); ret := xScopeValidaInterfacePP( PP_INTERFACE_LIB_COMPARTILHADA ); GravarLog(' ret: '+IntToStr(ret)); if (ret <> PC_OK) then TratarErroPinPadScope(ret); try AbrirComunicacaoScope; aPorta := ConfigurarPortaPinPad(fPortaPinPad); if (aPorta = 0) then aPorta := bPorta; if (bConfig = PPCONF_MODO_ABECS) then fPinPadSeguro := True; if fPinPadSeguro then begin if (aPorta = 0) then Canal := CANAL_COMM_NONE else Canal := CANAL_COMM_SERIAL; GravarLog('ScopePPOpenSecure( '+IntToStr(Canal)+', '+IntToStr(aPorta)+' )'); endereco := IntToStr(aPorta); ret := xScopePPOpenSecure(Canal, PAnsiChar(endereco)); end else begin GravarLog('ScopePPOpen( '+IntToStr(aPorta)+' )'); ret := xScopePPOpen(bPorta); end; GravarLog(' ret: '+IntToStr(ret)); if (ret <> PC_OK) then TratarErroPinPadScope(ret); finally VerificarSeMantemConexaoScope; end; end;

Após imprimir o TEF eu envio a impressão da NFC-e, mas ao executar LerStatusImpressora está retornando offline, onde será que está se perdendo?

Olá, estou realizando a integração de PIX na tela do PINPAD pelo CliSiTef, porém o mesmo não aparece na tela. Configurei segundo o exemplo do ACBr para carteiras digitais, como tambem configurei o arquivo .ini do sitef com os codigos 7 e 8, porém não aparece na tela do pinpad o qrcode, mas fica com status de aguardando a leitura. Tambem realizei a configuração da função OnExibeQRCode do componente ACBrTEFD, porém não é chamada. Foram configurados: ACBrTEFD1.TEFCliSiTef.Restricoes = {DevolveStringQRCode=0} ACBrTEFD1.TEFCliSiTef.PinPadIdentificador = cnpj ACBrTEFD1.TEFClisiTef.OperacaoCRT = 122 ACBrTEFD1.GPAtual = gpCliSiTef Teria algo que faltou configurar talvez?

Boa tarde a todos! Estou implementando uma customização no layout dos comprovantes utilizados no meu TEF. porém não encontrei muitas informações precisas sobre quais são os dados obrigatórios de cada bandeira/adquirente que processa a transação. Por acaso alguém saberia direcionar algum documento nesse sentido? Obrigado!

Quanto implementei o TEF com a empresa direção e utilizando a Dll, para iniciar a transação passava alguns parâmetros: Exemplo: Valor, tipo de operação, valor da parcela, quantidade de parcelas e se era permitido alteração. Dessa forma conseguia bloquear a interação do usuário com interface do TEF da direção, pois não era necessário. Estou implementando a integração do TEF com a NTK(PAY&GO) e utilizando ACBR. Como faço para realizar uma transação de TEF com o parcelamento na administradora sem que o usuário precise digitar a quantidade de parcelas, pois essas informações já serão passados pelo meu sistema. Utilizando o comando acbrtefd1.CRT, tenho uma quantidade limitada de parâmetros. Existe outro comando na qual possa passar mais parâmetros(ex: quantidade de parcelas), dispensando assim a interação com o usuário. Obrigado.

Pessoal, estou fazendo a impressão do TEF no PDV e está saindo a impressão do comprovante normalmente, mas em comparação com as maquininhas de cartão, é até grande a impressão. Eu estava querendo ver uma forma de imprimir o comprovante com menos dados e talvez num formato diferente. Eu já setei a flag "ImprimirViaClienteReduzida" para true e ajudou, mas gostaria de reduzir mais ainda. Eu vi que tem o método "OnComandaECFImprimeVia", mas não sei se há outras formas de diminuir o tamanho do comprovante. Poderiam me ajudar?

Prezados, estou pesquisando no fórum sobre o assunto, e não achei nada para o Pay&GO sobre como obter a bandeira da transação, alguém pode dar uma luz, obrigado.

Preciso que o dialogo da taxa de embarque e serviço não apareça na sequência do TEF. Vi essa resposta antiga do Daniel em um post sobre TEF. Eu tentei usa-la mas não parece surtir efeito. Na sequencia de telas do Sitef, usando como base o tefdemo, o form para taxa de embarque e serviço sempre aparece. Estou tentando escondê-la assim: procedure TfrmPrincipal.ACBrTEFD1CliSiTefObtemCampo(Titulo: string; TamanhoMinimo, TamanhoMaximo, TipoCampo: Integer; Operacao: TACBrTEFDCliSiTefOperacaoCampo; var Resposta: AnsiString; var Digitado, VoltarMenu: Boolean); Var AForm : TfrmDadosTef ; MR : TModalResult ; PerguntaCampo:boolean; begin AForm := TfrmDadosTef.Create(self); try AForm.Panel1.Caption := Titulo; AForm.TamanhoMaximo := TamanhoMaximo; AForm.TamanhoMinimo := TamanhoMinimo; AForm.Operacao := Operacao; AForm.TipoCampo := TipoCampo; AForm.Edit1.Text := Resposta; { Para usar Valores Previamente informados } MR := AForm.ShowModal ; Digitado := (MR = mrOK) ; VoltarMenu := (MR = mrRetry) ; case TipoCampo of 504 : // Taxas de Servico e Taxa de Embarque begin PerguntaCampo := (ACBrTEFD1.TEFCliSiTef.Tag > 0) ; if not PerguntaCampo then begin Digitado := True; VoltarMenu := False; Resposta := '0,00' ; end end ; else if Digitado then Resposta := AForm.Edit1.Text; end; finally AForm.Free; end; end; Dados do post antigo do Daniel: "Se a pergunta tive um "TipoCampo" específico a ela, você poderia simplesmente enviar a resposta para o TEFD, sem abrir a tela para o usuário... No caso do SiTef eu uso isso para não exibir as perguntas de Taxa de Serviço e Embarque da Visa" 504 : // Taxas de Servico e Taxa de Embarque begin PerguntaCampo := (ACBrTEFD1.TEFCliSiTef.Tag > 0) ; if not PerguntaCampo then begin Digitado := True; VoltarMenu := False; Resposta := '0,00' ; end end ;

Caros amigos, Preciso fazer implementação TEF em nossa aplicação. Conheço a ACBR usando, NFe, MDF , NFCe agora indo pro TEF. Vi os exemplos na pasta, mas tô meio confuso pois tem varios projetos de exemplo. Pergunta, eu preciso comprar pin pad? Preciso selecionar algum fornecedor especifico de serviço e do leitor ? Queria tipo uma direção básica somente. Desde já agradeço!! Abraços! Ivanilson Ribeiro Delphi Developer

Olá Pessoal boa noite, com fmx e possível ter aplicativo em maquenta do pagSeguro, ciclo, rede, Stone Elas em si tudo é android. Mas normalmente pra se aprovar o pagamento precisa falar com sdk da maquineta. Existe como isso delphi fmx? Ou outro equipamento pos, onde no final de venda ele realizad pagamento ali via débito, crédito enfim isto é bem comum hoje em dia. Conhecem case disso ? Se sim algum githut ? At John

Pessoal, atualmente uso o Sitef (Software Express) com o componente TACBrTEFD, mas estou passando para o TEF em nuvem da SkyTEF que por acaso usa a Software Express. No componente TACBrTEFD eu geralmente uso o GP TEFClisiTEF, mas com o SkyTEF, como faço? Está dando erro de clisitef não inicializado quando uso o mesmo GP. Tem como eu usar o componente TACBrTEFD para TEF em nuvem da SkyTEF ou tenho que usar o TACBrTEFAPI?

Aplicação para rodar TEF com CLISITEF usando DLL. As DLL's estão atualizadas e na pasta da aplicação Faço a inicialização acbrtefd1.inicializar(TACBrTEFDTipo(4)); acbrtefd1.atv; Ai me devolve a mensagem Não foi possível acionar o TEF! Erro: I/O Error : 32 O que está errado?

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 , estou fazendo a homologação porem nao encontro dados da banese, goodcard, petrocard , credishop e ticketcard