Era 23h47 de uma quarta-feira em fevereiro quando recebi o print no WhatsApp: a fatura do cartão corporativo da minha empresa anterior tinha R$ 38.412 de cobranças em Google Ads de uma conta que o time havia trocado de agência havia quatro meses. A nova agência herdou as credenciais. As campanhas pausadas reativaram. Ninguém revisava o e-mail do dono original. E a única forma de parar a sangria era cancelar um cartão único que rodava outros 39 fornecedores.
Aquele incidente é a razão pela qual hoje, no HubCard, cancelar um cartão corporativo é literalmente um DELETE numa API REST.
A ligação que não atendeu
Liguei para o banco. Robô. Disse "cancelar cartão". Robô. Disse "falar com atendente". Robô. Vinte e dois minutos depois, uma pessoa atendeu e disse que a cobrança não poderia ser revertida porque tinha sido autorizada. Para evitar mais, eu precisava cancelar o cartão. Mas isso ia derrubar todos os outros fornecedores rodando no mesmo número.
Você está me dizendo que para parar de pagar uma campanha eu preciso parar de pagar tudo?
Aquilo não fazia o menor sentido. Toda a infraestrutura financeira da empresa estava amarrada num único objeto físico que eu só conseguia operar via call center, em horário comercial, com confirmação por SMS no celular do CFO que estava de férias na Bahia.
Cartão como objeto, não como artefato
A premissa do HubCard nasceu naquela noite: um cartão corporativo precisa ser um objeto programático, com ciclo de vida exposto via API, igual qualquer outro recurso de infra. Não um pedaço de plástico. Não um número impresso. Não uma cadeia de SMSs e e-mails.
Quando você pensa cartão como objeto, três coisas se tornam óbvias:
- Você não cancela o cartão master. Você cancela o objeto que representa a relação com aquele fornecedor.
- Cada objeto tem seu próprio ciclo:
created,active,paused,cancelled. Webhooks por evento. Audit log nativo. - Mudanças não precisam de aprovação humana se vierem com a credencial certa. Idempotência resolve race conditions.
Na prática, isso significa que cancelar um cartão vira:
# cancelar cartão do Google Ads — agora, sem ligar pra ninguém
curl -X DELETE https://api.hubcard.one/v2/cards/card_01HX7P3M9 \
-H "Authorization: Bearer sk_live_••••" \
-H "Idempotency-Key: cancel_gads_2026_05_14"
# resposta em ~140ms
{
"id": "card_01HX7P3M9",
"status": "cancelled",
"cancelled_at": "2026-05-14T23:48:11Z"
}
Os outros 39 fornecedores? Continuam rodando, no cartão deles. Isolamento por design.
Quatro endpoints e nada mais
Quando começamos a desenhar a API v1, listei todos os verbos que um cartão poderia precisar. A primeira versão tinha onze endpoints diferentes: emitir, listar, pausar, retomar, cancelar, atualizar limite, atualizar metadata, suspender temporariamente, gerar virtual, recuperar PAN, exportar. Cada um com sua lógica, seus erros, seu rate limit.
Olhei para isso e percebi que tinha reproduzido exatamente o problema que estava tentando resolver: complexidade artificial. Reescrevemos com quatro verbos.
Toda mudança de cartão é POST /cards (criar), PATCH /cards/:id (atualizar — inclui pausar/retomar via status), DELETE /cards/:id (cancelar) ou GET /cards/:id (ler). Quatro verbos. Idempotency-Key resolve race conditions. Migrar de onze para quatro endpoints foi a única decisão de arquitetura que ninguém reclamou depois.
O efeito colateral: auditoria de graça
Quando cada relação de pagamento é um objeto isolado, auditoria deixa de ser um exercício mensal e vira uma view. A controladoria não precisa mais cruzar planilha de fatura com planilha de fornecedor com planilha de centro de custo. Cada cartão já carrega isso como atributo.
Em entrevistas com clientes early-stage, a métrica que mais ouvi foi: "reduzimos o fechamento de 6 dias para 90 minutos". Não porque a contabilidade ficou mais rápida — porque a categorização ficou implícita no esquema. Cada transação carrega card_id, e cada cartão carrega supplier, cost_center, tags. Não há onde se perder.
Agentes que pagam contas
Há um efeito menos óbvio que descobrimos depois do lançamento: agentes de IA passaram a usar a API de cartões pré-pago para se auto-financiar. Um cliente nosso roda um agente de pesquisa que provisiona instâncias de GPU sob demanda. Antes, ele precisava ter um cartão pré-cadastrado na Lambda Labs com limite generoso. Hoje, o agente emite um cartão com limite exato para a job, executa, e DELETE ao final.
Isso muda o que significa "infraestrutura paga por demanda". Não é mais o serviço sendo cobrado por uso — é o pagamento sendo provisionado por uso. A primitiva é diferente.
O que muda no fechamento
Três meses depois de migrar uma empresa de 60 pessoas inteiramente para o modelo:
- Tempo de fechamento mensal: de 6 dias úteis para 4 horas.
- Reembolsos pendentes: caiu 94%, porque ninguém mais usa cartão próprio achando que vai recuperar depois.
- Disputas de chargeback: -71%, porque cada cartão sabe exatamente para qual fornecedor está autorizado.
- Tempo médio para cortar um fornecedor: de 22 minutos no telefone para 140 milissegundos numa API.
O último número é o que importa. Em pagamentos B2B, velocidade de reverter uma decisão é a métrica que ninguém mede mas todo mundo precisa. Empresas pequenas perdem dinheiro por não conseguir parar uma cobrança que já foi autorizada. Empresas grandes perdem por não conseguir parar 40 cobranças porque a aprovação precisa subir três camadas hierárquicas.
O cancelamento como POST não é elegância de engenharia. É a forma mais barata de devolver autonomia ao time que opera o dinheiro.