Claude API Subscription Billing: Stripe Integration

Billing customers for Claude API usage with Stripe

If you're building a product on top of Claude and need to charge your own customers for it, the core problem isn't "how do I call Claude" — it's "how do I turn tokens consumed into a bill that Stripe can collect." That means combining three things: a way to meter usage per customer, a Stripe pricing model that matches your cost structure, and a reliable pipe that reports usage into Stripe on a schedule Stripe understands.

This guide walks through the two common billing models (flat subscription and metered/usage-based), how to wire Claude usage data into Stripe's Billing APIs, and where a layer like SubToAPI removes most of the plumbing so you're not building a metering pipeline from scratch.

Why you can't just resell Claude access directly

Anthropic's API bills you, the developer, by token. Your customers don't want to think in tokens — they want a seat price, a monthly plan, or a "pay for what you use" model that feels predictable. To get from raw token usage to a Stripe invoice, you need:

1. A way to attribute usage to a customer — ideally per API key, per workspace, or per account ID.
2. A pricing decision — flat fee, metered, or hybrid (base fee + overage).
3. A reporting mechanism that pushes usage into Stripe at the right cadence (real-time, daily, or at invoice time).

Skipping step 1 is the most common mistake. If every customer's requests hit the same Claude API key, you have no way to separate who used what. This is also why many teams layer a service like SubToAPI in front of raw Claude access — it issues distinct sub_live_... keys per customer or per team seat, and every response includes usage metadata (tokens in/out) you can log and report without building your own token-counting middleware. See the quickstart for how key issuance works.

Two billing models that actually work

Flat subscription (Solo / Team / Scale style)

This is the simplest to implement and the easiest for customers to understand. You pick tiers, each with a monthly price and usage ceiling, and bill on a fixed schedule with Stripe Subscriptions.

curl https://api.stripe.com/v1/subscriptions \
  -u sk_live_...: \
  -d customer=cus_123 \
  -d "items[0][price]=price_team_monthly"

Pair this with a soft usage cap enforced in your app (reject or throttle requests past the limit, or auto-upgrade). This model works well if your customers' usage is fairly predictable — think internal tools, not high-variance consumer apps.

Metered / usage-based billing

For customers whose Claude usage swings wildly, metered billing is fairer and easier to sell ("pay for what you use" beats "guess your tier"). Stripe's Billing Meters API lets you report usage events and have Stripe aggregate them into an invoice line item.

curl https://api.stripe.com/v1/billing/meter_events \
  -u sk_live_...: \
  -d event_name=claude_tokens \
  -d "payload[value]=4820" \
  -d "payload[stripe_customer_id]=cus_123"

You'd call this after each Claude request (or batched, e.g. every 5 minutes) with the token count for that customer. The key engineering decision is where that token count comes from — either you compute it yourself from the raw Claude response, or you read it from usage metadata already exposed by your API layer.

Hybrid: base fee + overage

Most SaaS products land here eventually: a flat monthly fee that includes an allowance, plus metered overage beyond it. In Stripe terms, this is a subscription with one flat-rate price and one metered price on the same subscription item structure.

Wiring usage into Stripe without building a metering service

If you're calling Claude directly, you own the entire pipeline: counting tokens from each response, attributing them to a customer, storing them, and batching the Stripe report. That's a reasonable amount of infrastructure for something that isn't your core product.

If you're already routing requests through SubToAPI, usage metadata (input tokens, output tokens, model used) is returned with every response and tied to the specific API key that made the call:

const res = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4",
    max_tokens: 1024,
    messages: [{ role: "user", content: "Summarize this ticket." }]
  })
});

const data = await res.json();
// data.usage.input_tokens, data.usage.output_tokens

Since each customer or team seat can have its own key, you can map key -> customer_id once in your database and then forward data.usage straight into your Stripe meter event on every call, or batch it nightly. No separate token-counting library, no need to reconcile Anthropic's raw billing against your own logs — the usage numbers you report to Stripe are the same ones you'd see in your dashboard. Full request/response shapes are in the Messages docs, and streaming responses (which still return usage once the stream closes) are covered in streaming.

Handling team seats and multi-tenant billing

If your product has teams, not just individual users, seat-based billing adds another wrinkle: usage should roll up per organization, not per individual key, even though each team member might have their own key for isolation and rate limiting. The practical pattern:

• One Stripe customer per organization.
• One or more SubToAPI keys per organization (per seat, or per environment — staging vs production).
• A nightly job that sums usage across all keys tagged to that organization and reports a single meter event to Stripe.

This keeps your billing logic decoupled from how granular your API key issuance is, which matters once you need per-seat rate limits without per-seat invoices. If you're issuing keys per teammate, pricing plans like Team and Scale already bill per seat, which you can either pass through to your own customers or absorb into a flat tier.

Reconciliation and failure handling

Two things will bite you if you skip them:

• Idempotency — Stripe meter events should include an idempotency key tied to the usage record, so retries after a network failure don't double-bill.
• Grace periods — if a Stripe payment fails, don't hard-cut Claude access mid-conversation. Queue a soft warning, then disable the key after a grace window.

Questions

Do I need a separate billing system if I use Stripe metered billing? No. Stripe Billing Meters handles aggregation and invoicing; you only need to report usage events with a customer ID and a value. The work is in getting accurate per-customer usage numbers to report.

Can I bill customers a markup on top of raw Claude token costs? Yes — this is standard. Decide your margin, set your Stripe price per unit (or per 1K tokens) above your actual cost, and report the same usage units you're being billed on upstream.

What's the fastest way to get per-customer usage without building my own metering layer? Issue separate API keys per customer through a layer like SubToAPI, read the usage metadata returned on each response, and map it to Stripe customers. Start with the quickstart or try it via signup.