Skip to main content
Gruv.ai logo
Payment Recovery

Recover failed payments with a real playbook

A renewal fails. Gruv retries at the right time, emails the subscriber with a one-click card-update link, and tracks whether the charge recovers or becomes churn.

Retry policiesGrace periodsRecovery visibility
Dunning · M1 cohort
Recovered 62.4%
Lost 7.1%
Day 1
Retry 1
card declined
Day 3
Card update sent
email opened
Day 5
Retry 2
insufficient funds
Day 7
Updater hit
new card · +$49
Day 8
Recovered
active · billed
At risk
$128,400
Recovered
$80,196
Remaining window
14 days

How it works

Where failed-payment recovery falls apart

Retrying at the wrong time wastes attempts

An "insufficient funds" decline may justify a later retry. An expired card usually needs a customer update instead. One retry schedule for both wastes attempts.

Subscribers often get an unhelpful notification

The email says "your payment failed." No card-update link. No explanation. The subscriber ignores it and churns three weeks later.

Nobody knows who is in grace and who is about to churn

Support checks one system. Billing checks another. Is this subscriber in retry, in grace, or already cancelled? Three people, three answers.

You cannot measure what you cannot see

Which retry cadence recovers the most revenue? Which failure reason has the lowest recovery rate? Without analytics, you are guessing.

Dunning around retry, action, and visibility

Failed charges trigger the right retry at the right time, notify the subscriber with a card-update link, and track recovery vs. churn for your growth team.

  • Retry schedules per failure reason

    Insufficient funds retries after payday. Expired cards skip retry and send an update prompt. You configure the timing per decline code.

  • Grace periods with escalation

    The subscriber keeps access for 7 days while retries run. After grace expires, the subscription moves to the state you configured: pause, downgrade, or cancel.

  • Actionable subscriber notifications

    Each email explains what failed and includes a one-click card-update link. No vague "payment failed" messages.

Dunning around retry, action, and **visibility**
Capabilities

What recovery teams need

Smart retry schedules

Retry after payday for insufficient funds. Skip retry for expired cards. Timing adapts per decline code.

Grace periods

7-day or 14-day grace with continued access. Escalation to pause or cancel after expiry.

Subscriber notifications

Clear emails with one-click card-update links. Sent at the right cadence, not a single generic blast.

Recovery analytics

Recovery rate by failure reason, method, plan, and cohort. See exactly where involuntary churn originates.

Lifecycle sync

Billing, support, and your CRM show the same recovery status throughout dunning.

How it works

From failed charge to recovered or churned

Frequently Asked Questions

How many retry attempts should we configure?+
It depends on the decline code. Insufficient funds may recover after 2-3 retries. Expired cards need a subscriber update, not more retries. Gruv lets you set the max per decline type.
What happens after all retries fail?+
Your policy decides. Move to grace, pause the subscription, offer a lighter plan, or cancel. You configure the escalation path per plan and segment.
Can subscribers update their card during dunning?+
Yes. Every notification includes a one-click link to a hosted card-update page. Gruv re-attempts the charge the moment the subscriber updates.
How do we know if our dunning is working?+
Track recovery rate by decline reason, payment method, retry attempt number, and subscriber segment. See whether each retry actually recovers revenue or just delays churn.

Next step

See where Gruv fits

Tell us what you are trying to do, where it needs to work, and how your team handles it today.

Contact the team