I built a Stripe-native marketplace where AI agents pay for APIs automatically

A few weeks ago, Stripe shipped their Agent Toolkit — a way for AI agents to hold a payment method and spend money programmatically. I read the announcement and immediately thought: there's nowhere for agents to actually spend this money.

So I built one. This is the story of how, plus the technical decisions and dead ends along the way.

The problem

AI agents increasingly need to call external services — scrape a page, validate a phone number, generate a PDF. Today, that means one of three things for the developer wiring it up:

• Hardcode an API key for every service the agent might need
• Build a custom billing integration per provider
• Maintain a growing pile of subscriptions for services the agent calls a handful of times

None of this is agent-native. An agent that discovers it needs a capability mid-task has no standard way to find a provider and pay for exactly what it uses.

MCP (Model Context Protocol) solves half of this — it standardizes how agents discover and call tools. Stripe Agent Toolkit solves the other half — it lets an agent actually pay for something. Nobody had connected the two into an actual marketplace. That's run.pay.

How it works

Two sides, one backend:

Sellers publish any API as a service with a price per call. A scraper, a validator, anything that returns JSON.

Agents connect once via an MCP endpoint and discover the entire catalog automatically:

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

From there, calling a service and paying for it is one request:

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

Stripe charges the agent's attached card, the request is forwarded to the seller's endpoint, the result comes back. The seller gets paid via Stripe Connect. Nobody touches a dashboard.

The architecture

Pretty boring on purpose — boring is reliable:

• Backend: Node.js + Express on Railway
• Database: PostgreSQL (also Railway)
• Payments: Stripe Connect for payouts, a custom wrapper around the Payment Intents API for per-call charging
• Discovery: a standard MCP server exposing list_services and call_service as tools
• Email: Resend, for vendor onboarding and sale notifications

The interesting part isn't any single piece — it's how the payment flow has to behave for an autonomous caller.

What broke, and why

Stripe's minimum charge amount

My first instinct was to price services the way Twilio or AbstractAPI do — fractions of a cent per call. That's the right end-user price, but Stripe enforces a minimum charge (~$0.50 depending on currency), and on top of that takes a flat fee per transaction. Charging $0.01 per call means losing money on Stripe's fee alone.

The fix for v1 was pragmatic: price services at $0.60+ so a single Stripe charge clears the minimum and the fee stays a small percentage. It's not the long-term answer — a credit-based system (buy $10 of credits in one transaction, debit fractions of a cent per call) is the real fix, and it's next on the roadmap. But it would have delayed launch by weeks, and getting a working pay-per-call loop in front of people mattered more than getting the unit economics perfect on day one.

Auto-refunding failed calls

If a seller's endpoint times out or returns a 500, the agent has already been charged. There's no acceptable version of "sorry, no refund" when the thing that failed wasn't the agent's fault. So /api/call/:id wraps the seller request in a try/catch that triggers an automatic Stripe refund on any non-2xx response or timeout, before the error even reaches the agent. The agent sees a clean failure with refunded: true instead of a silent charge for nothing.

Designing the MCP surface for a marketplace, not a single tool

Most MCP servers I looked at expose a fixed set of tools — one server, one capability. A marketplace needs a different shape: one stable tool (call_service) that takes a dynamic service ID, plus a discovery tool (list_services) that returns whatever the catalog currently contains. The catalog changes as vendors join; the MCP surface itself shouldn't need to change. That distinction took a couple of false starts to get right — my first version tried to generate a new MCP tool per service, which works until you have 50 services and an agent's context window is full of tool definitions it'll never call.

Where it's at

Six services live right now — phone validation, web scraping, PDF generation, screenshot capture, plus batch variants of a couple of them. One real Stripe transaction has cleared the full loop: charge, call, refund-on-failure logic untested-in-anger (good), result returned to the agent in under two seconds.

The harder problem now isn't technical — it's the standard cold-start problem for any marketplace. Sellers won't list services with zero agents calling them; agents have no reason to integrate a marketplace with zero services. I've spent the last week doing the unglamorous work: building services myself to seed the catalog, manually reaching out to MCP server maintainers who already have something worth monetizing, getting indexed on Smithery and the awesome-mcp-servers list.

What I'd tell someone building something similar

Price for Stripe's economics first, your ideal economics second. I lost a day discovering the minimum-charge issue in production instead of reading Stripe's docs more carefully upfront.

Auto-refund anything that wasn't the caller's fault. An autonomous agent can't dispute a charge. If your system charges before it confirms success, it needs to un-charge automatically when that confirmation never arrives.

Design the discovery layer to scale independently of the catalog. If your MCP surface has to change every time someone adds a service, you've built a single-tenant integration, not a marketplace.

run.pay is live at getrunpay.com. The docs have copy-pasteable curl examples for every service, and there's a sandbox mode if you want to test the flow without a real charge. The MCP server source and a Python SDK are both on GitHub.

If you maintain an MCP server with something worth monetizing, or you're building an agent that needs to call external services, I'd genuinely like to hear what would make a marketplace like this useful to you.