A single reconciliation function every payment path funnels through. It re-sums the payment rows, writes amount_paid and payment_state, advances or holds the order status, and strips a 'paid' journey entry if the payments that proved it have gone. Deleting recomputes from the surviving rows rather than subtracting, so one bad write cannot leave a permanent drift.
Also called: order says $0 paid · wrong balance · amount paid wrong
- 1reconcilePaidStatus re-reads the payments and rewrites amount_paid and payment_state
- 2Sums are rounded to cents; a half-cent epsilon stops a fully-paid order sticking at partial
- 3Cancelled, disputed and returned orders are frozen
- 4A failed reconciliation rolls the payment insert back, so a false return means nothing happened
- 5A successful proxy update is distinguished from a failed one, because an UPDATE returns no rows
'It used to be written by whichever call site remembered to, and one that didn't (the payments modal) left an order reading "$0.00 of $48,840 paid" while $9,667 of payment rows sat underneath it… this column is a cache of their sum, so it is recomputed here — the one place every path funnels through.' A separate comment records the write-detection bug: 'db collapses two very different outcomes into the same null… every successful update reported failure… a good payment got rolled back as if it had failed.' And on the rollback: 'A payment whose balance never landed is worse than no payment at all: the money is recorded, the order still reads as owing it, and the next person pays it again.'
- A hand-maintained total drifts from the payments underneath it
- A payment recorded with a stale balance gets paid again
- A successful save reported as a failure
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →