A 200 response is not proof of correct billing state.
A TypeScript reliability and conformance kit for teams already running Stripe Checkout or Billing against their own database. It drives the duplicate deliveries, crashed workers, stale events and failed writes that happy-path examples never reach, and fails when your integration does not hold.
Stripe event
received
Signature verify
—
Durable lease
—
Business operation
—
Postgres commit
—
Entitlement reconcile
—
Stripe event
received
Signature verify
—
Durable lease
—
Business operation
—
Postgres commit
—
Entitlement reconcile
—
- Automated tests
- 83
- Automated tests
- PostgreSQL integration tests
- 14
- PostgreSQL integration tests
- Node.js versions in CI
- 20 · 22
- Node.js versions in CI
- Stripe sandbox lifecycle
- Live
- Stripe sandbox lifecycle
01 — The problem
Webhook examples stop where production starts.
Every failure below is ordinary. Each one is a documented property of at-least-once delivery, distributed retries and concurrent writes — and each one quietly produces the wrong billing state.
Duplicate delivery
Stripe retries. Your handler runs a second time and the customer is granted the same purchase twice.
Out-of-order arrival
Events do not arrive in the order they were created. The last write wins, and it is the wrong one.
Acknowledged, then failed
The endpoint returns 200 before the transaction commits. Stripe considers it delivered and never sends it again.
Stale workers
A process stalls, wakes up long after its claim expired, and overwrites state that moved on without it.
Retry after partial work
Half the effect committed before the failure. The retry repeats the half that already happened.
Truncated entitlement summaries
The event payload carries a capped view of the customer's entitlements. You persist it as though it were complete.
Concurrent customer updates
Two events for one customer interleave between read and write, and one of them disappears.
02 — Failure modes
Six failures, each with a named control and a test that proves it.
These are the scenarios the conformance suite drives against your implementation. Pick one to see the sequence it forces and the property it holds you to.
Same purchase. Multiple events. One durable effect.
- checkout.session.completed delivered
- Lease acquired · business operation commits
- Identical event redelivered
- Operation already recorded · no second grant
One purchase produces one durable business effect, however many times the event is delivered.
- injected fault
- control engages
- normal progress
Correct billing state is not decided by the handler that returned 200.
It is decided by what actually committed, what got retried, and what was reconciled afterwards. That is the part this package tests.
03 — What you get
A package you read, run and keep.
One download. No service to sign into, no license check at runtime, nothing that stops working if this site goes away.
- runtime
- TypeScript runtimeSignature verification, event leasing, business-operation deduplication and entitlement reconciliation.
- persistence
- PostgreSQL primitivesDurable event leases, stale-worker fencing and transactional operation records.
- conformance
- E1–E9 conformance suiteThe executable specification your integration has to satisfy, run against your own implementation.
- fixtures
- Failure-injection fixturesIncluding deliberately broken implementations the suite is expected to reject.
- migrations
- SQL migrationsThe schema the persistence primitives depend on, ready to apply.
- reference
- Next.js App Router exampleA working end-to-end integration you can read, run and copy from.
- package
- Compiled .tgzInstall into an existing project without building from source first.
- docs
- DocumentationSetup, the reliability model, and the reasoning behind each control.
- source
- Full source codeEvery module the compiled package is built from, readable and modifiable.
You own the infrastructure. The harness runs inside your application, against your database, on your hosting. There is no hosted component, no telemetry and no call home.
- Node.js 20 / 22
- TypeScript
- PostgreSQL
- Stripe Checkout / Billing
04 — Conformance
The tests are the product.
Webhook boilerplate is not hard to write. Knowing that the version you wrote is correct — under redelivery, partial failure and concurrency — is the part nobody can eyeball.
The E1–E9 suite drives those conditions at your implementation and reports on each control individually. It is written to be hostile: it ships with implementations that are deliberately wrong, and it is expected to reject them.
A control that was never exercised reports SKIPPED. Silence is never read as success.
- PASSduplicate delivery · single durable effect
- PASSpersistence failure · non-2xx before retry
- PASSpost-commit bookkeeping failure
- PASSstale entitlement event · reconciled
- PASSconcurrent customer updates · serialized
- PASSentitlement pagination beyond summary
- SKIPPEDstale worker fencing
- PASSpayment-mode checkout handling
- FAILbroken reference · duplicate grant
- PASS
- The control was exercised under the failure and held.
- FAIL
- The control was exercised and did not hold. Here, against a deliberately broken reference.
- SKIPPED
- The control was never exercised. It is reported as unproven — never counted as a pass.
05 — Reliability boundaries
What this does not do for you.
Reliability claims are only useful when their edges are stated. These are the limits of the model, written the way they appear in the documentation.
An event lease does not make business effects exactly once.
A lease prevents concurrent processing of the same event. Exactly-once business effects come from stable operation identity, not from the lease.
Stable business operation IDs are required.
Deduplication is only as good as the identifier you derive. If the same logical purchase can produce two different IDs, it can produce two effects.
Transaction boundaries matter.
The operation record and the business write must commit together. Split them across transactions and the guarantee is gone.
Remote side effects need their own idempotency or outbox pattern.
Database transactions cannot roll back an email, a provisioning call or a third-party charge. Those need idempotency keys or an outbox.
Stripe event timestamps are not authoritative ordering tokens.
Timestamps tell you when an event was created, not what is currently true. Reconcile against current state instead of sorting by time.
High-throughput systems should durably enqueue before acknowledging.
Processing inline inside the webhook request is fine at modest volume. Past that, persist the event and acknowledge, then process out of band.
06 — Pricing
One price. Bought once, yours permanently.
Limited to the first 25 customers. Regular pricing is planned at $99 afterwards.
Get Founding Edition — $79Checkout is handled by Polar. Read the commercial source code license before buying.
- Full source code
- Commercial use
- Unlimited applications owned by the purchaser
- Updates through v1.x
- Installation and reproducible-defect support
- No runtime fees and no license server
- No revenue share
- No hosted service
- No deployment fee
- No subscription
07 — Questions
Before you buy.
Anything not covered here, ask directly. Questions about fit, requirements or licensing get an answer from the person who wrote the code.
onborrowedtime.obt@gmail.comIs this a SaaS product?
No. There is no hosted service, no runtime license server and no account to maintain. You buy the source code, run it inside your own application, and it keeps working whether or not this site exists.
Do I get the source code?
Yes. The full TypeScript source ships with the package, along with fixtures, migrations, tests, documentation and a compiled .tgz you can install directly.
Does it replace Stripe Billing?
No. Stripe remains your billing system. This is the layer between Stripe's events and your database — the part that decides what your application believes about a customer, and proves that belief survives redelivery, failure and concurrency.
Does it work without PostgreSQL?
The shipped persistence primitives — event leases, operation records and fencing — are PostgreSQL implementations, and the integration tests run against a real PostgreSQL database. The runtime is written against persistence interfaces, so another transactional store is possible, but you would be implementing and verifying that adapter yourself.
Is there a recurring fee?
No. $79 once. No subscription, no per-seat charge, no revenue share, no usage metering.
Can I use it commercially?
Yes. The license grants perpetual commercial use across an unlimited number of applications owned by the purchaser, and you may ship compiled portions of it inside your own applications. What it does not allow is redistributing the source publicly or reselling the Kit as a standalone developer product. The full terms are reproduced on the license page.
What are the runtime requirements?
Node.js 20 or 22 (both validated in CI), TypeScript, PostgreSQL, and an existing Stripe Checkout or Billing integration. The reference implementation uses the Next.js App Router; the runtime itself is framework-agnostic.
Are future updates included?
Founding Edition purchasers receive updates through version 1.x. The current release is v0.2.0.
Does this guarantee my billing can never fail?
No, and any product claiming otherwise is selling you something else. It gives you specific, named controls for specific, named failure modes, and a conformance suite that fails when those controls are absent. The reliability boundaries section states plainly what it does not cover.