MCP-Billing

OAuth 2.1 + usage-based Stripe billing for MCP servers

API

SaaS

Developer Tools

GitHub

Visit WebsiteSee on Product HuntNpm ⧉Github ⧉

Hey @marc_gil1 — the webhook silent-failure story in your launch note is a great flag for exactly the kind of bug that doesn't announce itself — appreciated the honesty there.

One thing I didn't see covered in the OAuth thread: how does this handle machine-only auth, where the "user" consenting is an agent acting on someone else's behalf with no human at the keyboard to click Allow? Client-credential / device-code shaped flows with no human in the loop are the case that keeps coming up as agents start initiating their own transactions.

Also curious about the runtime — the stack leans on Postgres + Redis, is this deployable on an edge runtime (Workers, etc.), or does it assume a traditional always-on Node server?

The decision to keep the metering core open source while charging for the rest is genuinely smart, basically lets people trust the math before they trust the product. Love that there's no revenue share either, feels refreshing.

The decision to ship the metering core as free open source while keeping the full stack paid is a really thoughtful move, it lets developers build trust with the hardest part before committing to the boilerplate.

The webhook story is the right thing to lead with. I shipped a Stripe integration this month where everything was green in test mode and the first real card 400'd on a currency param test mode never asked for - and separately found receipts failing silently because the send helper never throws and a try/catch was eating the reason. Money bugs don't announce themselves; you find them by walking the path with a real card and reading the logs like a skeptic.

Which is why I'd second Grace's checklist ask, and add one architectural vote: treat metering as a ledger, not a counter. Reserve before the metered call, settle exactly once keyed on the attempt, refund on failure - Gal's retry-dedupe question mostly dissolves when the settle is idempotent by construction. The counter tells you what happened; the ledger makes sure it only happened once.

Publishing mcp-metering free and inspectable is a genuinely good trust move. €79 for the edge cases someone already paid to discover is fair.

The zero-downtime API key rotation is the detail that would save the most pain in practice — keys usually get replaced when something breaks, not during planned maintenance, and any rotation downtime cascades into support tickets. The question I would ask before building on this: does the usage-based metering support different pricing tiers per API key, or is billing flat across all keys on the account? That matters when you want to give different API keys to different customer tiers without running separate instances.

The OAuth 2.1 + PKCE half is the part I'd have paid for. We ship an MCP server next to a local CLI binary, and the awkward case was authenticating a client that has no redirect target of its own — we ended up binding a loopback listener on 127.0.0.1 and handing back a http://localhost:<port>/ca... redirect URI. That took longer to get right than the billing did.

Does the boilerplate cover that non-browser client path (loopback or device code), or is it aimed at hosted MCP servers where a normal redirect URI already exists? Also curious what led you to one-time €79 with no revenue share when the metering core is already open source — that's a deliberate-looking choice.

The Stripe webhook example is a strong trust signal. For MCP servers, billing is one of those areas where AI-generated code can look complete while the edge cases quietly decide whether the product is usable.

One onboarding thing I’d want as a small builder: a checklist or test mode that proves the money path end to end — auth, metering, retry behavior, failed payments, and key rotation — before I connect a real server.

the webhook silent-failure story in your maker comment is the one that would actually keep me up at night, not the OAuth stuff everyone's asking about. on the usage-based billing side specifically: if Stripe retries a webhook (which it does on any non-2xx, including your own transient DB hiccups), does mcp-metering dedupe on the event id before incrementing usage, or is double-counting on retry something the integrator has to guard against themselves? that's the kind of bug that doesn't throw an error, it just quietly overcharges someone until they notice their invoice looks wrong

The OAuth half of this is the part I would pay for before the billing half. I connect MCP servers to my Claude setup as a user most weeks, and the pattern from that side is blunt, a server whose auth works on the first try gets used the same day, and one that fails sits unauthenticated for weeks. I have one in that exact state right now. Does your OAuth 2.1 flow cover the interactive consent dance the desktop AI clients run, or is it aimed at headless API consumers with keys?