The double-charge email
A provider resends a webhook, which is normal. Your code applies it twice. Now a customer's access or credit balance is wrong. Here, a repeated event changes nothing.
Run the businessCommercial platform
Flexible billing
Subscriptions, usage, one-time access, and credits from one catalog.
Choose Stripe, Lemon Squeezy, Polar, or Mollie for hosted checkout and verified webhook fulfillment. Provider-specific portal and metering capabilities change the product surface automatically.
- 1
- catalog shared by pricing and checkout
- 4
- hosted billing provider adapters
- 1
- time each provider event applies
1 of 4 in Run the business
Product example
See it working
This is the same visual component used by the authenticated app, rendered with deterministic sample data.
Scenario
viewport
surface theme
mode
Free workspace
See the no-subscription state and the implemented upgrade choices.
Inert sample data · no network access
Preview ready
The problem this solves
Without a shared foundation, every team rebuilds these edge cases — differently.
The zombie subscription
A customer cancels. A slow update message arrives late and flips them back to active. They get billed for a plan they ended. This kit checks event timestamps and throws the stale message away.
Three copies of your pricing
The pricing page says one thing. Checkout charges another. The server enforces a third. They drift apart slowly, and a customer notices before you do. Here it's all one file.
Highlights
Why it matters
One product catalog
Pricing, checkout, provider IDs, access, credits, and usage all read the same typed definition.
Repeats change nothing
Providers resend events by design. Each one applies exactly once, so a repeat settles to the same result.
Old news gets ignored
If a late message arrives after a newer one, the server skips it. A cancellation can't get undone by a stale update.
How it works
The mechanism end to end, as implemented in the repository.
- 1
One product catalog
You define modes, offers, provider IDs, and fulfillment once. Pricing, checkout, and server-side access read from that same definition.
- 2
The server opens checkout
Only an organization admin can start hosted checkout. Stable idempotency keys prevent retried clicks from creating duplicate sessions.
- 3
Every provider message is checked
The active webhook route verifies a provider signature or, for Mollie classic payment webhooks, retrieves the referenced entity with the server API key. Fake, malformed, or tenant-unbound messages cannot fulfill anything.
- 4
State moves forward, once
Each event applies inside a locked database transaction, exactly one time. Older events are skipped, so your billing state only ever moves forward.
Engineering guarantees
What this does and does not promise
Safety boundary
The public demo reads the real catalog but never calls a provider. Live checkout, portals, usage reporting, and webhook sync stay behind authenticated server boundaries.
Implementation evidence
The boundary above is code, not a claim. These files carry the contract:
src/features/billing/server.tssrc/features/billing/providerssrc/features/billing/jobs.tsconfig/billing.ts
Questions
Frequently asked questions
Related capabilities
These capabilities share contracts and boundaries with this one.
Build on the flexible billing foundation
The docs describe the same contracts this page demonstrates.