Eu construí um marketplace nativo do Stripe onde agentes de IA pagam por APIs automaticamente

Há algumas semanas, o Stripe lançou seu Agent Toolkit — uma maneira para agentes de IA manterem um método de pagamento e gastarem dinheiro programaticamente. Eu li o anúncio e imediatamente pensei: não há lugar para os agentes realmente gastarem esse dinheiro.

Então eu construí um. Esta é a história de como, além das decisões técnicas e becos sem saída ao longo do caminho.

O problema

Agentes de IA precisam cada vez mais chamar serviços externos — raspar uma página, validar um número de telefone, gerar um PDF. Hoje, isso significa uma das três coisas para o desenvolvedor que está conectando:

• Codificar uma chave de API para cada serviço que o agente possa precisar
• Construir uma integração de cobrança personalizada por provedor
• Manter uma pilha crescente de assinaturas para serviços que o agente chama algumas vezes

Nenhuma dessas opções é nativa para agentes. Um agente que descobre que precisa de uma capacidade no meio da tarefa não tem uma maneira padrão de encontrar um provedor e pagar exatamente pelo que usa.

MCP (Model Context Protocol) resolve metade disso — padroniza como os agentes descobrem e chamam ferramentas. O Stripe Agent Toolkit resolve a outra metade — permite que um agente realmente pague por algo. Ninguém havia conectado os dois em um marketplace real. Isso é run.pay.

Como funciona

Duas partes, um backend:

Vendedores publicam qualquer API como um serviço com um preço por chamada. Um raspador, um validador, qualquer coisa que retorne JSON.

Agentes se conectam uma vez via um endpoint MCP e descobrem todo o catálogo automaticamente:

{
  "mcpServers": {
    "runpay": {
      "url": "https://runpay-backend-visibility-production.up.railway.app/mcp"
    }
  }
}

A partir daí, chamar um serviço e pagar por ele é uma única requisição:

curl -X POST https://runpay-backend-visibility-production.up.railway.app/api/call/SERVICE_ID \
  -H "Content-Type: application/json" \
  -d '{"agent_id":"meu-agente","payload":{"phone":"+33612345678"}}'

O Stripe cobra o cartão vinculado do agente, a requisição é encaminhada para o endpoint do vendedor, e o resultado retorna. O vendedor é pago via Stripe Connect. Ninguém toca em um painel.

A arquitetura

Bastante entediante de propósito — entediante é confiável:

• Backend: Node.js + Express no Railway
• Banco de dados: PostgreSQL (também Railway)
• Pagamentos: Stripe Connect para pagamentos, um wrapper personalizado em torno da API de Payment Intents para cobrança por chamada
• Descoberta: um servidor MCP padrão expondo list_services e call_service como ferramentas
• Email: Resend, para integração de vendedores e notificações de vendas

A parte interessante não é nenhum único componente — é como o fluxo de pagamento precisa se comportar para um chamador autônomo.

O que quebrou, e por quê

O valor mínimo de cobrança do Stripe

Meu primeiro instinto foi precificar serviços da maneira que o Twilio ou AbstractAPI fazem — frações de centavo por chamada. Esse é o preço certo para o usuário final, mas o Stripe impõe uma cobrança mínima (~$0.50 dependendo da moeda), e além disso, cobra uma taxa fixa por transação. Cobrar $0.01 por chamada significa perder dinheiro apenas com a taxa do Stripe.

A solução para a v1 foi pragmática: precificar serviços em $0.60+ para que uma única cobrança do Stripe ultrapasse o mínimo e a taxa permaneça uma pequena porcentagem. Não é a resposta a longo prazo — um sistema baseado em créditos (comprar $10 de créditos em uma transação, debitar frações de centavo por chamada) é a verdadeira solução, e está próxima no roadmap. Mas isso teria atrasado o lançamento por semanas, e conseguir um loop de pagamento por chamada funcionando na frente das pessoas importava mais do que acertar a economia unitária no primeiro dia.

Reembolso automático de chamadas falhadas

Se o endpoint de um vendedor expirar ou retornar um 500, o agente já foi cobrado. Não há uma versão aceitável de "desculpe, sem reembolso" quando a falha não foi culpa do agente. Portanto, /api/call/:id envolve a requisição do vendedor em um try/catch que aciona um reembolso automático do Stripe em qualquer resposta não-2xx ou timeout, antes que o erro chegue ao agente. O agente vê uma falha limpa com refunded: true em vez de uma cobrança silenciosa por nada.

Projetando a superfície MCP para um marketplace, não uma única ferramenta

A maioria dos servidores MCP que eu examinei expõem um conjunto fixo de ferramentas — um servidor, uma capacidade. Um marketplace precisa de uma forma diferente: uma ferramenta estável (call_service) que aceita um ID de serviço dinâmico, além de uma ferramenta de descoberta (list_services) que retorna o que o catálogo atualmente contém. O catálogo muda à medida que os vendedores se juntam; a própria superfície MCP não deve precisar mudar. Essa distinção levou algumas tentativas frustradas para acertar — minha primeira versão tentou gerar uma nova ferramenta MCP por serviço, o que funciona até você ter 50 serviços e a janela de contexto de um agente está cheia de definições de ferramentas que ele nunca chamará.

Onde está

Seis serviços estão ativos agora — validação de telefone, raspagem da web, geração de PDF, captura de tela, além de variantes em lote de alguns deles. Uma transação real do Stripe completou o ciclo completo: cobrança, chamada, lógica de reembolso em falhas não testadas na prática (bom), resultado retornado ao agente em menos de dois segundos.

O problema mais difícil agora não é técnico — é o padrão de problema de início frio para qualquer marketplace. Vendedores não listarão serviços com zero agentes chamando-os; agentes não têm razão para integrar um marketplace com zero serviços. Passei a última semana fazendo o trabalho pouco glamoroso: construindo serviços eu mesmo para semear o catálogo, entrando em contato manualmente com mantenedores de servidores MCP que já têm algo que vale a pena monetizar, sendo indexado em Smithery e na lista awesome-mcp-servers.

O que eu diria a alguém construindo algo semelhante

Precifique para a economia do Stripe primeiro, sua economia ideal em segundo. Eu perdi um dia descobrindo o problema do valor mínimo de cobrança em produção em vez de ler os documentos do Stripe com mais cuidado no início.

Reembolse automaticamente qualquer coisa que não foi culpa do chamador. Um agente autônomo não pode contestar uma cobrança. Se seu sistema cobra antes de confirmar o sucesso, ele precisa des-cobrar automaticamente quando essa confirmação nunca chega.

Projete a camada de descoberta para escalar independentemente do catálogo. Se a sua superfície MCP precisa mudar toda vez que alguém adiciona um serviço, você construiu uma integração de inquilino único, não um marketplace.

run.pay está ao vivo em getrunpay.com.