{"slug": "i-built-a-stripe-native-marketplace-where-ai-agents-pay-for-apis-automatically", "title": "I built a Stripe-native marketplace where AI agents pay for APIs automatically", "summary": "A developer built RunPay, a Stripe-native marketplace that lets AI agents automatically discover and pay for third-party APIs using the Model Context Protocol (MCP) and Stripe's Agent Toolkit. The platform handles payment routing, automatic refunds on failures, and dynamic service discovery, with six services currently available including phone validation and web scraping.", "body_md": "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.*\n\nSo I built one. This is the story of how, plus the technical decisions and dead ends along the way.\n\nAI 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:\n\nNone 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.\n\n**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](https://getrunpay.com).\n\nTwo sides, one backend:\n\n**Sellers** publish any API as a service with a price per call. A scraper, a validator, anything that returns JSON.\n\n**Agents** connect once via an MCP endpoint and discover the entire catalog automatically:\n\n```\n{\n  \"mcpServers\": {\n    \"runpay\": {\n      \"url\": \"https://runpay-backend-visibility-production.up.railway.app/mcp\"\n    }\n  }\n}\n```\n\nFrom there, calling a service and paying for it is one request:\n\n```\ncurl -X POST https://runpay-backend-visibility-production.up.railway.app/api/call/SERVICE_ID \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"agent_id\":\"my-agent\",\"payload\":{\"phone\":\"+33612345678\"}}'\n```\n\nStripe 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.\n\nPretty boring on purpose — boring is reliable:\n\n`list_services`\n\nand `call_service`\n\nas toolsThe interesting part isn't any single piece — it's how the payment flow has to behave for an *autonomous* caller.\n\nMy 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.\n\nThe 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.\n\nIf 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`\n\nwraps 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`\n\ninstead of a silent charge for nothing.\n\nMost 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`\n\n) that takes a dynamic service ID, plus a discovery tool (`list_services`\n\n) 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.\n\nSix 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.\n\nThe 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](https://glama.ai/mcp/servers) and the [awesome-mcp-servers](https://github.com/punkpeye/awesome-mcp-servers) list.\n\n**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.\n\n**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.\n\n**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.\n\nrun.pay is live at [getrunpay.com](https://getrunpay.com). The [docs](https://getrunpay.com/docs.html) 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](https://github.com/PalabreX/runpay-mcp) and a Python SDK are both on GitHub.\n\nIf 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.", "url": "https://wpnews.pro/news/i-built-a-stripe-native-marketplace-where-ai-agents-pay-for-apis-automatically", "canonical_source": "https://dev.to/palabrex/i-built-a-stripe-native-marketplace-where-ai-agents-pay-for-apis-automatically-8gf", "published_at": "2026-06-24 00:41:34+00:00", "updated_at": "2026-06-24 01:15:07.453716+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools", "ai-infrastructure", "ai-products"], "entities": ["Stripe", "RunPay", "Model Context Protocol", "Stripe Agent Toolkit", "Stripe Connect", "Twilio", "AbstractAPI"], "alternates": {"html": "https://wpnews.pro/news/i-built-a-stripe-native-marketplace-where-ai-agents-pay-for-apis-automatically", "markdown": "https://wpnews.pro/news/i-built-a-stripe-native-marketplace-where-ai-agents-pay-for-apis-automatically.md", "text": "https://wpnews.pro/news/i-built-a-stripe-native-marketplace-where-ai-agents-pay-for-apis-automatically.txt", "jsonld": "https://wpnews.pro/news/i-built-a-stripe-native-marketplace-where-ai-agents-pay-for-apis-automatically.jsonld"}}