Usage-based pricing aligns cost with value. But it's more complex to implement.
Pay-per-use pricing (per API call, per seat, per GB) requires metering, aggregation, and reporting usage to Stripe's metered billing API. The product tracks consumption; Stripe bills based on reported usage. Getting the metering accurate and the billing UX right.
Need to implement usage-based or metered pricing — where customers pay based on consumption (API calls, seats, data, messages sent) rather than a flat monthly fee
Usage-based pricing has two implementation layers:
Layer 1: Usage tracking
The application must accurately count usage. Every billable action increments the usage counter for the customer.
// Track an API call
await db.insert(usageEvents).values({
organization_id: orgId,
metric: 'api_calls',
quantity: 1,
timestamp: new Date()
});
Store individual usage events (not just totals) to allow for auditing and dispute resolution.
Layer 2: Stripe Meters
Stripe's Meters API receives usage reports and aggregates them for billing. Two approaches:
Stripe Meters (new API): Report usage events to Stripe in near-real-time. Stripe aggregates and bills.
await stripe.billing.meters.createEvent({
event_name: 'api_call',
payload: { stripe_customer_id: customer.stripeId, value: 1 }
});
Metered subscription items (legacy): Aggregate usage in the application, report the total to Stripe at the end of the billing period via stripe.subscriptionItems.createUsageRecord.
Usage dashboard:
Customers need visibility into their consumption. A usage dashboard shows current period consumption, projected bill, and historical usage. Builds trust and reduces billing dispute support tickets.
Hybrid pricing:
Many products combine subscription + usage: a base monthly fee (for the subscription) plus per-unit charges above the base (for overages). Stripe Billing supports this with a flat-rate component plus a metered component on the same subscription.
Usage-based billing with accurate consumption tracking, Stripe Meter integration, and usage dashboard so customers can see what they're paying for
Usage event tracking
in the application database
Stripe Meters
integration for billing
Customer usage dashboard
(current period, projected bill)
Usage limit alerts
(notify before overage)
Billing period reporting
for the customer's invoice
One honest number to start.
Fixed-scope, fixed-price. The number below is the starting point — final scope is built from your brief.
Usage-based billing with accurate consumption tracking, Stripe Meter integration, and usage dashboard so customers can see what they're paying for
Three steps, every time.
The same repeatable engagement on every project. No surprises, no mystery, no billable ambiguity.
Brief & discovery.
We send you questions, then get on a call. Output: a written scope with every step, feature, and integration listed.
Build & ship.
Fixed schedule, weekly reviews. No scope creep unless you change the scope — and if you do, we reprice it transparently.
Warranty & retainer.
30-day warranty on every launch. Most clients stay on a monthly retainer for ongoing features and maintenance.
Why Fixed-Price Matters Here
Usage billing scope is the metric count and the Stripe Meters configuration. Fixed-price.
Questions, answered.
Three models: hard limit (block when exceeded, require upgrade), soft limit (allow overage, charge per unit above limit), or notification only (warn the customer but don't block). Business decision; all three are implementable.
Usage reports should be reliable. Build retry logic into the reporting pipeline; store usage locally as the system of record; reconcile with Stripe periodically.
Tell Ryel about your project.
Describe what you’re building and what outcome you need. You’ll have a written, fixed-price scope within the week.