Gateways de pagamento para startups fintech: guia técnico

Para uma startup fintech, o gateway de pagamento não é um detalhe de infraestrutura: é uma das poucas peças que toca ao mesmo tempo a margem, a experiência do usuário e o risco. Uma decisão apressada nas primeiras semanas se paga por anos, tanto em custos por transação quanto na dependência técnica de um único fornecedor.

A boa notícia é que a decisão pode ser tomada com critérios concretos. A má é que quase nenhum comparador público os explica, porque o modelo de negócio dos gateways depende de a integração ser fácil de começar e difícil de abandonar.

O que avaliar antes de assinar com um gateway

Antes de escrever a primeira linha de código, convém avaliar cada fornecedor com base em uma lista curta e mensurável.

• Custo real por transação. Na Argentina e em boa parte da América Latina, os gateways de cartão costumam ficar entre 3% e 6% mais impostos por operação, com custos fixos adicionais e prazos de liquidação que vão de 24 horas a vários dias. Os internacionais como a Stripe giram em torno de 2,9% mais um valor fixo por transação. O número da home nunca é o número final: é preciso somar chargebacks, saques e conversão de moeda.
• Taxa de aprovação. Dois gateways com a mesma comissão podem diferir em vários pontos em quantos pagamentos aprovam. Cada ponto perdido é faturamento que não entra, então esse dado pesa mais do que a comissão nominal.
• Modelo de liquidação e conciliação. Como e quando o dinheiro é creditado, quais relatórios o gateway entrega e se esses relatórios batem com o seu banco de dados sem trabalho manual.
• PCI DSS e tratamento de dados sensíveis. O ideal é que o gateway tokenize o cartão e que o seu sistema nunca armazene o número completo. Isso mantém a empresa no nível de conformidade mais leve (SAQ A) em vez de assumir toda a carga de auditoria.
• Lock-in. O quanto a lógica de cobrança fica atrelada a esse fornecedor. Se migrar de gateway implicar reescrever metade do backend, você já perdeu poder de negociação.

Por que multi-gateway deixa de ser opcional

Quando o volume cresce, depender de um único gateway é um risco de negócio, não apenas técnico. Se esse fornecedor tem uma queda, sofre uma degradação ou rejeita uma faixa de cartões, o faturamento para por completo.

Uma arquitetura multi-gateway resolve dois problemas ao mesmo tempo:

1. Failover. Se o gateway primário rejeita ou não responde, a cobrança é repetida em um secundário de forma transparente para o usuário.
2. Roteamento inteligente. É possível direcionar cada pagamento para o gateway que melhor aprova aquele tipo de cartão ou emissor, ou para o de menor custo para aquele meio. Na prática, rotear por emissor e somar um segundo fornecedor de backup costuma recuperar entre 2 e 5 pontos de taxa de aprovação.

O custo de construir isso é real, mas se amortiza rápido: em uma fintech que processa volume, recuperar três pontos de aprovação equivale a um aumento direto de receita sem gastar um centavo a mais em aquisição.

Retentativas inteligentes e conciliação: onde se ganha ou se perde dinheiro

Uma recusa não é igual à outra. Há recusas "duras" (cartão roubado, conta encerrada) em que repetir não faz sentido, e recusas "brandas" (fundos insuficientes momentâneos, limite temporário) em que uma retentativa no momento certo recupera a cobrança. Repetir às cegas queima custos e pode disparar bloqueios antifraude; repetir lendo o código de resposta recupera receita que a maioria dos produtos prontos deixa na mesa.

A conciliação é a outra metade silenciosa. Cada pagamento precisa ser cruzado com o que o gateway efetivamente liquidou, considerando comissões, chargebacks e estornos. Quando isso é feito à mão em uma planilha, quebra assim que o volume sobe. Quando é automatizado com webhooks idempotentes (ou seja, que processam o mesmo evento uma única vez mesmo que chegue duplicado), a equipe financeira deixa de perseguir divergências.

Split de pagamentos e modelos de marketplace

Se o produto distribui dinheiro entre várias partes (um marketplace, uma plataforma de serviços, um modelo de comissões), surge o requisito de split de pagamentos: cobrar uma vez e liquidar automaticamente a cada beneficiário, retendo a comissão da plataforma. Nem todos os gateways suportam isso de forma nativa, e os que suportam impõem a sua própria lógica. Desenhar essa camada acima dos gateways, e não atrelada a um só, é o que permite trocar de fornecedor sem refazer o modelo de negócio.

Quando a integração sob medida vence a solução pronta

Um botão de pagamento pré-montado é a opção certa para validar uma ideia na primeira semana. Deixa de ser quando o negócio escala e a lógica de cobrança se torna uma vantagem competitiva.

A integração sob medida vence quando a empresa precisa orquestrar vários gateways, aplicar regras próprias de retentativa e roteamento, conciliar de forma automática, suportar split de pagamentos e, acima de tudo, não ficar refém de um fornecedor. Uma integração multi-gateway com conciliação e webhooks bem resolvidos costuma levar entre 4 e 10 semanas conforme o escopo, e esse investimento se recupera em margens e em resiliência operacional.

Na PairProgramming, abordamos a integração de gateways de pagamento como uma camada de orquestração própria do produto, não como um plugin: a empresa mantém o controle das suas regras de cobrança e pode somar ou trocar fornecedores sem reescrever o seu backend. Esse mesmo critério de dados e automação é o que aplicamos em projetos de vertical financeiro como o portal de cotação de seguros miseguro.com.ar.

O gateway mais barato do comparador raramente é o mais rentável em doze meses. O que move o ponteiro é a arquitetura ao redor dele.

Escrito por Esteban Aleart, founder & lead engineer na PairProgramming.