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.
Draai je bedrijfCommercial platform
Betalingen geregeld
Checkout, upgrades en facturen werken al. Niemand betaalt twee keer door een retry.
Checkout, upgrades en facturen werken al. Niemand betaalt twee keer door een retry.
- 1
- catalog shared by pricing and checkout
- 4
- hosted billing provider adapters
- 1
- time each provider event applies
1 van 4 in Draai je bedrijf
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
See the no-subscription state and the implemented upgrade choices.
Inerte voorbeelddata · geen netwerktoegang
Voorbeeld gereed
Het probleem dat dit oplost
Zonder een gedeelde basis bouwt elk team deze randgevallen opnieuw — en anders.
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.
Kernpunten
Waarom dit belangrijk is
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.
Hoe het werkt
Het mechanisme van begin tot eind, zoals het in de repository is geïmplementeerd.
- 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.
Technische garanties
Wat dit wel en niet belooft
Veiligheidsgrens
Achter de schermen houden autorisatie, tenantgrenzen en foutafhandeling één duidelijke eigenaar. Zo blijft de snelle ervaring voor gebruikers gekoppeld aan veilig herstel als het misgaat.
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
Verwante functies
Deze functies delen contracten en grenzen met deze pagina.
Bouw verder op Betalingen geregeld
De documentatie beschrijft dezelfde contracten die deze pagina demonstreert.