Três fraudes em cartão corporativo que reescreveram nosso roadmap de gestão de despesas

Toda startup B2B brasileira que opera com cartão corporativo acaba colecionando histórias de fraude. As nossas — coletadas em três anos atendendo empresas que tinham cartão master único — reescreveram inteiramente o roadmap do HubCard. Esse post conta três delas. Os nomes das empresas estão alterados; os números são reais.

Caso 1 — O CMO que rodou R$ 84 mil em ads do concorrente

Empresa: SaaS de 40 pessoas. Cenário: cartão corporativo único pagando todos os fornecedores de marketing.

O CMO saiu da empresa em outubro. Saiu mal. Antes de devolver o notebook, criou uma conta no Google Ads com o cartão corporativo (que ele tinha tokenizado em Apple Pay seis meses antes, para aprovar pré-autorização) e configurou uma campanha agressiva para o produto do concorrente direto.

A campanha rodou 17 dias. R$ 84.327 em cliques. Quando a controladoria viu o lançamento na fatura, a campanha já tinha sido pausada (manual, sem aviso) e a conta no Google Ads tinha sido fechada. Provar foi possível — recuperar o dinheiro, não. Google Ads exige fluxos formais com janela curta para disputa de chargeback.

O que mudou no produto: tokenização em wallets agora é escopada por cartão. Cada cartão corporativo emitido pelo HubCard tem flag wallet_tokenizable: bool. Cartões usados em fluxos críticos (mídia paga, cloud) vêm com a flag desligada por default. Quem precisar tokeniza explicitamente.

E mais importante: ao desligar um colaborador, o RH dispara um webhook que revoga todos os tokens wallet vinculados ao cartão dele em batch. Não dá para tokenizar o que já está cancelado, e os tokens existentes morrem em horas, não meses.

Caso 2 — O agente de IA que provisionou GPU durante o feriado

Empresa: fintech early-stage. Cenário: agente de IA com permissão para emitir cartões via API de cartões pré-pago, sem teto global.

Era 31 de dezembro. Todo mundo de férias. Um pipeline de fine-tuning entrou em loop tentando emitir cartões para provisionar instâncias H100 na Lambda Labs. O bug: a chave de idempotência incluía timestamp no millisegundo, então cada retry virava cartão novo. Em 4 horas, 312 cartões foram emitidos, cada um com limite de US$ 200.

O processador externo começou a recusar emissões aos 280. O Lambda Labs começou a recusar cobranças aos 47. Mas R$ 38.412 já tinham sido autorizados e capturados em GPUs que ninguém estava usando.

O que mudou no produto: três coisas.

1. Rate limit por chave de API: cada api_key tem teto de cartões emitidos por hora. Default conservador (20/h), aumentável sob pedido.
2. Teto global por organização: a soma de limit_cents de cartões ativos não pode exceder X por padrão.
3. Idempotency-Key agora é mandatória em POST /v2/cards. Sem ela, 400. Antes era opt-in.

Esse incidente também virou um post separado sobre idempotência na API de emissão, porque a lição vale para qualquer endpoint que move dinheiro.

Caso 3 — A planilha compartilhada que sabia o CVV

Empresa: agência de growth, 12 pessoas. Cenário: planilha do Google Drive compartilhada entre todos, com os números do cartão corporativo de pagamento de mídia.

A justificativa de existir essa planilha: "as pessoas precisam saber o número pra cadastrar nas plataformas". Foi compartilhada com o link público, sem autenticação, sem auditoria de quem acessou. Em algum momento de 2025 vazou. Apareceram cobranças de um e-commerce em Hong Kong, US$ 1.200 por dia, durante 6 dias, antes de alguém notar.

A empresa cancelou o cartão. Todos os fornecedores que rodavam nele caíram. Levou 11 dias para reativar tudo, com Google Ads pausado durante 4 dias na alta temporada de Black Friday.

O que mudou no produto: dois pivots.

1. PAN nunca aparece em UI por default. O painel mostra •••• 7102. Para ver o PAN completo, é necessário um passo extra com 2FA e log de auditoria. Mesmo o admin. Mesmo o owner.
2. Cada API key tem escopo de leitura granular. A maioria das integrações precisa apenas listar cartões e ver status + last_four. Nunca o PAN. Quem precisa do PAN (ex.: cadastrar manualmente em fornecedor sem painel) pede via fluxo específico, com 2FA, e a operação fica no audit log.

O padrão por trás

As três fraudes têm o mesmo formato: uma credencial compartilhada que ninguém revoga porque revogar quebra muita coisa.

A solução não é fazer credenciais melhores. É eliminar a categoria de credenciais compartilhadas. Quando cada cartão é dedicado a uma relação (um fornecedor, um agente, um job), revogar não tem custo lateral.

Cada incidente aprendido reforça uma decisão: na gestão de despesas moderna, o cartão é descartável por design. Um cartão deve durar exatamente o tempo da relação que ele representa — nem um dia a mais.

O que ficou no roadmap depois

Esses três casos viraram features que hoje são padrão:

• Wallet tokenization escopada por cartão, com webhook de revogação em massa.
• Rate limit por API key + teto global por organização em POST /v2/cards.
• PAN protegido por 2FA + audit log obrigatório.
• MCC defaults agressivos para cartões de categorias críticas (ads, cloud) — não é possível autorizar fora do MCC esperado.
• Alertas em tempo real para anomalias: cartão que normalmente cobra R$ 5k/mês e de repente cobra R$ 20k em 2h aciona webhook automático.

Se você é founder de fintech: documente seus incidentes. Cada um vira uma feature que evita o próximo. As três histórias acima existiram justamente porque ninguém antes da gente tinha tratado cartão corporativo como objeto programático com ciclo de vida controlado pelo dono do gasto, não pelo dono do plástico.