■FIG. A.1 · Production SaaS · solo-built · May 2026
qlabaqua.com
The fastest way to misread this project is as “a website.” It is a payments-bearing production system: every rupee that moves through it passes an idempotency boundary I designed for retries, duplicate webhooks, and hostile concurrency. Thirty live pages sit on 38 REST routes, and the whole thing is guarded by a CI gate of 330+ Vitest tests.
— ledger console idle. run the charge to watch retries collapse. —
model of the committed design: unique-index upserts, lost-race recovery, timing-safe HMAC webhooks, 30-day ledger reconciliation. production system at qlabaqua.com.
THE PAYMENTS CORE
The core idea is that a payment event should be a fact with a unique identity, not a message with effects. Orders carry idempotency keys; the ledger enforces them with unique-index upserts, so a retried charge or a redelivered webhook converges to exactly one revenue event. Lost-race recovery handles the case where the webhook arrives before the synchronous verification does.
Webhook verification is timing-safe HMAC over the raw request body — never a re-serialized one. On top of that, Python jobs reconcile the local ledger against the gateway every 30 days, so even a bug in the live path surfaces as a diff, not a mystery.
ABUSE AND BOUNDARIES
Rate limiting is fail-closed and transactional in Postgres — state lives in the same transaction as the request’s effects, and it holds at 500+ concurrent requests. CSRF protection runs independently at the edge rather than trusting one layer. Every request body is Zod-validated at the boundary, so internal code never sees untyped input.