Payment history
Every payment this module has captured, with its current lifecycle status and the outcome of the pre-release validation gate it passed through. The status shown is read from the stored payment row on each render — there is no cached projection — so an originator sees a change (a hold released, a settlement completing) as soon as it is committed.
No payments match these filters.
Not polling: nothing on screen can change status any more. Showing state as of .
No payments have been captured yet. Post an internal transfer to see it here.
Lifecycle
A payment walks Initiated → Validated → Held → Posted for on-us book transfers, or Initiated → Validated → Pending settlement → Settled when it clears through the scheme adapter. It can end in Returned, Failed, Rejected. Open a payment to see its postings and its full status timeline.
Before any release, every payment runs the same validation gate — payee exists and is verified, positive whole-cent amount, sufficient available funds, within limits, and the fields its payment type requires. Each failed check gets a named reason code (shown above); a reject-disposition failure refuses the payment outright, a hold-disposition failure parks it in Held, and a held payment posts nothing while it is held.
Sample book disclosure: the customer accounts and staff users in this environment are seeded demonstration data created by this module — there is no connection to a real core banking system or payment scheme.