Nineveh for product teams

Nineveh sits between a bank’s virtual-account system and your product. Money arrives on an account number; Nineveh matches it, prices it, posts it to a double-entry ledger, and tells you — once, in a signed event you can verify. You keep your product. You stop keeping a ledger.

What Nineveh does

Matches a credit to the account number it landed on, and therefore to a unit and a tenant.
Prices it with your fee rule, so what the payer sends and what the tenant gets are both explicit.
Posts it as balanced double-entry journals. Balances are derived from postings and never stored.
Tells you, with a signed webhook, retried on a published schedule until it lands or dead-letters.
Reconciles what it holds against what the bank settled, and writes down every difference.

What Nineveh does not do

It does not hold a banking licence, issue account numbers, or move money at a bank. The account numbers belong to the bank; settlement is the bank paying a segregated collections account; payouts are recorded here and executed there. Nineveh is the record and the control plane, not the rail.

Nothing implies completion the provider has not confirmed. A credit becomes a balance when the bank says the money arrived. A payout is marked paid when an operator has a bank reference in hand — not when a button was clicked.

The shape of an integration

Two directions, and they are deliberately different mechanisms. You call Nineveh over HTTPS with an API key. Nineveh calls you with a signed webhook. A stolen console password cannot post a credit, and a leaked API key cannot approve a payout.

text

  bank ──notifies──▶ Nineveh ──signed event──▶ your product
                        │
                        ├─ prices the credit   (your fee rule)
                        ├─ posts the journals  (double entry, balanced)
                        └─ derives the balance (never stored)

Start with the Quickstart: receive one credit end to end, verify its signature, and read the balance it moved.