Connect Stripe
Authorize via OAuth and we handle the rest. Recoupt reads your failed-payment events — nothing else — so your Stripe data stays private.
← Recoupt
Recoupt feature
Smart Stripe retry logic for failed payments — by failure reason
Smart retries are automated payment recovery attempts scheduled by failure reason, not by a fixed interval. Recoupt reads the Stripe failure code and applies the retry schedule most likely to succeed — insufficient funds waits for payday, expired cards skip retries and go straight to dunning. Most recouped payments resolve within 10 days.
Every failure reason is a different problem. Recoupt treats them that way. An insufficient-funds decline waits for the next payroll cycle; a transient processing error retries fast; an expired card skips retries entirely and goes straight to dunning.
How it works
Recoup revenue on autopilot
One-click Stripe connection. No code changes, no SDK, no webhook setup. Recoupt connects to your existing account in under 5 minutes.
We detect and recoup
When a payment fails, Recoupt identifies the failure reason and schedules retries with optimal timing. If retries don’t work, branded dunning emails guide customers to update their payment method.
Watch revenue return
Your dashboard shows revenue at risk, recouped, and lost in real time. See every failed payment, every retry attempt, every email sent.
The schedule
Different failures need different schedules.
Three failure codes, three retry shapes. Read across the timeline:
Retry schedule by failure_code
retry
dunning email
D0
D4
D8
D14
card_declined
expired_card
insufficient_funds
Smart retry timing
Every failure reason gets a different schedule. Because a declined card and an expired card are completely different problems.
Failure reason Retry schedule Why
card_declined 24h, 72h, 7 days Gives time for temporary holds to clear
insufficient_funds 48h, 5 days, 10 days Aligned with payroll deposit cycles
processing_error 4h, 24h, 72h Often transient — retry fast
expired_card Dunning email Retrying won’t help; customer needs to update
authentication_required Dunning email Customer action required (3D Secure, etc.)
When retries don’t work, dunning emails take over . See the full Stripe failure codes reference for every code and the optimal recovery strategy.
Why do fixed-schedule retries leave money on the table?
Stripe’s built-in Smart Retries fires on a uniform schedule regardless of why the
payment failed. That’s reasonable for transient declines, but it’s wrong
for the two failure modes that drive most involuntary churn:
insufficient_funds needs a payroll-cycle
delay, and expired_card needs a customer
action no retry can produce. Retrying an expired card three times across seven days is
a free way to burn three Stripe failure events and lose the subscription.
Walk through one example. A customer’s card declines for
card_declined — usually a temporary
hold from their bank that clears within a day or two. Recoupt retries at 24 hours,
72 hours, then 7 days: tight enough to catch the unlock window, spaced enough that the
third retry happens after the bank has rotated through a full cycle. A
one-size-fits-all retry at 4 hours / 1 day / 3 days catches the easy cases but misses
the ones where the bank takes its time.
A second example. insufficient_funds
declines almost always resolve on the customer’s next payroll deposit, and US
payrolls land biweekly — meaning a deposit reaches the account within 14 days.
Recoupt retries at 48 hours, 5 days, 10 days, sweeping the full payroll window. A
retry at 4 hours and 1 day on the same failure misses the deposit by two weeks. Same
number of retries; entirely different recoupment rate.
Watch every retry in real time
on the recoupment dashboard.
The 65% recovery estimate, explained
Recurly’s published research on subscription billing finds that merchants who deploy smart retries together with a dunning email sequence typically see involuntary churn drop from a baseline of around 6% per month to around 1% per month. That’s an ~83% reduction in monthly involuntary-churn loss, sustained over a representative merchant cohort. The math works out cleanly: if 6% of MRR was being lost to failed payments and 1% remains lost after smart retries + dunning, you’ve recovered five out of six dollars that would have walked.
Recoupt’s public claim of ~65% recovery is intentionally
conservative against that 83% benchmark. Your actual rate depends on your customer
base, failure mix, and how much you customize the dunning copy. A 65% estimate gives a
15-point cushion for newer setups, smaller cohorts where statistical noise dominates,
and merchants whose failures skew toward harder-to-recoup categories (e.g. heavy
expired_card mix in long-tenure
subscribers). Above that floor, gains are upside.
Smart retry FAQs
Why do fixed-schedule retries leave money on the table?
Fixed-schedule retries treat every failure the same way, but each failure code is a different problem. An insufficient_funds decline resolves after the customer’s next paycheck; an expired card requires the customer to update their payment method and retrying it will never succeed. Stripe’s built-in retries apply the same interval to both, burning retry attempts on failures that need a different approach.
When does Recoupt retry an insufficient_funds payment?
Recoupt retries insufficient_funds payments at 48 hours, 5 days, and 10 days — aligned with US payroll deposit cycles, which run biweekly. This schedule covers the full payroll window, giving each retry the best chance of catching a fresh deposit.
What happens when a card fails for expired_card or authentication_required?
When a payment fails for expired_card or authentication_required, Recoupt skips retries entirely and routes it directly to the dunning email sequence. Retrying an expired card cannot succeed — only the customer can update it. Sending an email immediately is faster and more likely to recoup the payment than waiting for failed retries.
How long does it take to recoup a failed Stripe payment?
Most failed payments recoup within 1 to 10 days depending on the failure reason. A card_declined failure retries at 24 hours, 72 hours, and 7 days. An insufficient_funds failure retries at 48 hours, 5 days, and 10 days to align with payroll cycles. Expired cards skip retries and go straight to the dunning email sequence, where recoupment depends on how quickly the customer updates their card.
Does Stripe have smart retries built in?
Stripe has a built-in Smart Retries feature, but it applies the same retry schedule to every failure regardless of the reason. Recoupt reads the Stripe failure code and applies a different retry schedule for each type: insufficient_funds waits for the next payroll deposit, expired_card skips retries entirely, and processing_error retries fast. Failure-reason-based scheduling recovers more revenue than a fixed schedule.
What is the most common reason Stripe payments fail?
The most common Stripe failure reasons for subscription payments are card_declined (temporary bank holds), insufficient_funds (balance too low at billing time), and expired_card (card number or expiry changed). Each requires a different recovery approach: card_declined and insufficient_funds benefit from timed retries, while expired_card requires a dunning email since no retry will ever succeed.
Stop the leak. Recoup the revenue.
Smart retries go live the moment you connect Stripe. The first failure that hits your account triggers the schedule above — no code, no config.