Dois anos atrás emitimos o primeiro cartão corporativo via HubCard. Era um cartão fake, num ambiente sandbox de um BIN sponsor que ainda não tinha nos contratado formalmente, comprado num GitHub Pages estático que servia de site institucional. Hoje, atravessamos 12.000 cartões emitidos. Esse post é a retrospectiva honesta — o que ficou da primeira versão, o que reescrevemos três vezes, e o que ainda dói.
O que ficou: a tese central
A premissa de fundação era simples: cartão corporativo precisa ser objeto programático, com ciclo de vida via API. Isso não mudou. Tudo o que construímos depois é consequência.
Em retrospectiva, isso parece óbvio. Não era. Quando começamos:
- Toda fintech brasileira que falava de "cartão corporativo" estava resolvendo despesa de funcionário (reembolso, viagem).
- O mercado de API de cartões pré-pago era dominado por solução de white-label para outras fintechs, não para empresas finais.
- O assunto "cartão por fornecedor" era um caso de nicho que ninguém articulava como categoria.
A tese sobreviveu porque o mundo mudou na direção dela: SaaS recorrente explodiu, mídia paga virou commodity, APIs de IA viraram custo dominante. O cartão corporativo de TI passou a parecer o que sempre foi: uma planilha disfarçada de plástico.
O que reescrevemos três vezes
A API de emissão (3 versões)
v1 (mar/2024): 11 endpoints, sem idempotência, JSON parcialmente livre. Funcionava para 10 clientes.
v2 (set/2024): 4 endpoints, idempotência opt-in, webhooks com schema. Funcionava para 200 clientes.
v3 (mar/2026): 4 endpoints, idempotência obrigatória, webhooks tipados versionados, MCC restritivo por default. Funciona para 2.400 organizações ativas.
Cada reescrita ficou mais simples. A lição contraintuitiva: API boa fica menor com o tempo, não maior. Cada feature nova foi acompanhada de uma feature deprecada.
O modelo de dados de transação (3 versões)
v1: transação era objeto plano. { amount, status, merchant, card_id }. Quebrou quando começaram a ter chargebacks (precisa de relação 1:N).
v2: transação virou hierarquia: Transaction → AuthorizationEvent[] → CaptureEvent → ReversalEvent. Funciona bem, mas era denso pra consumir.
v3: modelo "lifecycle stream" — toda transação é uma sequência de eventos imutáveis com event_type. O cliente reconstrói o estado a partir do stream. Migrado em 6 meses, manteve compat.
A reescrita 3 só fez sentido depois de ter cliente o suficiente para justificar a complexidade. Reescrever antes seria over-engineering.
O modelo de billing interno (3 versões)
v1: plano flat, sem unidade clara. Quebrou porque alguns clientes emitiam 1 cartão/mês e outros 8 mil/mês com o mesmo plano.
v2: plano + por-emissão + por-transação. Funcionou comercialmente mas era impossível prever conta.
v3: plano por tier + envelope de inclusos + overage por unidade explícita. Estável há 14 meses.
A lição: pricing é produto. Quem trata pricing como "fica pra depois" descobre que pricing ruim filtra os clientes certos.
O que ainda dói
Onboarding com BIN sponsor
Para emitir cartão real, precisa de sponsor bank ou contrato direto com processador. No Brasil, isso é uma corrida de obstáculos regulatória, e cada empresa nova entrando no mercado paga o mesmo pedágio. Não é problema técnico — é problema de mercado pouco maduro. Estamos no processo de virar issuer direto. Espero não escrever mais sobre isso depois de 2027.
Tokenização em wallets
Apple Pay e Google Pay aceitam tokenização via parceiros listados. Cada wallet tem fluxo próprio. Cada bandeira tem certificação própria. Em produção desde set/2025, mas ainda exige operação manual para certos casos (cartão de alto valor, primeira tokenização da org). Estamos automatizando — é trabalho ingrato de integração.
Suporte a moedas exóticas
USD e BRL são commodity. EUR funcionou. Mas cliente com fornecedor em INR, IDR, AED descobre que conversão custa caro e às vezes nem é possível. Não há solução barata; estamos negociando volume com FX providers.
Disputa de chargeback
Quando o cliente disputa uma cobrança, a infraestrutura subjacente da bandeira ainda é manual. Você abre o ticket, espera 30–60 dias, vê o resultado num PDF. Nada disso é API. Estamos construindo uma camada UX em cima, mas a fundação continua sendo a infra dos anos 90.
O que ficou da primeira semana
Surpreendentemente, três decisões da primeira semana ainda valem:
-
Sandbox idêntico à produção. Cliente novo precisa testar exatamente como em prod, com dados de mentira. Cada vez que alguém propôs "sandbox simplificado", recusamos. Foi a melhor decisão de DX.
-
Documentação versionada com a API. Nunca tivemos "docs desatualizada" como categoria de bug. Cada PR muda código e doc juntos, ou não passa.
-
CLI que faz tudo que o painel faz. Cliente que vive no terminal nunca precisa abrir o painel. Foi caro de manter mas pagou em retenção.
O que não fizemos e ficou em débito
- Sem multi-currency wallet por cartão: cartão hoje é em uma única moeda. Para mudar, recriar.
- Sem cartão físico (plástico): 100% virtual. Decisão consciente, mas custo de conversão alta para empresas que ainda exigem físico para alguns casos.
- Sem integração nativa com 10+ ERPs: temos webhooks robustos, mas integração turn-key ainda exige trabalho do cliente.
Esses ficam para a v3 do produto. Cada um vale um post.
A métrica que importou
A métrica que melhor previu retenção, mais do que MRR ou número de cartões, foi: % de operações via API vs via painel. Cliente que opera majoritariamente via API tem churn próximo de zero. Cliente que opera só via painel tem churn de 30% no primeiro ano.
Isso muda quem é o cliente certo: não é o CFO que quer "gestão de despesas" geral — é o time de engenharia/dados que quer infraestrutura financeira programável. O CFO vem junto. Não o contrário.
A coisa mais difícil
A coisa mais difícil em construir API de cartões pré-pago no Brasil em 2024–2026 não foi técnica. Foi convencer que o mercado existe.
Toda conversa com VC nos primeiros 12 meses começava com: "vocês são Brex/Ramp para o Brasil?" — e a gente explicando que não, somos infra de pagamento programático, não cartão de funcionário. Os investidores que entenderam fecharam rápido. Os que insistiram em comparar fizeram a gente perder semanas.
Lição: se você está construindo categoria nova, gaste mais tempo escrevendo o que você não é do que o que você é. O posicionamento por contraste é mais barato que posicionamento por inovação.
O que vem
Os próximos 12 meses são sobre escala: mais países (Argentina, México, Colômbia em pipeline), mais moedas, e principalmente — virar issuer direto, eliminando o sponsor bank.
Mas a tese continua: cartão corporativo é primitiva de orquestração financeira, não plástico. Quem entendeu isso primeiro, ganhou. Quem ainda está vendendo cartão master "com app" está vendendo o passado.
Obrigada a quem confiou na v0, na v1, na v2. E pronta pra fazer o ridículo de novo na v3.