BETAHubCard beta — feedback bem-vindo.
HubCardhubcard
Começar
v2 · agora com idempotência

Um cartão por fornecedor.

HubCard é a plataforma de cartões corporativos virtuais e pré-pagos com API de emissão e gestão de despesas em tempo real — um cartão dedicado por fornecedor, via API ou painel. Auditoria limpa, cancelamento granular, automação na borda.

Começar agoraLer a doc
setup < 5 minpci dss l1brl · usd · eur
painel · cartõeslive
OA
OpenAI
engineering · usd
•••• 7102R$ 6.123,40
GA
Google Ads
marketing · br
•••• 4821R$ 18.420,17
AW
AWS
platform · usd
•••• 0501R$ 11.876,50
AN
Anthropic
engineering · usd
•••• 3340R$ 1.872,00
FG
Figma
design · usd
•••• 1928R$ 1.440,00
gasto · maioR$ 142.380,00
usado por times emplúriacontabofoursightcardume.ainoduloaerolabsextante
api · v2

API de cartões pré-pago: emita via POST, cancele via POST.

API REST para emitir cartões corporativos virtuais e pré-pagos, definir limites e MCC, tokenizar em Apple Pay e Google Pay e consumir webhooks tipados. Idempotência nativa, paginação por cursor — pronta para agentes de IA.

cli · hubcard
$hubcard cards create --vendor openai --limit 2000 --currency usd
 
Cartão criado
├─ id         card_8x2m9
├─ vendor     openai
├─ limit      USD 2.000 / mês
└─ status     active
 
?Encaminhar transações para webhook? (Y/n) Y
 
Webhook conectado · ouvindo transaction.authorized
casos de uso

Gestão de despesas corporativas com cartões dedicados por fornecedor.

Mídia paga

Um cartão por canal. Cancelamento sem afetar campanhas vizinhas.

google adsmetalinkedintiktok

Infraestrutura

Cloud, observabilidade, CDN. Tetos defensivos contra autoscale fora de controle.

awsgcpcloudflaredatadog

SaaS corporativo

Cada ferramenta com seu cartão. Cobrança por squad, sem ligação para o banco.

figmanotionlineargithub

APIs de IA

Cartões provisionados por agente, com teto e ciclo de vida próprios.

openaianthropicgoogle aireplicate
preços

Preços simples, escala honesta.

Free
$0/mês
  • 3 cartões ativos
  • 100 transações/mês
  • API + painel web
  • 1 webhook
  • 1 membro de equipa
Começar
Developer
$20/mês
  • 25 cartões ativos
  • 1.000 transações/mês
  • Acesso MCP para agentes
  • 5 webhooks
  • 3 membros de equipa
Começar
MC

Marina Costa

@marinacode

“Migramos todos os fornecedores internacionais para cartões dedicados em uma semana. A fatura virou auditável de verdade — cada lançamento tem dono.”

Citado em

  • Fintech Brainfood
  • Stratechery
  • AI Weekly
Ver comparativo completo de planos
Blog

Notas do time.

Ver todos

19 de maio de 2026

Dê um cartão para seu robô: por que cada agente de IA precisa do próprio cartão pré-pago

Em algum ponto dos últimos 18 meses, agentes de IA pararam de ser chatbots e viraram funcionários que pagam contas . Eles provisionam instâncias de GPU, assinam APIs, compram tokens de modelo, contratam serviços de scraping, alugam workers no Modal. E a maioria dos times está resolvendo isso da pior forma possível: compartilhando o cartão corporativo da empresa com o agente . Esse post é sobre por que cada robô precisa do próprio cartão pré-pago dedicado — e como dar isso a ele em uma chamada de API. A gambiarra atual O setup típico em produção hoje: Empresa tem um cartão corporativo master (de quem? do CFO). Engenheiro cadastra esse cartão na Lambda Labs, OpenAI, Anthropic, AWS, Modal, etc. Agente roda e cobra desse cartão. Quando o agente entra em loop, alguém precisa acordar e cancelar o cartão (derrubando todos os outros 30 serviços que dependem dele). Isso não escala. Não escala em risco (uma credencial cobre tudo), não escala em observabilidade (qual cobrança veio de qual agente?), não escala em contabilidade (como reembolsar o custo do agente para o cliente certo?). A primitiva certa: cartão por agente A regra que aplicamos no HubCard: cada agente que move dinheiro tem o próprio cartão . Não compartilha com humano, não compartilha com outro agente. Quando o agente é instanciado, emite. Quando é destruído, cancela. Os efeitos imediatos: O agente não pode gastar mais que o orçamento dele. Cartão tem hard cap. O agente não pode cobrar fora do MCC esperado. Se tentar pagar uma TV em Hong Kong, declinado. Você sabe exatamente quanto cada agente custou. em cada . Se o agente sair do controle, cancelar não derruba mais nada . A regra "um cartão, um agente" Vejo times caindo na tentação de "vamos ter um cartão por tipo de agente". É um meio-termo ruim. O custo de emitir um cartão extra é zero. O benefício de ter granularidade até a instância é alto. Regra prática: Agente persistente (assistant do cliente, agente de scraping diário): cartão por instância, com renovação automática mensal. Agente efêmero (job de fine-tune, sprint de pesquisa): cartão por job, expira no fim. Agente experimental (devs testando idea nova): cartão por dev por experimento, expira em 7 dias por default. Cada uma dessas categorias mapeia para um padrão de emissão. Quando dúvida, mais granular sempre. Webhook como olho do controlador O agente não fala diretamente com o sistema de monitoramento. O sistema observa as transações do cartão dele via webhook tipado: Esse pattern é o que separa "agente que paga contas" de "agente que torra dinheiro sem ninguém perceber". O controlador escuta o que o cartão diz — não confia no que o agente reporta. "Mas e se o agente for malicioso?" A pergunta que sempre aparece: e se o LLM for prompt-injectado e o agente tentar emitir um cartão de US$ 1M? Respostas em camadas: A API key do agente tem role limitada. Permissão com cap de por cartão. Mesmo se o agente quiser, não pode. Rate limit por API key. Máximo X cartões/hora. Bloqueia loops. Teto global por organização. Soma de ativos tem ceiling. Acima disso, 429. Audit log. Toda emissão registra . Investigação é trivial. Cancelamento humano sempre prioritário. Owner cancela qualquer cartão via painel ou CLI a qualquer hora. Modelagem de risco igual a dar credencial AWS pra agente: você confia no escopo, não na credencial. MCP: dar cartão é uma ferramenta A forma mais limpa de dar cartão ao agente é via MCP server (Model Context Protocol). O agente vê isso como uma ferramenta: Claude, GPT e qualquer modelo compatível com MCP usam isso de forma natural. O modelo "decide" emitir um cartão quando precisa pagar algo, executa, e cancela depois. Sem você ter que escrever orchestration custom. Detalhamos esse padrão em API de cartões pré-pago para agentes de IA . O efeito cultural Quando você dá cartão ao robô, algo muda na forma como o time pensa: Agentes começam a ter orçamento explícito , não "use o cartão da empresa". Reviews de agente passam a incluir "qual o gasto previsto vs realizado". Custo de IA vira observável por unidade de trabalho , não linha agregada na fatura. Devs param de medo de testar agente novo, porque o blast radius é o limite do cartão. Esse último é talvez o ganho mais importante. A maior barreira pra experimentar com agentes hoje é financeira, não técnica. Remover essa barreira destrava categoria nova de produto. O que NÃO recomendamos Um cartão para "todos os agentes da empresa" : perde granularidade, vira mini-master. Cartão com limite "alto pra qualquer caso" : defeats the purpose. Limite deve ser orçamento real + 5–10%. Cartão sem : agente que esqueceu de cancelar vira cobrança eterna. Sempre defina expiração. Cartão sem : você vai precisar dessa info quando o webhook chegar. Sempre tagueie. Dê o cartão hoje Se você opera agentes em produção, dar a cada um seu próprio cartão pré-pago não é otimização — é arquitetura mínima. Compartilhar credencial entre agente e empresa (ou entre agentes) é a versão 2026 de hardcodar password no código. Comece com a API de cartões pré-pago ou veja o MCP server do HubCard para integrar com Claude e GPT em minutos. Seu robô merece o próprio plástico (virtual).

Ler artigo

17 de maio de 2026

Como usar o MCP de cartões HubCard: dê a Claude e GPT acesso programático a cartões pré-pago

O MCP (Model Context Protocol) virou o jeito padrão de dar ferramentas a agentes de IA. Claude Desktop, Claude Code, Cursor, Windsurf e a maioria dos clientes modernos consomem MCP nativamente. Esse post é o tutorial prático de como instalar e usar o MCP server do HubCard — para que seu agente de IA possa emitir, listar e cancelar cartões pré-pago sem você escrever uma linha de orquestração. O que o MCP do HubCard expõe Sete ferramentas: Tool O que faz --- --- Emite um cartão pré-pago novo com limite, MCC, currency, validade Lista cartões da organização com filtros (status, supplier, tags) Detalhes de um cartão específico (sem expor PAN por default) Atualiza limite, status (pause/resume), tags Cancela cartão definitivamente Lista transações com filtros (card id, period, MCC) Saldo da organização e teto disponível para novas emissões Cada ferramenta é descrita com schema JSON-Schema, descrição clara, exemplos de uso e limitações. O agente decide quando usar baseado no contexto. Pré-requisitos Conta no HubCard (free é suficiente pra começar — 3 cartões ativos, 100 transações/mês). Uma API key com permissão e . Gere em . Node.js 20+ instalado localmente (o MCP server roda como subprocess). Instalação no Claude Desktop Abra o arquivo de configuração do Claude Desktop: macOS : Linux : Windows : E adicione: Salve, reinicie o Claude Desktop. Você verá um ícone de ferramentas indicando que o MCP do HubCard está conectado. Instalação no Claude Code (terminal) No Claude Code (CLI), basta: Pronto. O lista o server ativo, e o agente já tem acesso às 7 ferramentas em qualquer sessão. Instalação no Cursor / Windsurf Cursor e Windsurf usam o mesmo formato do Claude Desktop. O caminho do config varia, mas o JSON é idêntico. Primeira conversa com o cartão Com o MCP rodando, abra uma conversa nova e teste: Emita um cartão pré-pago dedicado para a OpenAI com limite de US$ 50, válido por 30 dias. O agente vai: Identificar que precisa de . Preencher os parâmetros: , , , , . Gerar uma única. Chamar a ferramenta. Retornar o , mascarado e dados de expiração. Você confirma o uso (ou pré-aprova se está em modo agente). O cartão sai. Sem você ter aberto o painel. Casos de uso reais Agente de pesquisa que provisiona GPU Agente operador financeiro Bot de Slack que emite cartão sob demanda Em vez de o time pedir cartão por mensagem para o ops, o agente faz: O agente entende, chama , devolve o PAN mascarado e o ID. Quem precisar do PAN completo abre o painel com 2FA. Segurança e escopo A API key que você dá ao MCP define o escopo do que o agente pode fazer . Recomendações: Crie uma API key dedicada para o MCP , não reutilize a key da sua integração de prod. Use role se quiser cap automático de por cartão. Configure rate limit na key (e.g., 10 cartões/hora) para conter loops. Ative alertas para anomalias: cartão emitido fora de horário comercial, valor acima do P95 histórico, etc. Revogue a key se trocar de máquina, especialmente se tiver compartilhado com claude-code session de outro user. A chave nunca sai da sua máquina (o MCP server é local), mas tratar como password é a higiene mínima. Auditoria Toda chamada do MCP fica registrada no audit log do HubCard com: : indica que veio do MCP ( ) : nome do cliente MCP (Claude Desktop, Claude Code, etc.) (opcional): pra identificar a máquina Você consegue ver no painel exatamente quando e por qual ferramenta cada cartão foi emitido. Em time, é a forma de saber qual dev/agente fez o quê. Limitações conhecidas PAN completo nunca retorna via MCP por default. Para usar o cartão programaticamente, o agente recebe ( ). Para receber o PAN completo, configure no MCP server (não recomendado por default). retorna até 100 por chamada. Para volume maior, pagine via . MCP é stateless. Cada call carrega seu próprio contexto. Para fluxos com múltiplas chamadas, o agente reusa o retornado. Próximos passos Se você opera agentes em produção, o MCP é a forma mais barata de dar a eles acesso a cartões corporativos pré-pago . Para o padrão por trás disso, leia dê um cartão para seu robô . Quem está construindo plataforma de agentes (LangChain, LangGraph, AutoGen, frameworks próprios) também tem SDK Python e TypeScript caso prefira integração direta. MCP é o caminho rápido; SDK é o caminho profundo. Instalou? Manda no Twitter/X com print do primeiro cartão emitido pelo agente. Curtimos esse tipo de coisa.

Ler artigo

16 de maio de 2026

Por que você precisa de um cartão corporativo com Full API: o que muda quando todo verbo é HTTP

A maior parte dos cartões corporativos brasileiros tem "API" no marketing e dois endpoints reais : listar transações e bloquear cartão. O resto continua sendo painel web ou ligação para o gerente. Esse post é sobre por que Full API — todo verbo do cartão como HTTP — não é nice-to-have; é o requisito mínimo de gestão de despesas em 2026. O que "Full API" significa Full API quer dizer: tudo o que o painel faz, a API REST faz . Sem exceção. Sem "essa operação requer aprovação manual no telefone". Sem "pra isso fale com a sua gerente de conta". A lista mínima: Operação Endpoint Resposta esperada --- --- --- Emitir cartão 200 com PAN, ID e status Listar cartões 200 com paginação por cursor Detalhar cartão 200 com saldo, transações, metadata Atualizar limite 200 com novo estado Pausar cartão 200 imediato Retomar cartão 200 imediato Cancelar 200 final Listar transações 200 com filtros Webhooks de eventos (push) schema tipado, idempotency key Disputas/chargebacks 200 com ticket ID Tokenização wallet 200 com token Se o seu cartão "tem API" mas qualquer uma dessas operações exige call center, não tem Full API . Tem API parcial — que é pior, porque sugere automação possível e não entrega. A diferença prática Cartão com API parcial (a maioria do mercado) Cenário: você descobre 23h de quarta que um fornecedor está cobrando 3x o valor combinado. Você quer pausar só esse fornecedor e investigar amanhã. Liga no SAC. Robô. 22 minutos. Pessoa atende, pede confirmação por SMS no celular que está com outra pessoa. "Para pausar, vamos precisar cancelar o cartão inteiro." Você decide aguentar até de manhã. Amanhã: 30 minutos de processo formal, 11 fornecedores afetados. Cartão com Full API (HubCard) Você volta a dormir. Os outros 30 fornecedores continuam rodando. De manhã, investiga com calma e ou cancela ou retoma. A diferença não é tempo. É autonomia operacional . Detalhamos isso em por que cancelar um cartão corporativo deveria ser um POST . O que Full API destrava Orquestração por agentes Agentes de IA só podem mover dinheiro de forma segura se tiverem endpoints programáticos com limite, escopo e cancelamento. Sem Full API, você confia no agente; com Full API, você confia no escopo. Veja dê um cartão para seu robô e como usar o MCP do HubCard . Fechamento contábil em tempo real Webhook tipado dispara em milissegundos. Seu ERP recebe antes mesmo de a transação aparecer no painel. Conciliação contábil deixa de ser exercício mensal e vira processo contínuo. Detalhes em webhooks tipados na API de cartões . Auditoria como query Sem Full API, auditoria é Excel cruzando PDF. Com Full API, auditoria é SQL no warehouse. Três queries de 15 minutos toda sexta detectam SaaS órfão, anomalia de teto e vendor lock-in. Playbook em auditoria de fornecedores em 15 minutos . Cartão por job, por agente, por experimento Quando emitir é um e cancelar é um , o custo marginal de criar cartão extra é zero. Isso destrava padrões impossíveis com cartão master: Cartão por job de fine-tune : limite = orçamento + 10%, expira ao final. Cartão por campanha de growth : cada campanha tem seu próprio cartão, auditoria isolada. Cartão por experimento de dev : dev testa nova API sem medo de "estourar o cartão da empresa". Self-service real Quando engenharia consegue emitir e cancelar cartão sem fila, o time financeiro deixa de ser polícia . O CFO opera por exceção, não por aprovação. Em casos como o da Plúria , o tempo do CFO em "aprovação de cartão" caiu de 6h/semana para zero. O que não é Full API Lista do que não conta: ❌ Endpoint que retorna PDF da fatura. ❌ "API" que envia email pro suporte. ❌ Webhook não tipado, JSON livre, sem schema versionado. ❌ Endpoint que existe mas tem rate limit hostil (3 calls/minuto). ❌ Documentação "sob NDA". ❌ "Tem API mas precisa habilitar com nosso time comercial." Se você se identificou com qualquer um desses, você não tem cartão com Full API. Tem cartão com fachada de API. Os argumentos contra Full API (e por que estão errados) "Risco de fraude é maior se tudo é API" Falso. Cartão com Full API tem , rate limit, audit log e webhooks de anomalia. Cartão sem API tem PDF mensal e ligação. Qual é mais fraudável? "A maioria das empresas não precisa de API" Talvez não em 2020. Em 2026, qualquer empresa com 20+ fornecedores recorrentes precisa. E em 2027, qualquer empresa que opera agentes em produção precisa por sobrevivência. "API é coisa de empresa grande" Inverso. Empresa pequena precisa mais de API — porque não tem time para operar processo manual. Os clientes mais ativos da nossa API são startups de 5–20 pessoas com 40+ fornecedores cada. "Vamos lançar API ano que vem" Quem está prometendo Full API "no roadmap" tipicamente está há 3 anos prometendo. Não é prioridade comercial deles. Não vai sair. O teste do café A forma rápida de descobrir se o seu fornecedor de cartão tem Full API real: "Posso emitir um cartão, ajustar limite, pausar, retomar e cancelar — tudo via API, sem qualquer aprovação manual, em menos de 60 segundos por operação?" Se a resposta tiver "sim, mas", a resposta é "não". Como o HubCard se posiciona A gente nasceu Full API. 4 verbos REST cobrem 100% do ciclo de vida do cartão. Webhooks tipados entregam todo evento com schema versionado. Idempotência obrigatória garante que retry é seguro. MCP server expõe tudo isso pra agentes Claude/GPT. SDKs em 4 linguagens (TypeScript, Python, Go, Ruby) com tipos garantidos. Documentação OpenAPI publicada, versionada e válida — não PDF. Não é diferencial, é o desenho. Se você está avaliando provedor de cartões corporativos ou API de cartões pré-pago , Full API tem que ser linha de base — não checkbox. E se você ainda está operando com cartão sem Full API hoje, o playbook de migração em 60 dias cobre como sair. Cartão sem API é planilha. Cartão com Full API é infraestrutura. Escolha o que você quer integrar no seu stack.

Ler artigo

14 de maio de 2026

Por que cancelar um cartão corporativo deveria ser um POST, não uma ligação para o banco

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 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: , , , . 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: 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 é (criar), (atualizar — inclui pausar/retomar via ), (cancelar) ou (ler). Quatro verbos. 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 , e cada cartão carrega , , . 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 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.

Ler artigo

12 de maio de 2026

Idempotência sem dor na API de emissão de cartões: a chave que sobrevive a retries agressivos

No primeiro semestre de 2026, nossa API de emissão de cartões corporativos processou 2 milhões de requisições duplicadas — e nenhuma delas criou um cartão extra. Esse post é sobre como projetamos a chave de idempotência que sobreviveu a retries agressivos de clientes, agentes de IA com jitter mal calibrado e webhooks que insistiam em reentregas mesmo depois de 2xx. Por que idempotência importa em emissão de cartões Emitir um cartão pré-pago não é uma operação inócua. Envolve provisionar BIN range, alocar saldo, registrar no processador, gerar PAN e tokenizar para wallets. Se a operação acontece duas vezes, você tem dois cartões reais, dois saldos bloqueados, e uma reconciliação cansativa. Quando um cliente roda e o response demora 2.4s, é totalmente racional que ele dispare um retry. Em sistemas com fila de eventos, é racional que o handler reentregue. Em agentes de IA com jitter mal calibrado, isso vira tempestade. A regra é simples: a mesma chave de idempotência tem que produzir exatamente o mesmo recurso, mesmo um ano depois . A primeira versão (que quebrou) Nossa primeira tentativa foi a clássica: hash do body como chave. Recebia o request, calculava SHA-256 do payload normalizado, buscava em Redis, devolvia o resultado armazenado. Quebrou em três cenários: Timestamps no payload : cliente que incluía gerava hash diferente a cada retry. Cartão duplicado. JSON com chaves em ordem diferente : o mesmo client gerando e produzia hashes diferentes. Encoding de Unicode : caracteres acentuados em mudavam a representação bytes. A lição: a chave de idempotência tem que ser fornecida pelo cliente , não derivada do payload. O cliente sabe o que é uma operação única. Você não. O padrão Adotamos o header , inspirado em Stripe. A regra do contrato: A chave vive 24h em Redis. Cada chave armazena: O request hash (para validar que o body é o mesmo) O status do request ( ) O response completo (status code + body + headers relevantes) Comportamentos: Se a chave não existe : marca como , processa, salva resultado, retorna. Se a chave existe como : retorna o response cached, sem reprocessar. Se a chave existe como : bloqueia até 10s aguardando, depois retorna 409. Se a chave existe mas o request hash difere : retorna 422 — você está usando a mesma chave para operações diferentes, isso é bug. Por que importa O cenário que mais nos mordeu não foi retry — foi paralelismo. Cliente disparava o mesmo em duas threads simultaneamente. Sem lock, ambos achavam que a chave não existia, ambos criavam cartão. O resolve isso com no Redis: a primeira thread vence o lock. As outras veem e esperam. Quando a primeira termina, escreve o resultado e libera. As outras leem o resultado pronto. Para os 0.3% dos casos em que o lock expira antes do processamento terminar (processador externo lento), retornamos 409 e logamos. O cliente pode tentar de novo com a mesma chave. A armadilha do storage Idempotency-Key parece simples até você precisar: TTL : 24h é o sweet spot. Menos, retries de webhooks falham. Mais, storage explode. Garbage collection : Redis com resolve. Não use TTL em DB relacional — vai virar bottleneck. Migração : quando rotacionar a chave de hash, mantenha leitura compatível por 48h. Multi-região : replicação eventual mata idempotência. Use o mesmo Redis primário, ou um lock distribuído. O endpoint de inspeção Adicionamos para o cliente inspecionar. Retorna status atual, request hash, response cached. Útil em debugging quando o cliente acha que mandou X e o servidor recebeu Y. O resultado, em números Depois de seis meses com esse desenho: 2.04 milhões de requisições duplicadas detectadas (≈ 14% do volume total). Zero cartões duplicados emitidos por bug de idempotência. Latência adicional : 4ms p99 para lookup no Redis. Falsos positivos (mesmo Idempotency-Key + body diferente): 312 casos, todos bugs de cliente — devolvidos com 422 e mensagem explícita. Idempotência não é um nice-to-have. É a forma de dizer aos integradores: "retry à vontade. Você nunca vai cobrar duas vezes." . Se você está construindo uma API de cartões pré-pago ou qualquer endpoint que move dinheiro, isso precisa ser commodity.

Ler artigo

9 de maio de 2026

Gestão de despesas: o playbook que zera seu cartão corporativo master em dois meses

Toda gestão de despesas corporativas competente eventualmente esbarra no mesmo problema: o cartão master. Aquele cartão com nome do CFO que paga 40 fornecedores diferentes, vira a fatura em PDF de 84 páginas, e exige três pessoas para reconciliar. Esse post é o playbook que usamos para zerar a fatura do cartão master de uma empresa de 80 pessoas em 60 dias, migrando todos os fornecedores para cartões corporativos dedicados por relação. Não é teoria — é cronograma com responsável, etapa e métrica. Por que matar o cartão master A defesa do cartão master sempre vem em três argumentos: "É só um cartão, é simples." Não é. O custo invisível é a hora-pessoa que reconcilia. "O banco já me conhece." O banco te conhece como cliente; não conhece o fornecedor. "Cancelar todos os fornecedores é trabalhoso." Cancelar um fornecedor que descobriu falha é catastrófico. O cartão master concentra três riscos: fraude (quem rouba esse cartão captura tudo), operacional (cancelar para conter um vazamento derruba 40 serviços) e contábil (categorização vira processo manual mensal). Trocar por cartões dedicados resolve os três simultaneamente. Fase 1 — Levantamento (dias 1–7) Antes de mover nada, mapeie. Extraia 12 meses de fatura do cartão master e categorize cada cobrança. A planilha mínima: Fornecedor MCC Cobranças/mês Ticket médio Moeda Centro de custo --- --- --- --- --- --- Google Ads 7311 4 R$ 5.420 BRL marketing OpenAI 5734 12 US$ 240 USD engineering AWS 7372 1 US$ 1.812 USD platform Figma 5817 1 US$ 45 USD design Em média, 60% das cobranças vêm de 20% dos fornecedores . Esses são os candidatos óbvios para migrar primeiro. Fase 2 — Onboarding técnico (dias 7–14) Crie a conta na plataforma de API de cartões pré-pago que vai gerir a emissão. Configure: Membros : quem pode emitir, quem pode aprovar, quem só lê. Centros de custo : replique a estrutura do ERP. MCC defaults por tag : cartão "ads" só autoriza MCC 7311–7372, cartão "saas" só 5734–5818, etc. Webhooks : aponte para o seu BI ou ferramenta de fechamento para receber em tempo real. Esse setup leva entre 4 e 8 horas se feito com cuidado. É a parte mais ingrata e a mais importante. Fase 3 — Pilot com 5 fornecedores (dias 14–21) Escolha 5 fornecedores que cabem em três categorias: alto volume baixa criticidade (Google Ads, Meta Ads), baixo volume alta criticidade (AWS produção), e caso ruim (algum SaaS que historicamente já deu chargeback). Para cada um: Emita o cartão dedicado via API ou painel. Atualize a forma de pagamento no painel do fornecedor. Confirme a primeira cobrança bem-sucedida. Só então desative a forma de pagamento antiga no master. A regra de ouro: nunca remover o master antes de confirmar a primeira autorização no novo. Sobreposição custa zero em juros, mas evita um incidente. Fase 4 — Rollout em ondas (dias 21–45) Com o pilot validado, faça ondas de 8 fornecedores por semana. Comunique o calendário ao time: Segunda : emissão dos cartões da semana, comunicação para os donos dos serviços. Terça–Quinta : trocas no painel de cada fornecedor. Sexta : validação. Cobranças vieram pelo novo cartão? Limites suficientes? MCC bateu? Em 4 semanas você cobre 32 fornecedores. Sobram os que tradicionalmente são chatos: SaaS legados com formulário de troca via e-mail, fornecedor que cobra "pré-aprovação" da operadora, qualquer fornecedor que use boleto disfarçado. Fase 5 — A cauda longa (dias 45–60) Os últimos 15–20% são onde a operação trava. Estratégias por caso: Fornecedor que exige IBAN : emita um cartão virtual, tokenize em Apple/Google Pay, use para pagar via merchant gateway. Fornecedor que cobra pré-autorização altíssima : configure o cartão com igual ao valor da pré-aut + 5%. Fornecedor antigo sem painel self-service : trate como exceção formal, mantenha no master, mas mova o limite global do master para o teto necessário apenas a esses casos. Fase 6 — Desligar o master (dia 60) Com a fatura do master abaixo de 5% do volume total, você tem duas opções: Manter como contingência com limite reduzido (R$ 2.000–5.000) para emergências. Cancelar de vez se você quer eliminar superfície de ataque. A maioria das empresas escolhe a primeira por seis meses, depois cancela. Métricas pós-migração Os três indicadores que importam: Tempo de fechamento : meta < 1 dia útil (era 5–7 dias). % de cobranças sem dono : meta < 1% (era 8–14%). Tempo médio para suspender fornecedor : meta < 60s (era 22 min de telefone). E o efeito menos óbvio: quando a gestão de despesas deixa de exigir reconciliação manual, o time de finanças deixa de ser a polícia interna e volta a ser parceiro de operação. Esse é o ganho que paga o esforço. O custo do silêncio Já vi três empresas adiarem essa migração por seis meses argumentando "não temos tempo agora". Cada uma teve, no semestre seguinte, um incidente de chargeback acima de R$ 50.000 que teria sido contido em segundos se o cartão estivesse isolado. Migrar não é técnico. É contratual com você mesmo: você passa a ter o controle real do dinheiro que sai da empresa.

Ler artigo

5 de maio de 2026

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 . 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 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. Rate limit por chave de API : cada tem teto de cartões emitidos por hora. Default conservador (20/h), aumentável sob pedido. Teto global por organização : a soma de de cartões ativos não pode exceder X por padrão. agora é mandatória em . 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. PAN nunca aparece em UI por default. O painel mostra . Para ver o PAN completo, é necessário um passo extra com 2FA e log de auditoria. Mesmo o admin. Mesmo o owner. Cada API key tem escopo de leitura granular. A maioria das integrações precisa apenas listar cartões e ver + . 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 . 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.

Ler artigo

2 de maio de 2026

MCC codes explicados: como restringir cartões corporativos por ramo de atividade via API

MCC — Merchant Category Code — é um código de 4 dígitos que a Visa, Mastercard e demais bandeiras atribuem a cada estabelecimento. Existe desde 1972. E é a forma mais barata e robusta de restringir cartões corporativos por ramo de atividade na borda da autorização, antes de qualquer regra de pós-processamento. Nesse post, como exposemos MCC na nossa API de cartões pré-pago e o que mudou no v2. Por que MCC, e não regras customizadas Quando começamos, oferecíamos restrição por merchant name — você listava "openai.com" e o cartão só autorizava nele. Quebrou em três semanas: Merchant name muda : Google Cloud aparece ora como "GOOGLE CLOUD" ora como "GOOGLE CLOUD-LLC". Subdomínios diferentes : a mesma empresa cobra de 14 entidades jurídicas distintas. Internacionalização : cobranças em árabe ou cirílico. MCC resolve isso por baixo: a bandeira já classificou o merchant. Você restringe por categoria, não por string. O que cabe num MCC Os MCCs relevantes para gestão de despesas corporativas em SaaS, mídia paga e cloud: MCC Categoria --- --- 5734 Computer Software Stores (OpenAI, Anthropic, software) 5817 Digital Goods — Apps, Software, Games 7311 Advertising Services (Google Ads, Meta Ads) 7372 Computer Programming/Data Processing (AWS, GCP, Azure) 5818 Digital Goods — Large Digital Goods Merchant 4816 Computer Network/Information Services Um cartão para ferramentas de IA tipicamente cobre , , . Um cartão para mídia paga cobre só . Tente cruzar — não dá: um cartão de mídia paga não autoriza compra de SaaS, e vice-versa. A API No HubCard, MCC é um campo na emissão: A regra: se a autorização vem com MCC fora de , declined na borda . Sem processar, sem registrar tentativa de captura. O webhook dispara com . Você também pode usar para o caminho inverso (autoriza tudo exceto X). A maioria dos casos é melhor com allow-list — é menos surpresa. O que MCC não resolve MCC tem três limitações que vale conhecer: MCC pode estar errado . Em 3% dos casos, o adquirente classifica mal. Se você acha que Google Cloud é e descobre uma cobrança como , a culpa é do classificador, não sua. O sistema permite ajuste por exceção. MCC não distingue produtos do mesmo merchant . Se OpenAI cobra plataforma e cobra DALL-E pelo mesmo MCC, não dá para separar via MCC. Use por cartão e emita cartões diferentes. MCC é por merchant, não por categoria de despesa . Um anúncio no Facebook tem MCC 7311; uma assinatura premium do Facebook também. Para o sistema, a mesma transação. O efeito colateral: chargeback fica mais simples Quando você tem MCC restrito, qualquer cobrança que aparece fora do MCC esperado é automaticamente suspeita . Quase sempre é fraude. O HubCard dispara alerta antes da fatura fechar. Em quatro meses de v2, o tempo médio para detectar fraude por uso fora de MCC caiu de 6 dias (na fatura) para 8 segundos (na autorização). Isso muda o custo da fraude — não é mais "perder dinheiro e tentar disputar", é "negar antes de capturar". Como combinar com outras restrições MCC funciona melhor combinado com: : teto por ciclo (mensal, semanal). : restrição por país do merchant (Brasil-only, ou multi-país explícito). : cobrança em outra moeda que não a do cartão é bloqueada. : cartão com data de expiração explícita para uso de campanha ou agente temporário. Combinados, esses quatro atributos cobrem >95% dos casos de uso de gestão de despesas corporativas. O resto é caso raro o suficiente para tratar como exceção manual. Por que isso é diferente de regras de fraude bancária Bancos têm regras de fraude que rodam pós-autorização — eles autorizam, capturam, e depois disputam. MCC restrito no HubCard roda antes da autorização — se o cartão não permite aquele MCC, a bandeira nem chega a confirmar a transação. A diferença prática: dinheiro nunca sai. Não há disputa, não há reembolso pendente, não há fatura suja. Para gestão de despesas em escala, isso é a diferença entre "controle pós-fato" e "controle pré-fato". E é por isso que cartão corporativo na infraestrutura certa é diferente de cartão bancário antigo com app: o ponto de decisão se move para o emissor, e o emissor escuta as suas regras.

Ler artigo

28 de abril de 2026

Como a Plúria trocou o cartão black por 14 cartões corporativos dedicados — caso real de gestão de despesas

Esse é o caso da Plúria — empresa de tecnologia educacional, 80 pessoas, R$ 2,4 milhões por mês em fornecedores recorrentes, sede em São Paulo. Em 30 dias, eles migraram de um único cartão corporativo master (com nome do CFO) para 14 cartões dedicados por categoria de fornecedor. O que mudou no fechamento, na fraude, no fluxo. Caso real, números reais, autorizado a publicar. O ponto de partida (março/2026) Antes da migração, a Plúria operava assim: 1 cartão corporativo Visa Infinite Itaú, limite R$ 500.000/mês. 39 fornecedores recorrentes sendo cobrados nesse cartão (Google Workspace, OpenAI, AWS, Vercel, Stripe, Notion, Figma, Linear, etc). Fatura mensal : PDF de 84 páginas, 470 lançamentos. Tempo de fechamento mensal : 5–7 dias úteis envolvendo 3 pessoas (CFO, analista financeira, BPO contábil). Reembolsos pendentes : R$ 18.000/mês de colaboradores que pagavam com cartão próprio "porque era mais rápido". E dois incidentes recentes que motivaram a mudança: Em janeiro, fraude de R$ 12.000 em uma cobrança duplicada de um SaaS que ninguém usava mais. Demorou 23 dias para identificar; chargeback negado. Em fevereiro, cartão master clonado em uma tentativa de compra em e-commerce nos EUA. Itaú bloqueou preventivamente. Resultado: 11 fornecedores caíram simultaneamente em uma sexta à noite. Reativação na segunda. A decisão (semana 1) O CFO da Plúria avaliou três opções: Manter o master, adicionar regras de fraude : continua reativo. Não resolve o problema da fatura monolítica. Cartões corporativos por colaborador (estilo Brex/Ramp): bom para reembolso, ruim para fornecedor recorrente. Cartões dedicados por categoria de fornecedor : cobre o problema real. Optaram pela terceira via HubCard. A meta: 14 cartões, agrupando os 39 fornecedores por categoria, em 30 dias. A topologia (semana 1) Os 14 cartões emitidos: Cartão Fornecedores agrupados Limite/mês MCC --- --- --- --- ads-google Google Ads R$ 80.000 7311 ads-meta Facebook/Instagram Ads R$ 60.000 7311 ads-tiktok TikTok Ads R$ 30.000 7311 ai-tools OpenAI, Anthropic, Cohere US$ 4.000 5734, 5818 cloud-aws AWS produção US$ 3.500 7372 cloud-vercel Vercel, Netlify US$ 800 7372 productivity Google Workspace, Notion R$ 8.000 5817 design Figma, Adobe, Sketch US$ 600 5817 dev-tools Linear, GitHub, Sentry US$ 1.200 5817 payments Stripe (fees), Pagar.me R$ 40.000 6051 infra-monitoring Datadog, Grafana US$ 800 7372 comms Slack, Loom US$ 700 5817 training Cursos, certificações R$ 5.000 8299 emergencia Master de contingência R$ 5.000 (sem restrição) Cada cartão tem MCC restritivo (exceto o de emergência) e teto explícito. Soma dos tetos: equivalente a R$ 320.000 — 36% menor que o limite do master antigo, porque agora ninguém precisa de "folga geral". A migração (semanas 2–4) A migração seguiu o playbook descrito em como zerar o cartão master : ondas de 8 fornecedores por semana, sempre com sobreposição (master ativo até confirmar primeira cobrança no novo). Pontos de atrito reais: Google Ads exigiu reabertura de billing thread (1h de fricção, sem fricção técnica). AWS teve duas tentativas falhas porque o cartão tinha e a cobrança vinha como Irlanda. Resolvido habilitando IE. Stripe (fees) rejeitou cartão pré-pago no primeiro teste. Resolvido convertendo o cartão para "credit" no provisionamento. Em 4 semanas, todos os 39 fornecedores migrados. Master mantido como emergência com R$ 5k de limite. Os resultados (mês 1 pós-migração) Quatro métricas que importavam para a Plúria: Métrica Antes Depois Δ --- --- --- --- Tempo de fechamento mensal 5–7 dias 4 horas -94% Reembolsos pendentes R$ 18k/mês R$ 1.4k/mês -92% Tempo médio para suspender fornecedor 22 min 140ms -99% Cobranças sem dono identificado 14% 0.3% -98% E dois efeitos qualitativos: A controladoria parou de ser a polícia interna. Não precisava mais cobrar de cada gestor "isso é seu?". Cada lançamento já vem com que mapeia para uma categoria que mapeia para um responsável. Cada gestor ganhou autonomia. O CMO consegue ver, em tempo real, quanto a campanha de ads está consumindo. Antes via no relatório semanal. O custo O HubCard custou à Plúria US$ 200/mês (plano Startup) + tarifa transacional padrão. O ROI veio do tempo das 3 pessoas envolvidas no fechamento — estimado em 36h/mês liberadas, equivalente a R$ 7.200/mês em custo de oportunidade. Payback em 6 dias. Mas o ganho que o CFO mais cita não é financeiro: "agora eu durmo sem checar fatura" . O que não migrou Três casos ficaram fora do escopo do HubCard: Pagamentos via boleto (não é cartão). Folha (não é fornecedor). Despesas de viagem dos colaboradores (resolvido com outra ferramenta especializada em T&E). Esse último é importante: HubCard não substitui Brex/Ramp/Conta Simples no caso de cartão de funcionário com reembolso. Eles atendem mercados diferentes. Veja HubCard vs Conta Simples para a discussão completa. O efeito secundário inesperado Três meses depois da migração, a Plúria começou a usar a API de cartões pré-pago do HubCard para emitir cartões temporários para campanhas específicas. Cada campanha de growth ganha um cartão com limite exato e data de expiração. Quando a campanha termina, o cartão se autocancela. Auditoria do fim de campanha é uma query — não uma reunião. Esse padrão emergente — cartão como objeto programático escopado por projeto — é talvez o uso mais interessante do produto, e nasceu de cliente, não do roadmap. Replicar isso na sua empresa Se você tem entre 30 e 200 pessoas e gasta mais de R$ 500k/mês em fornecedores recorrentes, esse mesmo modelo cabe. O playbook está em como zerar o cartão master em 60 dias . A topologia de 8–16 cartões dedicados por categoria é o sweet spot pra essa faixa. A pergunta certa não é "vale a pena?" — é "quantos fechamentos contábeis você ainda quer passar com 470 lançamentos sem dono?".

Ler artigo

22 de abril de 2026

API de cartões pré-pago para agentes de IA: pagamento como primitiva de orquestração

Há uma classe nova de problema que está aparecendo em produção: agentes de IA que provisionam infraestrutura precisam pagar pela infraestrutura que provisionam . E hoje, isso é resolvido com gambiarras — cartão master compartilhado, limites genéricos, sem ciclo de vida. Esse post é sobre como expor uma API de cartões pré-pago para que agentes virem cliente legítimo do sistema de pagamento, com idempotência, escopo e cancelamento programado. O caso de uso Eu rodo um agente de pesquisa que provisiona instâncias H100 spot em três provedores diferentes (Lambda, RunPod, Hyperstack) dependendo de preço e disponibilidade. Antes do HubCard: Cartão pré-cadastrado em cada provedor. Limite genérico , porque o custo varia muito por job. Cancelamento manual se o agente fugia do controle. O dia em que um agente meu rodou US$ 18 num GPU spot às 4h da manhã não me incomodou. O dia em que outro agente entrou em loop e rodou US$ 4.300 em 90 minutos me convenceu que pagamento precisa ser orquestrado, não pré-aprovado . A primitiva: cartão escopado por job A ideia central: para cada job que vai consumir infra paga, o agente emite um cartão dedicado com limite igual ao orçamento da job , executa, e cancela ao final. O efeito: mesmo se o agente entrar em loop, o cartão não autoriza acima de US$ 2.000. Mesmo se o agente cancelar mal, o mata o cartão automaticamente. Mesmo se duas tentativas paralelas rodarem, garante um único cartão. MCP: agentes Claude/GPT como clientes nativos Lançamos um MCP server (Model Context Protocol) que expõe a API de cartões pré-pago como ferramenta nativa para agentes Claude, GPT e similares. O agente fala diretamente: O agente recebe um objeto cartão funcional, usa o PAN para autenticar na API de destino, e devolve via: A diferença com cartão master: o agente nunca tem acesso à credencial de pagamento da organização inteira . Ele tem acesso à credencial de pagamento da job que está executando. Se ele se comportar mal, o blast radius é o limite da job. Idempotência salva a vida Agentes têm jitter mal calibrado. Já vimos retries de 50ms entre tentativas, threads paralelas tentando a mesma operação, jobs que param e voltam horas depois pensando que precisam emitir cartão novo. A regra que aplicamos: a chave de idempotência DEVE estar no contexto da job , não no momento da chamada. Algo como — não . Mais detalhes em idempotência na API de emissão . Webhooks como sinal para o agente O agente também consome webhooks. Quando uma transação é autorizada/recusada, o evento volta para o controlador do agente: O controlador agora sabe que o agente bateu o teto e pode decidir: pausar, emitir cartão novo com mais saldo, abortar a job. Sem o webhook, o agente continuaria rodando achando que tudo está bem. O risco do "agente que emite cartão" A primeira pergunta de qualquer security review: "e se o agente decidir emitir um cartão com US$ 1 milhão e fugir com isso?" Respostas que aplicamos: Rate limit por API key : max X cartões/hora. Default conservador. Teto global por organização : a soma de de cartões ativos não pode exceder Y. Roles : a API key do agente tem permissão que aplica um teto duro de por cartão. Audit log : toda emissão tem registrando qual agente, qual job, qual run. Cancelamento por humano sempre prioritário : o owner pode cancelar qualquer cartão a qualquer hora via painel ou CLI, independente do que o agente esteja fazendo. O modelo de risco aqui é o mesmo de dar acesso AWS a um agente: você confia no escopo, não na credencial. Quem dá acesso a um agente está errando do mesmo jeito que quem dá . Padrões de uso emergentes Em 6 meses observando esse uso em produção: Cartão por experimento de fine-tune : limite = orçamento previsto + 10%, expira em 24h. Cartão por sprint de scraping : limite = teto da semana, MCC restrito a / . Cartão por usuário final (quando o agente é multi-tenant): cada usuário do produto tem seu cartão, billing volta limpo para reconciliar. Cartão por billing cycle : ferramentas que cobram mensal recebem cartão com , expira no fim do ciclo, renovado por orquestrador. O padrão comum: cartão como objeto de orquestração , não como recurso compartilhado. Por que isso muda a economia da IA O argumento de quem opera agentes em produção: o custo dominante não é o LLM — é a infra que o agente provisiona. GPU spot a US$ 2/h, API de tools a US$ 0.01/call, storage S3 que ninguém limpa. Esses custos só ficam previsíveis com observabilidade financeira em tempo real . Cartão dedicado por escopo dá essa observabilidade de graça: cada transação é taggeada, cada limite é hard cap, cada cancelamento é instantâneo. A planilha de custo do agente vira uma view SQL — não uma fatura de fim de mês. E quando você combina isso com gestão de despesas já estruturada por categoria, a empresa inteira ganha uma camada nova de previsibilidade orçamentária que antes não existia para workloads agênticos. O dia em que pagamento vira primitiva de SDK A previsão razoável: nos próximos 12 meses, frameworks como LangChain, AutoGen, LangGraph vão tratar pagamento como primitiva de primeira classe. será tão natural quanto . E quando isso acontecer, a infraestrutura que vencer é a que tiver API de cartões pré-pago programática, com idempotência e escopo, exposta por MCP . Não é coincidência que a gente esteja descrevendo o HubCard.

Ler artigo

18 de abril de 2026

Auditoria de fornecedores em 15 minutos: três queries para gestão de despesas corporativas

90% das cobranças recorrentes em gestão de despesas corporativas nunca são revisadas depois do cadastro inicial. SaaS que ninguém usa, fornecedores que duplicaram cobrança, contratos que renovaram automaticamente com aumento de 30%. Essa massa silenciosa vira gordura no fluxo de caixa. Esse post é o ritual que rodo toda sexta — três queries que respondem três perguntas e levam 15 minutos para acionar a próxima semana. Setup: o que assumo Você tem cartões dedicados por fornecedor (modelo descrito em como zerar o cartão master ) e webhooks de transação caindo num warehouse (BigQuery, Postgres, Snowflake). A tabela base: Se você ainda não tem essa estrutura, qualquer ferramenta de gestão de despesas com webhooks tipados resolve. O HubCard manda exatamente isso. Query 1 — SaaS órfão Pergunta: existem cartões ativos que não tiveram cobrança nos últimos 90 dias? Resultado típico: 4–7 cartões. Cada um é um SaaS que ou foi descontinuado, ou foi substituído, ou está em trial expirado mas alguém esqueceu de cancelar. Ação: descobrir o dono, confirmar se ainda é necessário, cancelar via se não for. Economia média que vejo nessa query toda sexta: R$ 800–2.400/mês. Query 2 — Anomalia de teto Pergunta: algum fornecedor cobrou 2x o ticket médio do trimestre nessa semana? Resultado típico: 1–3 fornecedores. Pode ser legítimo (aumento de uso planejado, campanha extra) ou problemático (script em loop, cobrança duplicada, renovação anual disfarçada de cobrança mensal). A ação importante: investigue antes de fechar o mês , não depois. Cobrança esquisita em fatura fechada é disputa de chargeback. Cobrança esquisita em autorização recente ainda é reversível por contato direto com o fornecedor. Query 3 — Vendor lock-in Pergunta: qual o % do gasto total concentrado nos 3 maiores fornecedores? Quando os 3 maiores fornecedores representam >55% do gasto mensal, você tem risco de concentração . Sair de um deles vai ser caro e demorado. Reduzir a dependência hoje vale mais que negociar desconto. Essa query não muda decisão semanalmente, mas trimestralmente. Inclua no relatório de fechamento. O ganho do ritual Toda sexta, 15 minutos: 5 minutos rodando as três queries. 5 minutos abrindo o painel HubCard para validar. 5 minutos no Slack alinhando ações (cancela X, investiga Y, monitora Z). Esse ritual elimina 80% do waste recorrente que aparece em fatura fechada. O resto (20%) vira insight estratégico para renegociação. Por que MCC ajuda nessas queries Quando cada cartão carrega MCC restrito (ver MCC codes explicado ), a query 2 fica mais poderosa. Você pode segmentar anomalia por categoria: "ads cresceu 40% essa semana" tem causa diferente de "cloud cresceu 40% essa semana". A primeira é decisão de marketing; a segunda é alerta de billing leak. O ritual escalado Equipes pequenas (até 30 pessoas) rodam manual toda sexta. Equipes médias (30–150) automatizam as queries num dashboard semanal. Equipes grandes (150+) ligam isso a um workflow que abre tickets automaticamente quando os thresholds são ultrapassados. A maturidade não está em automatizar — está em ter o pulso semanal. Quem audita fornecedor uma vez por trimestre paga 4 trimestres de gordura. Por que isso só funciona com cartão dedicado Note que todas as três queries dependem de mapeado para . Se você ainda opera com cartão master único, nenhuma dessas queries funciona — você só tem a fatura PDF para cruzar manualmente. É a diferença entre dados de autorização estruturados e PDF parseado . Esse é, no fim, o argumento maior pra ter um cartão corporativo por fornecedor: não é só sobre fraude. É sobre transformar dados de pagamento em dados de produto .

Ler artigo

14 de abril de 2026

Webhooks tipados na API de cartões: o fim do JSON livre

Webhooks são o canal silencioso por onde a infraestrutura conta o que aconteceu. Quando funcionam, ninguém percebe. Quando falham — ou pior, quando o esquema muda sem aviso — viram a categoria 1 de tickets de suporte. Esse post conta como migramos os webhooks da nossa API de cartões corporativos de JSON livre para eventos esquema-fortes, e tiramos 80% dos tickets de integração. O problema original A v1 da nossa API enviava webhooks assim: Simples, certo? Errado. Em seis meses: virou às vezes string ("58.40") em vez de int (5840). virou em alguns casos, em outros, em outros. às vezes vinha como , às vezes como objeto inteiro. Sem único — retries do nosso lado faziam o webhook chegar 3 vezes sem o cliente conseguir deduplicar. Cada cliente integrava interpretando o JSON do jeito dele. Cada mudança nossa (mesmo backward compat) quebrava integração de alguém. A v2 — eventos esquema-fortes Reescrevemos com 4 princípios: Cada tipo de evento tem schema próprio versionado. único, derivado dele. Versão no envelope, payload separado. Documentação como contrato OpenAPI publicado. A nova forma: Não mudou o conteúdo essencial. Mudou a estrutura. A taxonomia dos eventos Aplicamos um padrão . Os 14 eventos principais: Evento Disparo --- --- Cartão emitido com sucesso Cartão saiu de pending para active Atributos do cartão alterados Cartão pausado Cartão retomado Cartão cancelado Cartão atingiu Transação autorizada Transação capturada Transação recusada Transação revertida Chargeback aberto Tentativa acima do Tentativa em MCC não permitido Cada evento tem schema publicado em — versionado, com changelog. Idempotência no cliente, garantida é único e estável. O cliente armazena recebido e ignora se já viu. Nossa documentação tem snippet exato para Node, Python, Go e Ruby. Antes da v2, idempotência ficava "como você quiser". Agora é regra obrigatória. Assinatura HMAC com timestamp Cada webhook leva header: Validação no cliente: O (timestamp) evita replay attacks. A janela de 5 minutos cobre clock skew sem deixar buraco. Retries com backoff exponencial Quando o cliente não responde 2xx em 10s, retentamos: Tentativa 2: 30s depois Tentativa 3: 2 min depois Tentativa 4: 10 min depois Tentativa 5: 1 hora depois Tentativa 6: 4 horas depois Tentativa 7: 12 horas depois (última) Total de janela: 17 horas. Depois disso o webhook vira "permanently failed" no log e o admin recebe alerta. Eventos críticos (tx.captured, card.cancelled) também ficam acessíveis via por 30 dias. A migração Não fizemos breaking change. Mantivemos a v1 ativa por 6 meses, com header de deprecation: Clientes podiam optar pelo formato novo via header no endpoint registrado. Em 4 meses, 87% migrou voluntariamente. Os 13% restantes receberam comunicação direta antes do sunset. O resultado Em métricas operacionais, comparando o trimestre antes vs depois: Tickets de suporte sobre webhook : -82%. Tempo médio de integração de webhook (cliente novo) : de 6h para 90 min. Eventos perdidos por erro de schema : zerou. PRs de upgrade em SDKs externos quando lançamos novo evento : 8 PRs em 2 dias (vs nenhum antes). O ganho menos óbvio: clientes começaram a tratar webhook como source of truth . Antes, muitos clientes faziam e depois para confirmar — desconfiavam do webhook. Agora, com schema garantido + assinatura + idempotência, o webhook chegou ao status de evento confiável. Por que isso importa para gestão de despesas em tempo real Gestão de despesas em tempo real só funciona se cada chegar no seu ERP em segundos, com schema garantido. Sem isso, fechamento volta a ser exercício mensal de cruzar PDF. Com isso, a conciliação roda à medida que as transações acontecem. O fim do JSON livre não é estética. É a única forma de fazer integração financeira em escala.

Ler artigo

10 de abril de 2026

De zero a 12 mil cartões corporativos emitidos: decisões que sobreviveram dois anos

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. . Quebrou quando começaram a ter chargebacks (precisa de relação 1:N). v2: transação virou hierarquia: . Funciona bem, mas era denso pra consumir. v3: modelo "lifecycle stream" — toda transação é uma sequência de eventos imutáveis com . 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.

Ler artigo
FAQ

Cartões corporativos, API e gestão de despesas: perguntas frequentes.

HubCard é uma plataforma de cartões corporativos virtuais e pré-pagos com API de emissão e gestão de despesas em tempo real. Você cria um cartão dedicado por fornecedor (Google Ads, OpenAI, AWS, etc.) e controla todo o ciclo de vida — criar, ajustar limite, pausar, cancelar — via API REST ou painel web.

Comece com um cartão.

Sem mensalidade no plano dev. Setup em menos de 5 minutos. Cancele com um POST.

Criar contaFalar com vendas
Cartões corporativos e gestão de despesas com API · HubCard