DEV Community

Swipe Again for Swipe Again

Posted on

Retries Are Promises

Every retry attempt makes a small promise to an issuing bank: this charge is wanted, the customer knows, the amount is right. Keep the promise and the bank learns to trust the traffic. Break it — attempt too often, re-present charges the customer has disputed, keep knocking on a card the issuer has pronounced dead — and the promise devalues for every charge that follows, including the legitimate ones from the same descriptor.

This is the unglamorous ethics of scheduling. Spacing is promise-keeping. The eight-attempt ceiling is promise-keeping. Stopping on a hard decline instead of arguing with it is promise-keeping, and so is the fresh state check before every attempt, because a promise made on stale information is a promise made carelessly. None of it shows in a feature list. All of it shows in the approval rates a merchant's good charges receive months later.

Swipe Again treats attempt discipline as a covenant with the customer's bank, not a growth hack — the recovery flow would rather make fewer attempts it can stand behind than more attempts it has to apologize for. Trust at the issuer level compounds like interest. So does its opposite.

Top comments (1)

Collapse
 
fintechrailsdigest profile image
Fintech Rails Digest •

The stale state check is the one that bites hardest in practice. A retry queue that runs off a cached subscription snapshot will happily re-present a charge the customer already dealt with by phone, and the issuer reads that as a dispute signal rather than a scheduling bug. Making the pre-attempt refresh mandatory instead of a flag ended up being the change that moved our unexpected-refund counters. The descriptor inheritance point is underrated too: retries burn trust for the whole descriptor, not just their own charges.