FAQ

How Recoverr works

Recovery mechanics, decline classification, and the retry timeline — the questions prospects ask most.

How does Recoverr recover failed Stripe payments?
When a Stripe charge fails, Recoverr ingests the charge.failed webhook, classifies the decline into a named retry strategy, and queues the charge for a scheduled retry via next_retry_at. A background retry job picks each charge up at the offset dictated by its strategy and re-attempts the charge through Stripe. Outcomes — success, last error, exhaustion — are recorded on the charge row so the dashboard and daily digest stay in sync.
How are Stripe decline reasons classified into retry strategies?
Every Stripe decline code is mapped through the DECLINE_TO_STRATEGY table to one of six named strategies. The classifier picks the strategy in real time, and the strategy (not the raw decline code) dictates whether and how to retry. The six strategies are:
  • Insufficient Funds — bank declined for balance; recoverable.
  • Processing Error (transient issuer) — try_again_later, issuer_not_available; recoverable.
  • Expired Card — renewal needed from the customer; not retried.
  • Generic Card Declined — issuer rejected without a recoverable cause; not retried.
  • Fraud / Do Not Honor — stolen, lost, fraudulent, restricted; not retried.
  • Generic Decline — unclassified fallback; treated like Insufficient Funds.
What does the retry timeline look like for recoverable failures?
Each retryable strategy declares its own offset schedule and a cap of 3 retries per charge. Recoverr retries recoverable charges on these timelines:
  • Insufficient Funds / Generic Decline: 1h → 24h → 72h.
  • Processing Error (issuer transient / try_again_later): 1h → 4h → 24h — tighter cadence because the issuer's outage usually clears fast.
Each retry records its outcome on the charge and bumps retry_count; once retry_count reaches the strategy's max, no further retries are scheduled.
Which decline types should never be retried?
Three strategies short-circuit straight to dunning without any retry attempt: Expired Card, Generic Card Declined (including lost/stolen card), and Fraud / Do Not Honor. Each declares maxRetries: 0 with empty offsetsHours, and they carry dunningTier of firm or aggressive. Retrying these would burn customer relationships and rack up Stripe fees on charges that cannot succeed — Recoverr identifies them immediately and stops.
What happens once a retry succeeds or all retries are exhausted?
Two terminal paths, both visible in the dashboard and the daily digest:
  • Recovered: a subsequent charge.succeeded webhook marks the failed_charges row as recovered, clears next_retry_at, and fires a recovery notification.
  • Exhausted: once retry_count reaches the strategy's maxRetries, next_retry_at is cleared and no further retries are scheduled. The charge stays in the dashboard as exhausted so you can follow up manually or write it off.