Failures, followed up.
Spend alerts reach customers before the invoice surprises them. Failed charges get a diagnosis — insufficient funds, expired card, bank block — and a recovery plan to match, not a blind retry loop.
Updated August 2026Recovery that reads the reason, not just retries.
Three steps. No engineering ticket.
The decline reason — insufficient funds, expired card, bank block — is captured immediately, not guessed at.
Each failure type gets its own retry timing and message; expired cards skip retries for an update-method email instead.
On autopilot or approve-first, the agent executes the playbook and logs the outcome — no chasing email required.
Recovery matched to the reason, not a fixed schedule.
A fixed retry schedule treats every failed charge the same way, regardless of why it failed — which is exactly why it recovers less. Kribana captures the decline reason the moment a charge fails and picks a playbook to match it: insufficient funds gets a retry timed around a likely payday, a bank block gets a different cadence, and an expired card skips retries entirely in favor of an immediate update-payment-method email, since retrying a dead card just burns attempts and annoys the customer.
How much of this runs unattended is a choice, not a default. Every playbook can run in autopilot, approve-first, or alert-only mode, set independently — teams typically start on the more cautious modes for their riskier playbooks and move to autopilot once the pattern proves out, rather than handing over full control on day one.
Recovery isn't only reactive. Spend alerts reach a customer before their invoice does, when usage is trending toward a number that's going to surprise them — catching the moment before it becomes a failed charge or an angry support ticket, not just cleaning up after one.
Every action the agent takes — what signal triggered it, what was actually sent to the customer, and what it recovered — lands in an audit log. That's what makes the recovery rate a number you can verify rather than take on faith: you can see exactly which decline, on which account, led to which action.
“The recovery rate almost doubled without us writing a line of dunning logic ourselves.”
FAQ
How is this different from a normal fixed retry schedule?
A fixed schedule retries every failed charge the same way regardless of cause. Kribana captures the decline reason first and matches it to a playbook with its own timing and message — an expired card, for instance, skips retries entirely for an immediate update-method email instead of repeatedly hitting a card that's guaranteed to fail again.
Can I review what the agent does before it acts?
Yes — every playbook can run in autopilot, approve-first, or alert-only mode, set independently per playbook. Teams commonly start conservative on riskier playbooks and move to autopilot once they've seen the pattern hold.
Which decline reasons get handled differently?
Insufficient funds, expired cards and bank blocks each get their own timing and message rather than a one-size retry. Expired cards in particular skip retries altogether in favor of an immediate update-payment-method email, since retrying a dead card recovers nothing.
Do I get visibility into what recovery actions were taken?
Yes — every action lands in an audit log showing what signal triggered it, what was actually sent to the customer, and what it recovered, so the recovery rate is something you can verify rather than take on faith.
Does recovery only act after a payment fails, or also before?
Both. Spend alerts reach customers before an invoice surprises them, when usage is trending toward a number they haven't budgeted for — catching the moment proactively, not just cleaning up after a decline.