The rules the code follows
A billing period is billed once.
Every close locks the subscription and checks its period has not moved. Behind that, a unique index refuses a second invoice for the same period, so a crash or two racing workers cannot bill it twice.
Evidence: A billing process killed at five points left 0 duplicate and 0 lost invoices. With the index dropped, four billing engines racing on 40 periods billed 103 invoices, so the test can see a failure. That run predates the subscription lock, the guard now in front of the index. Correctness under failure →
Fail loudly.
If a read that a bill needs fails, the bill stops with an error. It never bills a default. A subscription that keeps failing is parked for you to look at.
Evidence: How it works, and why, is in its design record. Design record 119 →
For card charges, Stripe’s record decides what was paid.
A charge with an unclear result is held while Hardcount checks Stripe for the payment. If Stripe shows none 24 hours after the attempt, the invoice is charged again.
Evidence: Each case, and the known gaps, are listed in one place. Card payment failure handling →
One Postgres.
All billing data lives in Postgres; Redis is for rate limits only. No queue broker, warehouse or workflow engine until a measurement says Postgres is not enough.
Evidence: One large database took 12,000 usage events a second in 4 of 5 ten-minute runs, and in all 5 after one Postgres setting change. The hardware and method are stated. How much it handles →