Payment updates can go missing at three points, and providers or clients may retry

The third loss point is where the design pressure comes from: the business effect lands but the row that records it does not ^[5]. From outside your process, that is indistinguishable from a webhook that never arrived, and when the provider retries the same event later ^[6], the payload carries no way to separate "apply this" from "you already did". The receiver has to answer that question, which is why the application-side inventory in the dev.to piece includes a `processed_webhooks` table next to `payment_transactions`, `subscriptions`, `orders`, `invoices` and `wallets` ^[8]. That is the table nobody creates until the second incident.

The loop the article proposes is modest, and I think it is right: keep webhooks for near real-time updates, keep enough local state to know which records are unresolved, then periodically ask the authoritative source what happened and apply the missed update through the same path the webhook would have used ^[11]. Three conditions have to hold before that transfers to your stack. The handler must be safe to run twice, which the author treats as a design requirement rather than a nicety ^[13]. The schema must be able to name the unresolved set, which is the local-state half of the same recommendation ^[11]. And the provider must expose a lookup keyed by something you stored when you created the charge. That last condition is absent from the source material, and it is the one that varies most between providers. If the only handle you kept was the provider's id, and you lost it in the timeout, the sweep has nothing to join on.

Ordering is the other half of the subsystem. A delayed refund event must not leave a local record successful forever, and a missed failure must not keep access granted forever ^[12]. Both examples are about precedence rather than delivery: you need a rule for which state wins when an older event lands after a newer one, because arrival order carries no information about the order of the facts. The piece is blunt that this is ordinary distributed-systems behaviour and not an edge case to defer once money is in the path ^[14], and it extends the argument past the database boundary, where a committed transaction can still be followed by a failed cache update, notification or downstream job ^[7].

What is available here is framing rather than a specification. The outline promises sections on designing the flow, idempotency, reconciliation for payment providers, and observability with manual recovery ^[17], and the text stops before the flow itself. The framing is the part worth arguing about anyway, and it holds. If reconciliation means comparing state across a boundary and deciding what should be true now ^[3], then it owns a schedule and an owner, like any other subsystem in the diagram.