ENGINEERING NOTE 32 / 50 · CARD
Build a reconciliation queue for uncertain card operations
Uncertain operations need an owner, next action and evidence deadline. A generic failed label encourages unsafe retries and hides unresolved money movements.
Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.
Capture ambiguity explicitly
Distinguish rejected before submission from submitted with no final answer. Persist upstream reference, safe operation ID and last query outcome. An operation that may have succeeded should remain visible until reconciliation establishes its result.
Schedule bounded queries
Use a next-check time and backoff rather than hot-looping the upstream. Escalate after a documented window with the evidence collected so far. Avoid creating a second operation as a way to see whether the system is working.
Resolve with an audit trail
Each resolution should reference authoritative evidence and the ledger entry it produced or confirmed. Separate a human note from a financial mutation. Review queues are not permission to edit balances without the established settlement controls.
Illustrative implementation
case = {"state":"outcome_unknown", "next_check_at":t,
"attempts":2, "operation_ref":"demo", "owner":"operations"}Acceptance check
Every unresolved item must have a next action. Check that queue retries never produce duplicate debits or loads.