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.
Het fundament eronderCommercial platform
Plan- en betaalmachinerie
Platformmachinerie die we niet gebruiken om Growth-OS te verkopen.
Growth-OS is intern, dus niemand koopt het en er is geen provider ingesteld om mee af te rekenen. Wat dit onderdeel wel bepaalt, is het plan waar onze eigen werkruimte op uitkomt, want daar komen de rechten achter AI en projectlimieten vandaan. Afrekenen, het klantportaal, verbruiksrapportage en geverifieerde providerwebhooks zijn gebouwd en blijven achter ingelogde servergrenzen.
- 1
- catalog shared by plans and entitlements
- 4
- hosted provider adapters implemented
- 1
- time each provider event applies
7 van 22 in Het fundament eronder
Productvoorbeeld
Bekijk het in werking
Dit is hetzelfde visuele component als in de ingelogde applicatie, met voorspelbare voorbeelddata.
Scenario
Voorbeeldscherm
Thema van voorbeeldoppervlak
Voorbeeldmodus
Free workspace
The state a workspace with no subscription is in, and the plans the catalog defines.
Inerte voorbeelddata · geen netwerktoegang
Voorbeeld gereed
Het probleem dat dit oplost
Zonder een gedeelde basis bouwt elk team deze randgevallen opnieuw, en anders.
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.
Kernpunten
Waarom dit belangrijk is
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.
Hoe het werkt
Het mechanisme van begin tot eind, zoals het in de repository is geïmplementeerd.
- 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.
Technische garanties
Wat dit wel en niet belooft
Veiligheidsgrens
Niets op deze site opent een afrekensessie; de publieke pagina’s lezen de catalogus rechtstreeks. Omdat we Growth-OS niet verkopen, hebben afrekenen, het portaal en verbruiksrapportage geen dagelijks nut voor het team. Lees deze pagina als een beschrijving van de machinerie, niet van een scherm dat je opent.
Implementatiebewijs
De grens hierboven is geen claim maar code. Deze bestanden dragen het contract:
src/features/billing/server.tssrc/features/billing/providerssrc/features/billing/jobs.tsconfig/billing.ts
Vragen
Veelgestelde vragen
Hiernaast gebruikt
Deze functies delen contracten en grenzen met deze pagina.
Waar Plan- en betaalmachinerie op rust
De documentatie beschrijft dezelfde contracten die deze pagina demonstreert.