1
1 Comment

Show IH: I built the payments infrastructure layer your SaaS is missing

Most SaaS payment bugs aren't Stripe bugs.

They're yours.

You integrated Stripe in a weekend, shipped, and moved on. But somewhere in production you have:

  • No idempotency on charge execution — retries create duplicate charges
  • Webhooks processed without deduplication — events fire twice, balances break
  • No audit trail — you can't reconstruct what happened during an incident
  • No internal ledger — your balance in the DB drifts from what Stripe says

You find out when a customer emails you. Or worse, when they file a chargeback.

───

I've been building payment systems for a while and kept solving the same problems across projects. So I extracted the infrastructure layer and packaged it as a reusable kit.

HAYLAYN Backend Kit is a production-ready NestJS backend with the financial infrastructure built in from day one:

  • Double-entry ledger — every transaction recorded as paired debit/credit entries. Your balances never drift.
  • Idempotent payment execution — charge operations are safe to retry. No duplicate charges.
  • Outbox pattern — events are persisted before being dispatched. No lost webhooks.
  • Webhook processor — deduplication, ordering, retry logic included.
  • API key system — issue, rotate, and revoke API keys for your customers.
  • SLA monitoring — operational health dashboard out of the box.

Stack: NestJS 10 · Prisma 5 · PostgreSQL 16 · Docker

Everything is typed, tested, and documented. You clone it, configure your env, and you have a backend that handles money correctly.

haylayn.com

───

I'm curious: what's the most painful payment infrastructure problem you've had to solve from scratch? And would you have bought something like this early on, or do most of you prefer to build it yourself?

on March 16, 2026
  1. 1

    Internal ledger + idempotency + outbox is the right shape. The part I’d add is a reconciliation/outcome layer after the async path finishes.

    Example: Stripe says invoice failed -> local subscription/access state changed -> audit evidence exists. Without that, each component can look “working” in isolation while the actual money state still drifts.

    If you’ve solved this across projects, where did teams usually get burned first: duplicate events, missing events, or events handled successfully but not reflected correctly in their DB?