The event applied twice
Providers resend webhooks as a matter of course. Code that treats each delivery as new grants access or credit a second time. Here a redelivery finds a receipt and changes nothing.
The foundation under itCommercial platform
Plan and payment plumbing
Platform machinery we do not use to sell Growth-OS.
Growth-OS is internal, so nobody buys it and no provider is configured for checkout. What this capability still decides is the plan our own workspace resolves to, because that plan is where the entitlements behind AI and project limits come from. Checkout, the customer portal, metered usage and verified provider webhooks are implemented and stay behind authenticated server boundaries.
- 1
- catalog shared by plans and entitlements
- 4
- hosted provider adapters implemented
- 1
- time each provider event applies
7 of 22 in The foundation under it
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
The state a workspace with no subscription is in, and the plans the catalog defines.
Inert sample data · no network access
Preview ready
The problem this solves
Without a shared foundation, every team rebuilds these edge cases, differently.
The cancellation that came back
A slow update arrives after a newer one and flips state backwards. The server compares provider timestamps under a row lock and acknowledges the older event as stale instead of applying it.
Three copies of the same price list
One list on a page, another in checkout, a third in the code that grants access. They drift, and the difference is noticed from outside. One typed catalog removes the question.
Highlights
Why it matters
One catalog, one answer
Plans, offers, entitlements and provider identifiers live in one typed file, so what a workspace is allowed to do is written down once.
A repeated provider event changes nothing
Providers resend events by design. Each one applies exactly once, under a receipt, instead of being fulfilled twice.
Late news is discarded
An event that arrives after a newer one is skipped while a row lock is held, so a stale message cannot revive a cancelled subscription.
How it works
The mechanism end to end, as implemented in the repository.
- 1
One catalog defines the plans
Modes, offers, provider identifiers and fulfillment are declared once in config/billing.ts. Plan pages, checkout and server-side access all read that same definition.
- 2
A workspace resolves to a plan
resolveCommercialAccess maps subscription state to a plan, with a grace window for a late payment. With no subscription the answer is the free plan, unless an explicit organization grant says otherwise.
- 3
Every provider message is verified
The webhook route checks a provider signature, or for Mollie classic payment webhooks retrieves the referenced entity with the server key. A forged or unbound message cannot fulfill anything.
- 4
State only moves forward
Each event applies inside a locked transaction, exactly once, and older events are skipped. Billing state never goes backwards because of delivery order.
Engineering guarantees
What this does and does not promise
Safety boundary
Nothing on this site opens a checkout session; the public pages read the catalog directly. Because we do not sell Growth-OS, checkout, the portal and usage reporting have no day-to-day use for the team. Read this page as a description of the machinery, not of a screen you will open.
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
Used alongside this
These capabilities share contracts and boundaries with this one.
What plan and payment plumbing rests on
The docs describe the same contracts this page demonstrates.