Pagamentos Offline: Como Gateways Lidam com Store-and-Forward em Áreas Sem Internet
Ponto-chave
O modelo store-and-forward permite que terminais de pagamento processem vendas sem internet, armazenando dados criptografados para envio posterior. O grande desafio dos gateways e adquirentes é equilibrar a conversão em áreas remotas com o risco de fraudes e chargebacks em transações não autorizadas em tempo real.
O Brasil é um país de contrastes de infraestrutura. Você sai da Faria Lima com 5G estourando no celular e, duas horas depois, numa rodovia do interior paulista, o sinal desaparece por completo. Agora, transporte essa realidade para o agronegócio no Mato Grosso, para o turismo em praias isoladas da Bahia ou para o transporte fluvial na Amazônia. As pessoas continuam consumindo. O dinheiro precisa circular. Como você passa um cartão ou aproxima um celular numa maquininha sem um pingo de internet?
A resposta da indústria de pagamentos para a falta de conectividade atende pelo nome de store-and-forward (armazenar e encaminhar). Nós cobrimos a evolução da infraestrutura financeira brasileira há mais de 15 anos e acompanhamos de perto quando as antigas redes discadas deram lugar ao GPRS, e depois ao 3G e 4G. A promessa das teles era conectividade ubíqua. A realidade entregou milhares de áreas de sombra. Segundo dados do IBGE e da Anatel, cerca de 15% das rodovias pavimentadas e vastas porções do território rural brasileiro sofrem com apagões de sinal.
Para o ecossistema de pagamentos, rejeitar uma compra por falta de rede é rasgar dinheiro. É exatamente aqui que a engenharia de software dos adquirentes e gateways entra em ação para garantir que o comércio não pare, mesmo quando a internet cai.
A engenharia invisível do Store-and-Forward
No fluxo normal de uma transação online, a maquininha (POS) lê o cartão, empacota os dados criptografados e envia para o gateway ou adquirente (como Stone, Cielo, PagSeguro). O adquirente roteia isso para a bandeira (Visa, Mastercard), que baté na porta do banco emissor (Nubank, Itaú). O banco verifica saldo, limites e regras de fraude, e devolve o 'aprovado' ou 'negado'. Tudo isso em cerca de 1 a 2 segundos.
Quando o sinal de rede some, esse cordão umbilical com o banco emissor é cortado. A autorização em tempo real morre.
No modelo store-and-forward, a maquininha assume o papel de juiz temporário. O software do terminal é programado para aceitar a transação localmente. Ele captura os dados do cartão, valida a senha (PIN) através do próprio chip inteligente do plástico, gera um criptograma de autorização e guarda essa transação na memória interna. A maquininha imprime o comprovante, o cliente vai embora com a mercadoria e o lojista fica com uma promessa matemática de pagamento.
Horas ou dias depois, quando o terminal finalmente encontra um sinal de Wi-Fi ou rede móvel, ele faz o forward. Ele descarrega aquele lote (batch) de transações acumuladas para os servidores do gateway.
Onde a criptografia salva o dia
Você deve estar se perguntando: como a maquininha sabe que a senha está certa sem perguntar ao banco? A mágica acontece graças ao padrão EMV (Europay, Mastercard e Visa) presente nos chips dos cartões.
Existem três níveis de autenticação offline no protocolo EMV: SDA (Static Data Authentication), DDA (Dynamic Data Authentication) e CDA (Combined Data Authentication). O Brasil útiliza amplamente o DDA e o CDA. O chip do seu cartão é um microcomputador. Ele possui as chaves criptográficas públicas do banco emissor. Quando você digita a senha no terminal sem internet, a maquininha manda a senha para o chip do cartão. O chip processa a informação, verifica se baté com a senha gravada no seu interior (Offline PIN verification) e responde à maquininha: 'A senha está correta, pode prosseguir'.
Toda essa conversa acontece offline, blindada contra interceptações, garantindo que quem inseriu o cartão é realmente o dono dele.
O dilema do risco: quem paga a conta se der erro?
A tecnologia funciona perfeitamente. O problema é o fator humano e o risco de crédito.
Imagine o seguinte cenário: um fraudador sabe que o cartão dele foi cancelado ou não tem limite. Ele vai até um evento afastado, onde sabe que as maquininhas estão operando offline, e faz uma compra de R$ 5.000,00. O chip valida a senha, a maquininha aprova via store-and-forward. No dia seguinte, quando a maquininha se conecta à internet e envia o lote para o gateway, o banco emissor rejeita a transação imediatamente: 'Cartão bloqueado'.
Quem assume esse prejuízo?
Aqui entramos nas regras duras dos arranjos de pagamento. Nas transações offline, o risco de crédito (falta de saldo) ou de cartão bloqueado é quase sempre do lojista (estabelecimento comercial) ou do adquirente, dependendo do contrato firmado. O banco emissor lavará as mãos, pois ele não autorizou a transação no momento da compra.
Para mitigar esse risco de ruína, a indústria criou os chamados Floor Limits (Limites de Piso).
A parametrização dos Floor Limits
O Floor Limit é um teto financeiro configurado remotamente pelo adquirente ou gateway dentro do software da maquininha. Ele dita as regras do jogo quando a internet cai.
Na prática, funciona assim: a Stone ou o Mercado Pago podem configurar o terminal de um supermercado no interior do Pará para aceitar transações offline apenas até R$ 150,00 por compra, com um limite máximo acumulado de R$ 2.000,00 na memória. Se uma compra passar de R$ 150,00 sem rede, a maquininha recusa automaticamente e exige conexão.
Esses limites não são aleatórios. Eles são calculados por algoritmos de risco baseados no histórico de faturamento do lojista, no setor de atuação (MCC - Merchant Category Code) e no índice histórico de chargebacks. Uma padaria de bairro terá um Floor Limit diferente de uma loja de eletrônicos. Se você opera um e-commerce ou um sistema de vendas de ingressos para eventos remotos, preste atenção aqui: negociar esses limites de contingência offline com seu provedor de pagamentos define se o seu evento será um sucesso de vendas ou um desastre de filas travadas.
O pesadelo da conciliação para os varejistas
Resolver a captura do pagamento é apenas metade da batalha. A outra metade explode no backoffice do lojista na forma de um pesadelo de conciliação financeira.
Sistemas de ERP (Enterprise Resource Planning) modernos gostam de linearidade. Vendeu, registrou, conciliou o fluxo de caixa. Com o store-and-forward, o gateway de pagamento recebe hoje uma transação que ocorreu há três dias, numa fazenda no interior de Goiás.
Como o gateway apresenta isso nos relatórios (dashboards) e nas APIs de liquidação? A data da transação será a data do store (quando o cliente passou o cartão) ou a data do forward (quando o adquirente recebeu os dados)?
A resposta varia entre os players. Gateways mais sofisticados enviam os dois timestamps na API. Eles registram a 'Data de Captura Offline' e a 'Data de Processamento'. Isso salva a vida dos times de tesouraria, que precisam cruzar a venda física no estoque do dia 10 com o dinheiro que só apareceu no sistema do gateway no dia 13.
Nós observamos que muitas fintechs menores ainda tropeçam feio na hora de expor esses dados. Elas simplesmente sobrescrevem a data da transação original com a data em que o lote subiu para o servidor. O resultado? O lojista tenta fechar o caixa de terça-feira e os números não batem de jeito nenhum, gerando horas de trabalho manual para a equipe contábil.
Pix Offline e Drex: O futuro impulsionado pelo BACEN
Se o cartão de crédito e débito já resolveu parte do problema com o EMV, o Pix trouxe um novo desafio. O Pix nasceu nativamente online. Ele depende de comúnicação síncrona com o Banco Central via DICT (Diretório de Identificadores de Contas Transacionais) e SPI (Sistema de Pagamentos Instantâneos). Sem internet, não há Pix tradicional.
Mas o BACEN sabe que a inclusão financeira real exige resiliência offline. Em 2025, a pauta do Pix Offline e do Drex (a moeda digital do Banco Central brasileiro, CBDC) ganhou tração brutal.
Nos laboratórios do LIFT Challenge (Laboratório de Inovações Financeiras e Tecnológicas do BACEN), empresas como a Giesecke+Devrient (G+D) vêm testando carteiras digitais de hardware e smartcards capazes de transferir Drex e Pix sem qualquer conexão com a internet.
A mecânica testa os limites da criptografia de ponta a ponta. Usando NFC (Near Field Commúnication) ou Bluetooth BLE, o celular do pagador e a maquininha do recebedor criam um túnel seguro local. O dinheiro digital é deduzido do 'cofre offline' do pagador e transferido para o 'cofre offline' do recebedor simultaneamente. Não é apenas uma promessa de pagamento como no cartão; é a transferência definitiva do valor criptográfico.
Quando qualquer um dos dois dispositivos encontrar internet, ele sincroniza o saldo com a rede blockchain do Drex ou com o SPI do Banco Central. Isso muda o jogo completamente. Elimina o risco de crédito do lojista, pois a validação do saldo ocorreu de forma criptográfica e inviolável no hardware local.
Se você opera em áreas remotas, prepare seu setup
Ignorar a realidade da infraestrutura de telecomúnicações brasileira é um erro estratégico primário. Operações logísticas, distribuidores de bebidas, promotores de eventos e agronegócios precisam de contingência.
Na nossa análise, a escolha de um gateway ou adquirente não deve se basear apenas nas taxas de MDR (Merchant Discount Rate) ou de antecipação. Teste o comportamento do parceiro em situações de estrêsse offline.
Pergunte ao seu gerente de contas: Qual é o Floor Limit padrão da minha conta? O que acontece se a maquininha ficar mais de 72 horas sem conexão (muitos adquirentes expiram o lote de segurança após esse prazo, apagando as vendas)? Como as transações store-and-forward aparecem no webhook da API de conciliação?
O mercado financeiro brasileiro é um dos mais avançados do mundo. Temos o Pix, temos liquidação em D+0, temos biometria facial nos apps. Mas a verdadeira prova de fogo de um sistema de pagamentos robusto não acontece na Avenida Paulista debaixo de antenas 5G. Ela acontece no meio de uma rodovia sem asfalto, debaixo de chuva, quando o cliente estende o cartão e a maquininha precisa tomar uma decisão sozinha.
Perguntas Frequentes
Matheus Feijão
CEO & Fundador — ouro.capital
Especialista em fintech e criptoativos desde 2002. CEO da ouro.capital.