Retries Need a Fresh Read

The most expensive bug in payment recovery is a confident one: an engine that decided yesterday what to do today, and never looked again. Between the decision and the attempt, the world moves. The customer updates their card from an email link. The platform's own native retry succeeds. A refund lands. An engine working from a stale snapshot charges into all of that blind — and the worst outcome in this business, a double charge, is almost always a stale-read problem wearing a scheduling costume.

So the rule in Swipe Again is absolute: before every attempt, re-read the live state. Is this failure still open? Has the invoice changed? Did something else already recover it? The attempt fires only if the fresh read says the world still matches the plan. Combined with idempotency keys on every charge and an atomic claim on the recovery row — so two workers can never grab the same failure — the double charge stops being a risk to manage and becomes a thing the architecture cannot do.

This is unglamorous engineering, deliberately. The exciting parts of recovery — the schedules, the cadence, the copy — all sit downstream of a boring guarantee: we never act on old information about someone's money. The Churnkey alternative reads first, every time. In payments, that is what trust actually compiles to.