Backend Engineer: Payments platform, Node/TypeScript, PostgreSQL, ledger & API integrations.

Overview We are building a cross-border payments platform. The domain layer already exists — a tested TypeScript core with a double-entry ledger, a rules engine, an append-only audit log and a payment validation gate, with 82 passing tests. We need an engineer to build the integration layer around it. The architecture is decided and documented. We need someone who writes careful, well-tested backend code and who is good at making third-party APIs behave predictably. What you would build 1. PostgreSQL persistence layer. Repository implementations behind interfaces that already exist. Migrations, plus tests proving the database-level constraints fire — unbalanced ledger entries rejected, audit rows immutable, retention guards enforced. 2. Integration ports and adapters. Six external capabilities sit behind interfaces we define: identity verification, sanctions screening, company registry, payment rails, FX rates, regulatory filing. Each needs a working stub adapter plus a contract test suite that any real vendor adapter must also pass. One vendor adapter (Shufti Pro) is already written as the reference. 3. Payment orchestration service. Quote, validate, commit, submit, settle, reverse — with correct ledger postings at every transition and reconciliation that holds through a hold, a release and a reversal. 4. REST API layer. Thin. Schema validation with zod, role-based authorisation enforced at the service boundary, idempotency keys on mutating endpoints, consistent error model. 5. Auth, environments and CI. Identity provider integration, MFA, session handling. Dockerised local stack, seeded demo data, CI running typecheck, lint and tests on every push. You must be comfortable with • TypeScript and Node, strict mode, in a codebase where types are load-bearing • PostgreSQL beyond CRUD — transactions, triggers, check constraints, deferred constraints, and knowing when a rule belongs in the database rather than the application • Third-party API integration where the documentation is incomplete or wrong: signature verification, webhooks, retries, timeouts, and deciding what happens on failure • Testing as a first-class activity. Every control needs a test that attempts the forbidden thing and asserts it is refused. "It works on the happy path" is not done. • Money as integer minor units. If you would reach for a float or parseFloat near a monetary amount, this is not the right role. Nice to have Double-entry bookkeeping. Payments, KYC/AML or other regulated domains. Experience with a codebase where an audit trail mattered. How we work • Small repository, clear module boundaries, dependency rules enforced by lint • Trunk-based, short branches, every merge reviewed • Work packages with written acceptance tests — a task is done when its acceptance test passes in the integrated build • You will receive a full written specification and the existing codebase after an NDA To apply Please include: 1. A code sample or repository showing backend work you are proud of. A link is better than a description. 2. Your answer to this: a third-party screening API times out halfway through processing a payment. What should the system do, and why?