Retrying declines too fast looks like fraud, not persistence

Soft decline (code 51, insufficient funds) came back on a subscription renewal. Retry logic fired again in 90 seconds because that was the default backoff someone copied from a Stripe blog post years ago. Renewal failed again, and the issuer's risk engine started tagging the card for velocity — three attempts inside five minutes on the same card, same amount, from the same merchant ID reads like a testing pattern to most fraud models, not a legitimate retry.

Pulled six months of retry logs across a billing system: recovery rate on soft declines barely changed between a 4-hour wait and a 24-hour wait. What did change was the false-positive velocity flag rate, which dropped by more than half once retries were spaced past 6 hours. Insufficient funds resolves on payday or when a balance clears, not in the next few minutes, so hammering the network faster buys nothing except a worse risk score on the card.

Ended up mapping backoff intervals to decline code instead of using one universal retry schedule — do-not-honor gets a different curve than insufficient-funds, and both get capped at three attempts before falling back to dunning email.

Curious what intervals other teams landed on for soft-decline retries, and whether anyone has actual conversion data broken out by decline code rather than a flat retry count.