Stripe + independent metering
UsageBox records billable quantities, deduplicates retries and preserves raw events. Stripe can stay responsible for pricing, invoices, tax and payments.
Your application emits the measured quantity to UsageBox first. Pricing and invoice decisions remain downstream, so changing a Stripe price does not rewrite the evidence behind prior usage.
Producers retry and queues redeliver. The metering layer handles duplicate delivery before quantities are exported to a billing workflow.
A rollup is useful for billing; raw accepted events are useful when someone asks why the rollup is 12,431. Keep both available independently from the invoice object.
Keep prices, subscriptions, tax, invoices, payment methods and dunning in Stripe rather than recreating financial operations in the usage layer.
If you later change payment or billing providers, the instrumentation in your product and the historical usage ledger do not have to migrate at the same time.
The public quickstart shows the exact server-side request shape before signup. If it fits, create a key and keep that same contract in production.
Product boundary
The boundary is deliberate: trustworthy quantity on one side, financial operations on the other. That keeps usage instrumentation stable while pricing and billing workflows evolve.
Choose the usage signal, inspect the exact payload, then create a free key only when the contract fits your integration.
Migrating legacy Stripe usage billing?
The migration checker inventories removed UsageRecord resources, aggregate_usage, action=set semantics and billing_threshold dependencies before you touch the production API version.