B2B Payments and Reconciliation Platform

The challenge

The client operated a B2B platform that disbursed payments to thousands of vendors on behalf of its enterprise customers. Money moved correctly — but proving it did was a manual ordeal. Every billing cycle, a finance team exported gateway settlements, bank statements and internal ledgers into spreadsheets and reconciled them by hand. It took three days, it was error-prone, and it did not scale with the customer base they were signing.

They needed a system where reconciliation was a property of the architecture, not a monthly clean-up exercise — and where every rupee could be traced end to end for audit.

Our approach

In payments, the interesting failures are not the happy path. We began by mapping every way money could be in an ambiguous state: gateway says settled, bank has not posted; payout initiated, webhook never arrived; partial refunds; retries that must never double-pay. The ledger design followed from that failure analysis, not from the happy path.

We chose an append-only, double-entry ledger as the source of truth. Nothing was ever mutated; corrections were new entries. That single decision made the system auditable by construction and made reconciliation a query rather than a reconstruction.

What we built

• An immutable double-entry ledger in PostgreSQL, with every external event — gateway webhook, bank file line, manual adjustment — recorded as a posting with full provenance.
• An idempotent payout pipeline integrated with Razorpay, engineered so that retries, duplicate webhooks and network failures could never cause a double disbursement.
• Automated reconciliation that matched gateway, bank and ledger continuously and surfaced only genuine exceptions for human review, with the evidence attached.
• An audit view that let finance trace any payout from customer instruction to bank confirmation in a few clicks.

Technologies & stack

A Node.js services layer over PostgreSQL, deployed on AWS with Terraform-managed infrastructure, secrets isolation and least-privilege access. Razorpay handled rails; the correctness guarantees — idempotency, the ledger, reconciliation — were ours. PCI-aware practices and tokenisation were applied throughout; the platform never stored raw instrument data.

Outcomes

• Reconciliation effort fell from three days to under two hours per cycle, and most of that remaining time is reviewing genuine exceptions, not searching for them.
• Zero double-disbursement incidents since launch, by design rather than by vigilance.
• The append-only ledger passed the client's external financial audit without a single follow-up query — the provenance was already there.

Related case studies

The same instinct — make correctness structural, not procedural — runs through our regulated healthcare work, where audit trails are a clearance requirement rather than a convenience.