2.3 KiB
Financial reconciliation
The admin dashboard has separate Payouts and Refunds views. Start with the
Needs Attention filter and compare the row, application logs, and wallet history.
The overview and each list show processing and needs_review counts; these are
liabilities, not failed transfers that can safely be resent.
State rules
- A payout in
processingorneeds_reviewmay already have broadcast. Never use the retry action for it. - The payout retry action is available only for a hashless
failedorpermanently_failedrow. Use it only after proving the recorded error happened before broadcast and confirming that wallet history contains no matching transfer. The UI sends the API's required explicit confirmation. - A refund in
requestedhas not yet been claimed by the refund worker. A refund inprocessingmay have broadcast. A refund inneeds_reviewis quarantined. There is no dashboard resend action for any refund state. recordedmeans entitlements/payment state was reversed without an on-chain transfer;completedrequires transaction-hash evidence.
Reconciliation checklist
- Preserve the database row, service logs, wallet files, and current backups before changing anything.
- Match currency/network, destination, exact atomic amount, creation/processing time, transaction hash (if present), and wallet outgoing-transfer history.
- If a matching wallet transfer exists, record its hash and confirmation evidence in an audited remediation. Do not create a replacement transfer.
- If no transfer appears, treat that as inconclusive until the wallet is synchronized and the relevant time window and mempool are checked. Escalate ambiguous cases instead of retrying.
- Re-run the read-only financial audit after any reviewed database remediation and retain the before/after evidence with the incident record.
Periodic alerts use the same aggregate states. FINANCIAL_REVIEW_STALE_MS controls when a
payout processing row or refund requested/processing row is considered stale; the
default is 15 minutes. Alerts are read-only and never move or retry a transfer.
There is intentionally no generic "mark resolved" endpoint. A reviewed state transition needs a case-specific, audited remediation because the correct result depends on wallet evidence and whether value was actually transferred.