Dexwin Pay · Human review guide · Local issue 248.7.2

Prepare the source’s ledger resources before activating it

A Company source identifies its funding account. Saving it now verifies the Company’s GHS ledger and all nine required balance roles before the source becomes active. A durable receipt records the original save’s result.

Rollout is off by default. This page explains reviewed implementation and isolated test evidence. It is not a live banking demonstration or a deployment claim. Merge, deployment and live financial activation remain separate decisions.

Before

A source save could commit while ledger provisioning remained asynchronous. A saved source therefore did not establish that its ledger resources were ready.

After

The save prepares and verifies the resources first. One database transaction then activates the source and records its version, audit event and receipt. An uncertain response keeps the browser in recovery.

What happens during a save?

This is an illustration of the implementation, not captured runtime output.

Bind the original request: Company, actor, operation ID, account identity and the source version observed by the user. A version is a concurrency check: an older save cannot silently replace a newer source.
Prepare resources: use supported Blnk 0.14 role metadata and bounded database filters, then verify identities directly. Labels are discovery metadata; they do not prove uniqueness or readiness.
Check again: current authorization, KYC, holds, funding activity including admitted Care allocations, account ownership and the original version must still permit the save.
Commit together: the source, next version, fingerprint, audit event, attempt result and receipt change atomically. Remote provider calls happen outside these short database transactions.

What if the response is lost or the provider fails?

Unknown means the browser cannot establish the original result. It checks that operation’s status first. It never infers success from a later source and never automatically resubmits the save.

A definitive not activated result requires confirmed noncommit and durable revocation of that attempt. A user can explicitly resume the same original operation only when its binding and current gates permit it.

A generation is a numbered ownership attempt. Lease tokens, generations and deadlines prevent an older worker or delayed provider response from activating the source after ownership has moved. Background workers may prepare resources; only an authorized explicit source save can activate the source.

The browser clears account digits during recovery. Missing, malformed or reduced storage records stay conservative. Cross-tab restrictions cannot be upgraded by stale responses.

What changes in the database and shared foundation?

The implementation uses the shared financial foundation merged in PR #546. Generated migration 0088 adds the source-save-intent table. Released upstream migrations 0085, 0086 and 0087 remain intact; main’s Care Access changes from PR #552 and payroll verification marker from PR #555 are included. PR #553’s Finance production-deployment freeze remains in force.

Existing committed, identity-consistent resources retain signed financial history. New uncommitted resources must start at zero. Source provisioning makes no journal postings, resets or backfills.

The hook correction preserves a domain identity-mismatch error: SQL failures are mapped before domain reuse validation. The existing real-database mismatch test passed unchanged after the correction.

The concurrency proof also waits for the original delayed continuation to finish before checking each release order. This acknowledgement is available only in the isolated test adapter; it changes no production deadline or activation rule.

Observed evidence and practical limits

Normal commit checks: 6,912 API unit tests passed; formatting and lint passed.
Fresh API typechecking and migration lineage/baseline checks passed. Final full integration hooks, all three web typechecks and exact-head required CI are tracked in PR #556.
Real isolated API/PostgreSQL/Redis/Blnk acceptance: 90 required case IDs, including 71 timed leaves, passed. Every observed child lifetime made zero journal POSTs.
Production-built browser acceptance: five tests covering eight scenario rows passed with zero unexpected operational events through cleanup.
All 24 semantic mutations ran: 20 were killed by behavioral checks; four survived and are classified against retained guards. This is not proof against arbitrary database corruption or multiple guards being removed together.
Empty, populated and repeated migrations preserved all 94 original tables and values. The actual archived previous API and worker ran against the expanded schema with synchronous provisioning off.

These are local, disposable-environment results on the revision below. They do not prove live Affinity behavior, full Care funding execution, downstream payroll posting, cutover readiness or rollback safety during unresolved downstream journal work. Dedicated approved Financial Recovery UI files remain unchanged; shared client/environment changes are inherited and separately scoped.

All completed stateful setups were removed. No customer data, credentials, raw logs or private machine paths appear on this page.

Where should a reviewer start?

Review focus: original identity/version binding; final receipt and gate ordering; deadlines and generation fencing; exact resource identities and preserved history; browser status-before-resume; migration compatibility.