Repository navigation
Rehearse optional monetary settlement and reconciliation before enablement #87
Description
Problem
Current automated payment evidence establishes disabled-mode behaviour and scripted enabled wiring. It does not validate a complete receipt/charge/refund/payout lifecycle against a selected settlement implementation or an operator custody/recovery procedure.
Proposed change
Prepare a reviewed monetary support profile and exercise its complete failure/reconciliation workflow in a controlled test environment before any real-money enablement.
Acceptance criteria
- Select and document chain/network/asset, operator/custody responsibilities, economic rules, supported upgrade/backup recovery and who can authorize enablement.
- Run duplicate receipts, response loss, crashes before/after external success, concurrent new earnings, refund retry and recovery drills against the selected local test backend or emulator.
- Reconcile every uncertain effect using durable identities; establish no second debit, refund or payout and preserve later earnings.
- Obtain independent review of financial-effects and custody boundaries and publish the explicit remaining limits.
- Keep TEST fully supported; live funds or outside infrastructure remain a separate operating decision, not a side effect of a passing CI job.
Current evidence
unimplemented optional validation and release gate; source inspection only, no new runtime reproduction. Backlog classification is based on source inspection; this issue does not claim a new runtime reproduction.
- internal/dispatcher/payments/payments_test.go: Payment construction tests use scripted dependencies; their scope is not a live settlement certification.
Dependencies
- #88 — Replace UUID-cookie login with authenticated user sessions
- #89 — Enforce ownership and role authorization on every HTTP operation
- #79 — Acknowledge payment receipts only after durable processing
- #80 — Reserve exact payout amounts and reconcile uncertain transfers
- #81 — Make refunds safe for empty orders, write failures and uncertain transfers
- #82 — Propagate enabled Sui backend construction errors and validate dependencies
- #84 — Pass coin type and receiver in the correct USDC transfer order
- #85 — Handle paginated and malformed coin balances during Sui coin selection
Related work
These are integration points, not prerequisites for starting this issue.
- #111 — Create consistent versioned backups of operator state
- #112 — Restore a verified backup into separate state without replaying measurements
Priority context
Optional marketplace expansion after the non-monetary product; not required for local TEST adoption.
Activation
Optional work, deferred while the local team alpha is the priority. Development and fault injection use owned local fixtures. Production monetary operation, deployment and publication require the applicable release and operator approvals.
Validation must use owned local fixtures on supported Linux environments. Record the implementing merge request and relevant test results before closing this issue.
Imported from GitLab issue 86. Originally opened 2026-09-10. Historical GitLab links may require access to the original project.
Activity
State the chain payment schedules and the restore caveat
Merge the corrected payout branch into the rehearsal branch
Merge the corrected payout branch into the operations page branch
Merge the corrected allowances branch into the operations page branch
Merge the composed allowances branch into the operations page branch
Assert the refund outcome in the rehearsal drills
Merge current allowances into the payment operator profile
Merge the current payment stack into settlement rehearsals
Clarify payment deployment rehearsal checks
Merge distinct-port fixture repair into settlement rehearsals
Clarify cancellation refund recovery limits
ctfbruce commentedon Oct 5, 2026
The supported Sui Testnet USDC profile and custody, enablement, upgrade and recovery limits are documented in #383 and #391. #384 exercises duplicate receipts, response loss, stops before/after submission, later earnings, refund handling and restart recovery against a scripted chain and real SQLite; the rehearsal CI passed. A controlled Testnet run additionally completed paid execution, payout, paid-run failure and refund, schema upgrade, restart reconciliation and duplicate receipt replay. Financial effects and custody boundaries received independent review.
Automatic settlement retries require a recorded executor exit code. A dispatcher-recorded cancellation can lack that evidence; if its refund failed before reservation, automatic recovery remains a documented limit tracked in #392. Existing uncertain transfers must be reconciled before any replacement. TEST remains supported and shipped configurations remain chain-disabled. This acceptance does not authorize production or mainnet operation, certify arbitrary backup restoration, or claim every fault was injected on the live chain. Final configuration and refund corrections are covered by #391 checks.
The final correction is merged as e79fe623; main validation passed all 16 checks.