Gateway para delivery: como iFood, Rappi e 99Food processam milhões de pedidos por dia

Sexta-feira, 20h30. Chove forte em São Paulo. O trânsito na Marginal Tietê está travado e milhões de brasileiros decidem que a melhor opção para o jantar é pedir comida em casa. Você abre o seu aplicativo favorito, escolhe uma pizza de R$ 89,90, seleciona o cartão de crédito salvo e aperta 'Fazer Pedido'. A tela carrega por dois ou três segundos e, de repente, o aviso verde confirma: 'Pedido recebido'. O que acontece nesses breves milissegundos é uma das operações financeiras e tecnológicas mais complexas do mercado brasileiro.

Nós acompanhamos a evolução do setor de pagamentos há mais de 15 anos. Vimos a transição da era em que o motoboy carregava três maquininhas (POS) na mochila, torcendo para o sinal do GPRS funcionar no elevador, para a era dos pagamentos invisíveis. Hoje, o jogo é silencioso e acontece nos bastidores, dentro de data centers e instâncias na nuvem. O iFood, por exemplo, chega a processar mais de 80 pedidos por segundo em horários de pico. O Rappi lida com picos de transações cross-border e assinaturas Prime simultaneamente. A 99Food, enquanto operou fortemente no Brasil, tentou adaptar uma infraestrutura asiática gigantesca da DiDi para as peculiaridades do mercado nacional.

Se você opera um e-commerce, preste atenção aqui. A diferença entre um pedido aprovado e um cliente frustrado que vai cozinhar macarrão instantâneo é medida em latência. Um gateway de pagamentos genérico simplesmente não suporta a volumetria e a complexidade de regras de negócio do delivery. Vamos desmontar o motor de pagamentos dessas plataformas e entender como elas garantem que o dinheiro chegue ao restaurante, ao entregador e aos cofres da própria empresa, tudo em conformidade com o Banco Central.

A Engenharia do Smart Routing e a Multi-adquirência

Nenhuma plataforma que processa milhões de transações diárias pode se dar ao luxo de depender de um único adquirente. Se a Cielo passa por uma instabilidade de cinco minutos às 21h de um sábado, o iFood perderia milhões de reais em vendas, e os restaurantes parceiros ficariam ociosos. A solução arquitetônica para isso chama-se multi-adquirência, orquestrada por um motor de roteamento inteligente (Smart Routing).

Na prática, o gateway de um gigante do delivery funciona como um controlador de tráfego aéreo de alta precisão. Quando o seu pedido de R$ 89,90 é disparado, o sistema não manda a transação cegamente para a rede. O motor analisa dezenas de variáveis em tempo real: qual é a bandeira do cartão (Visa, Mastercard, Elo)? Qual adquirente (Stone, Rede, Getnet, Cielo) está oferecendo a melhor taxa de aprovação para essa bandeira nos últimos 60 segundos? Qual adquirente cobra a menor taxa (MDR) para este perfil de transação?

O Smart Routing toma a decisão em menos de 50 milissegundos e envia a requisição. Se o adquirente A demorar mais de 1.5 segundo para responder (timeout), o gateway cancela a chamada e tenta (retry) o adquirente B instantaneamente, sem que o usuário perceba. Essa redundância agressiva eleva as taxas de aprovação (authorization rate) para a casa dos 95% a 98%. Para plataformas que faturam bilhões por ano, subir a aprovação em 1% representa dezenas de milhões de reais direto na última linha do balanço.

Para suportar essa carga, a arquitetura de software útiliza microsserviços escaláveis. Tecnologias como Apache Kafka são usadas para enfileirar e processar eventos de pagamento de forma assíncrona, enquanto bancos de dados NoSQL garantem a gravação ultrarrápida dos logs de transação. Tudo isso rodando sob rígidos padrões de segurança PCI-DSS, garantindo que os dados do seu cartão nunca sejam expostos.

O Dilema da Latência e a Guerra Contra a Fraude

Um dos maiores desafios técnicos no delivery é equilibrar velocidade de aprovação com segurança. O Brasil é, historicamente, um dos países com maiores índices de fraude em transações não presenciais (Card-Not-Present ou CNP). Criminosos usam testes de cartões clonados (card testing) massivamente em apps de comida porque a entrega é rápida e o bem é consumível imediatamente.

O fluxo tradicional de e-commerce permite que uma análise de fraude leve até 48 horas. No delivery, a comida esfria em 30 minutos. O motor de antifraude precisa dar o veredito em cerca de um segundo. Ferramentas como ClearSale, Konduto (agora Boa Vista) ou motores proprietários baseados em machine learning analisam o comportamento do usuário: a geolocalização do celular baté com o endereço de entrega? É a primeira vez que este dispositivo faz um pedido? O valor foge do padrão de consumo desta conta?

Se a pontuação de risco (score) for baixa, a transação segue. Se for alta, é negada antes mesmo de bater no adquirente, economizando custos de processamento. A latência total aceitável para todo esse fluxo — do clique no app, passando pelo gateway, antifraude, adquirente, emissor (banco do usuário) e caminho de volta — é de no máximo 3 a 4 segundos.

A adoção do 3DS2 (3D Secure 2.0) tentou mitigar fraudes transferindo a responsabilidade (liability shift) para o banco emissor, mas a fricção de pedir autenticação biométrica no app do banco durante o pedido de uma pizza ainda gera abandono de carrinho. A solução que os gigantes adotaram é a tokenização de rede (Network Tokenization). O iFood e o Rappi substituem o número real do cartão (PAN) por um token gerado diretamente pela Visa (VTS) ou Mastercard (MDES). Como o banco emissor confia no token da própria rede, a taxa de aprovação sobe imediatamente e os falsos positivos de fraude despencam.

Split de Pagamentos: Dividindo a Conta em Milissegundos

Processar o pagamento é apenas a primeira metade da batalha. A segunda metade é a liquidação financeira. Quando você paga R$ 100 em um pedido (R$ 80 do restaurante, R$ 10 da taxa de entrega para o motoboy, R$ 10 da taxa da plataforma), o dinheiro não pode ir todo para a conta do aplicativo para depois ser repassado. Isso configuraria risco sistêmico e problemas tributários brutais.

O Banco Central do Brasil, através de regulamentações como a Circular 3.952 (que trata do registro de recebíveis) e regras de arranjos de pagamento, exige infraestruturas robustas de Split de Pagamentos. O gateway precisa 'fatiar' a transação no momento da captura ou na liquidação.

No modelo de Split, o adquirente já recebe a ordem de divisão. No D+30 (ou D+1 em recebimentos antecipados), o dinheiro cai diretamente na conta bancária do restaurante parceiro, na carteira digital do entregador e na conta da plataforma. O restaurante emite nota fiscal apenas sobre os R$ 80, o motoboy recebe seus R$ 10 limpos, e o app tributa apenas a sua comissão de R$ 10.

Fazer isso em escala exige um motor de conciliação financeira gigantesco. Cada restaurante tem contratos diferentes. Alguns pagam 12% de comissão, outros 27% (se usarem a logística da plataforma). Alguns antecipam recebíveis diariamente pagando juros, outros recebem no prazo padrão. O gateway precisa aplicar a regra de negócio específica de cada um dos mais de 300 mil restaurantes cadastrados em tempo real.

Estratégias Reais: Como iFood, Rappi e 99Food Operam

Observamos que cada um dos grandes players adotou caminhos distintos para resolver o mesmo problema de infraestrutura, refletindo suas origens e estratégias de capital.

O Ecossistema Fechado do iFood (MovilePay e Zoop)

O iFood, dominando cerca de 80% do mercado de delivery de comida no Brasil, percebeu cedo que pagamentos eram o seu verdadeiro core business. Em vez de depender apenas de gateways terceirizados de prateleira, a holding Movile (controladora do iFood) investiu pesadamente na Zoop, uma fintech de infraestrutura (PaaS - Payments as a Service).

Isso permitiu ao iFood criar a MovilePay (hoje integrada como Conta iFood). Eles construíram um banco digital focado nos restaurantes. O gateway do iFood processa a transação e já liquida os valores diretamente na Conta iFood do lojista. O restaurante, por sua vez, usa esse saldo para pagar fornecedores, gerar cartões pré-pagos ou contratar crédito direto com o app. É uma retenção de liquidez (float) brilhante. O iFood deixou de ser apenas um marketplace de comida para se tornar a principal instituição de pagamento dos seus parceiros.

Rappi: Cross-Border e o Desafio Multi-Vertical

A arquitetura colombiana do Rappi enfrenta um desafio diferente: eles não entregam só comida. Entregam supermercado, farmácia, eletrônicos e operam em múltiplos países da América Latina. O gateway do Rappi precisa lidar com conversões cambiais, integrações com dezenas de adquirentes locais em diferentes jurisdições e regras de compliance variadas.

No Brasil, o Rappi apostou forte no RappiBank e na parceria com a Visa para emitir seus próprios cartões de crédito. Ao incentivar o usuário a pagar com o cartão Rappi, eles reduzem drasticamente o custo de processamento e zeram o risco de fraude externa, já que são o emissor e o adquirente da mesma transação. O motor de pagamentos deles foca muito na recorrência (Rappi Prime), exigindo renovações automáticas de assinaturas com baixo índice de falha.

99Food: A Infraestrutura Global vs. Realidade Local

A trajetória da 99Food (braço da chinesa DiDi) no Brasil é um excelente estudo de caso. Eles chegaram com uma infraestrutura tecnológica global monstruosa, capaz de processar volumes que fariam qualquer e-commerce brasileiro corar. No entanto, pagamentos são um negócio intrinsecamente local.

A dificuldade de integrar perfeitamente os arranjos de pagamento brasileiros, gerenciar o split com as maquininhas físicas que ainda tentaram usar nos primeiros anos e a concorrência brutal por margens forçaram a empresa a rever sua estratégia no delivery local. O gateway deles era técnicamente impecável em termos de engenharia de software (microsserviços em Go, bancos de dados distribuídos), mas o custo de aquisição de clientes (CAC) e a queima de caixa (cash burn) para subsidiar as taxas de processamento provaram que ter a melhor tecnologia de gateway não é suficiente se a economia unitária (unit economics) não fechar.

O Efeito Pix no Delivery Brasileiro

Não podemos falar de infraestrutura de pagamentos no Brasil sem colocar o Pix no centro do palco. A adoção do Pix pelos apps de delivery foi uma revolução na gestão de caixa e na redução de custos de processamento. Hoje, estimamos que entre 30% e 40% do volume financeiro de um app de delivery nacional passe pelo arranjo do Banco Central.

Para o gateway, o Pix é um alívio. O custo de uma transação via cartão de crédito gira em torno de 2% a 2.5% em MDR, mais R$ 0,50 a R$ 1,00 por requisição de antifraude, além do risco latente de chargeback (contestação da compra). Um pagamento via Pix custa centavos para a plataforma e tem chargeback zero. O dinheiro já nasce liquidado.

O desafio arquitetônico do Pix no delivery foi a experiência do usuário (UX). O fluxo inicial de 'Copia e Cola' forçava o usuário a sair do iFood, abrir o app do Nubank ou Itaú, colar o código, autenticar e voltar. Cada quebra de fluxo derruba a conversão. A solução técnica dos gateways foi integrar webhooks de liquidação em tempo real (Instant Payment Notification - IPN). Assim que o banco do usuário confirma a transferência para o BACEN, o BACEN avisa o PSP (Provedor de Serviço de Pagamento) do iFood, que dispara um evento via Kafka para o backend do app, atualizando a tela do usuário para 'Pedido Confirmado' em menos de 2 segundos.

A próxima fronteira que já observamos em implantação é o Pix via Open Finance (Iniciação de Pagamento - ITP). O usuário aprova o Pix dentro do próprio ambiente do delivery, sem precisar abrir o app do banco, unindo a conversão do cartão de crédito com o custo baixíssimo do Pix.

Implicações Práticas: O Que Você Aprende com os Gigantes

A arquitetura de iFood e Rappi parece distante da realidade de um e-commerce médio ou de um app regional, mas os princípios são os mesmos e estão cada vez mais acessíveis.

Se você gerencia pagamentos online, a primeira lição é: pare de terceirizar sua inteligência de roteamento. Use gateways ou orquestradores que permitam plugar mais de um adquirente. A redundância não é um luxo de empresas bilionárias, é sobrevivência básica no varejo digital.

A segunda lição é a obsessão por dados. Plataformas de alto volume monitoram as taxas de aprovação por BIN (os seis primeiros dígitos do cartão que identificam o banco emissor). Se o emissor X está negando muitas transações por suspeita de fraude às sextas-feiras, o gateway ajusta as regras do 3DS2 dinamicamente apenas para aquele banco. Você precisa desse nível de granularidade nos seus relatórios de pagamento.

O mercado de delivery provou que o pagamento não é a etapa final da compra, mas o coração da experiência do cliente. No exato segundo em que a fome bate, a tecnologia precisa ser invisível. A infraestrutura que suporta a sua pizza de sexta-feira à noite continuará evoluindo, trocando os trilhos antigos por tokens criptografados, inteligência artificial preditiva e liquidação instantânea. Quem não acompanhar o ritmo de processamento, ficará com o carrinho vazio.