A paid M-Pesa ticket went undelivered because fulfilment threw after the SUCCESS write

The line that decides which payments can ever be repaired is the query predicate: `findMany({ where: { status: 'PENDING' } })` ^[8]. Status on that row records what Paystack said about the charge, and delivery of the thing bought happens in a separate step ^[11]. So the job's write removes a row from the job's own read set. Once it sets SUCCESS, that row can never match PENDING again ^[15].

Justin Wilson, commenting on the author's earlier post about STK Push timeouts and webhook verification ^[1], said: "The key missing safeguard is idempotency. Store transaction keys and make retries safe so delayed callbacks cannot create duplicate orders." ^[2] The author added exactly that. Ticket issuance is guarded by an already-issued check for the payment, and stream access is an idempotent upsert keyed on user plus resource, so two runs of the job, or three replicas running it at once, cannot produce two tickets for one payment ^[9].

Verification worked too. The job found the stuck payment, confirmed with Paystack that real money had moved, and flipped the row to SUCCESS ^[10]. Fulfilment then threw partway through, on a tenant-context bug in how the job ran that had nothing to do with payments ^[12]. By then the status write had landed ^[12].

From that moment the payment was outside every recovery path in the system. The sweeper reads PENDING ^[8], and this row said SUCCESS, so nothing looked at it again and nothing was watching for the gap ^[13]. The customer had paid, and the system treated the transaction as closed ^[13].

The author's fix is to invert the order and fulfil first ^[14]. That makes fulfilment the step that can run more than once, and the guards already cover that case: the already-issued check and the user-plus-resource upsert both absorb a repeat ^[16]. For the inversion to transfer to another codebase, fulfilment has to be idempotent under a key that holds across replicas. Where it is not, the failure mode changes from no ticket to two.

The other option is to keep the order and add a second sweep over payments that are settled but undelivered, which needs a field to sweep on. The post describes status values on the payment row and no separate fulfilment flag ^[17].

Either fix depends on being able to see the path. Before logging was added at charge initiation, the payment code emitted no log lines at all ^[4], and the first thing the new line printed was `http=200 status=true dataStatus=pay_offline` ^[5], which is Paystack's state for waiting on the customer to finish on the phone ^[6].