Sell more credits with Stripe

Stripe doesn't know what your app did

Stripe can charge a card, run a subscription, and bill against a usage number you send it. What it can't do is look inside your application and know that one customer's "request" triggered one model call and another's triggered nine, or that a reasoning model costs more per token than a small one.

That's not a gap in Stripe. It's not Stripe's job. Something has to watch the application and turn what actually happened into a number Stripe can bill against — and for an AI product, a raw request count usually isn't that number.

You define what counts as usage

Vibe doesn't pick a metric for you. It meters whatever you already defined a credit to be — tokens, model calls, seats, image generations, anything a usage.chat(), withdraw(), or route-metering call reports. That's the same unit covered in why AI apps need credits: one engine, your choice of what it counts.

Stripe then bills on whatever number you report under that unit. The price per credit, and whether a more expensive model costs more credits, is your pricing decision — Vibe measures consumption, it doesn't set what you charge for it.

Connect Vibe to Stripe

Add your Stripe API key under Integrations in the Console. Then, on a policy's tier, turn on the Stripe effect:

1. Stripe Customer ID — the Stripe customer that corresponds to this call's identity, the same field from your first call. It's what ties a report back to one customer in your Stripe account.
2. Meter to report to — the Stripe Billing meter event name that receives the report, such as api_tokens or requests_per_month.

From then on, when that tier fires, Vibe reports the call's consumption amount to that meter, under that customer. Your app never talks to Stripe for this — Vibe does.

Turn usage into revenue

• Free: 1,000 credits a month.
• Pro: 10,000 credits a month.
• Out of credits? Buy 5,000 more.

That's a whole pricing page, and every AI product ends up here. The hard part was never the pricing — it's making the balance mean the same thing in three places: what the customer sees, what the app enforces, and what Stripe charges. Reporting the real, settled amount instead of an estimate is what keeps those three in sync.

customer uses your app → Vibe meters consumption → balance hits zero → calls are blocked
      ↑                                                                       │
      └── credits increase ← Stripe confirms payment ← customer buys a pack ←─┘

The block isn't a failure. It's the moment they're most likely to buy.

Optional: sell prepaid credits

Metering handles the usage side. The other direction, adding credits when someone pays, is a secondary case: a webhook you write. Stripe confirms the charge, and you raise the balance with credit():

const endpointSecret = process.env.STRIPE_WEBHOOK_SECRET;

app.post('/webhooks/stripe', async (req, res) => {
  const event = stripe.webhooks.constructEvent(
    req.body, req.headers['stripe-signature'], endpointSecret
  );

  if (event.type === 'checkout.session.completed') {
    const session = event.data.object;
    await usage.credit({
      identity: session.client_reference_id, // the customer you passed at checkout
      amount: 5000, // the pack this customer bought
      idempotencyKey: session.id, // Stripe's id, safe to reuse on webhook retries
      reason: 'stripe:credit-pack-5000',
    });
  }
  res.json({ received: true });
});

session.id as the idempotency key matters, because Stripe retries webhooks and a retry shouldn't double-grant the pack.

One thing worth knowing before you point real payments at this: crediting a balance up is newer and less exercised than the metering path above, which only ever spends down. Test it against your own account first.

FAQ