Recovery
Managing failed payments, reading sequences, and what each dashboard number means.
Managing payments
Reading the payments list
The list at /recovery/payments holds every failed payment Foxhound has detected, newest first. A row carries the customer name and email, the amount, the decline category, the current status, and when the failure was detected. Open any row for that payment's own page.
Filtering and search
- Search. Matches on customer name, email, or plan name.
- Status. Stripe retrying, active, recovered, cancelled, or failed unrecovered.
- Decline category. Narrows to one category.
- Date range. Filters on when the failure was detected.
- Amount range. A slider bounded by the smallest and largest amounts you actually have.
- Sort. Newest first, oldest first, or by amount.
Every filter is a URL parameter, so a filtered view can be bookmarked or sent to somebody else and it opens the same way for them.
Rows per page
The selector above the table shows 10, 25, 50, 100, or all of them. It starts at 50.
What each status means
- Stripe retrying. Stripe is still attempting the payment on its own schedule. Foxhound is watching and has planned no steps yet.
- Active. The sequence is running and at least one step is still ahead of it.
- Recovered. The invoice was paid, and every remaining step was cancelled.
- Cancelled. You stopped the sequence, or the subscription behind it ended.
- Failed unrecovered. Every step ran and the payment did not come back. Nothing further happens on its own.
Reading a payment page
A payment's own page carries its whole timeline, from detection to the most recent step. Each step shows what kind it is, when it was scheduled, when it ran, and what came back: an email step shows the subject and the body that was sent, and a retry step shows what Stripe answered.
Opens and clicks are recorded per email step, so you can see whether a message was read and whether the card-update link was followed. The click is the one that matters for billing.
Acting on a payment by hand
- Trigger now. Runs the next pending step immediately instead of waiting for its scheduled time.
- Mark recovered. Closes the payment and cancels the rest of the sequence. Use it when the customer paid some other way, which Foxhound has no way to see.
- Cancel sequence. Stops every future step for that payment.
- Resend. Sends a completed email step again and records it as its own step.
- Note. A field for your own reference. It is never sent to the customer.
Bulk actions
Select rows with the checkboxes and a bar appears at the bottom of the screen. Trigger, mark recovered, or cancel every selected payment at once. There is a ceiling on how many one submission can carry, and the bar tells you what it is.
Exporting to CSV
Export CSV in the list header downloads the payments matching whatever filters you have on, so the export is the view you are looking at rather than the whole table.
Recovery sequences
Silent retries first
When a retryable payment fails, Foxhound attempts a quiet retry before any customer ever sees an email. If the quiet retry works, the customer is never bothered.
Only after the silent retry window closes does the first dunning email go out, and it carries a hosted card-update link.
How sequences are built by decline type
Declines are sorted into six categories: soft, network, expired, fraud, revoked, and unknown. Each gets its own schedule, spread across thirty days, chosen by what is actually wrong with the payment.
| Category | What it means | How it is worked |
|---|---|---|
| Soft | A temporary decline, often insufficient funds | Silent retries and emails together, the longest sequence of the six |
| Network | A processor or bank problem, usually passing | An early silent retry catches most of these before any email is needed |
| Expired | The card is past its expiry date | Emails only. A retry on an expired card fails every time until the customer updates it |
| Fraud | The issuer blocked the charge | Emails only. Retrying a blocked card can draw further flags |
| Revoked | The customer withdrew the mandate | A single email. There is nothing to retry against |
| Unknown | A decline code the engine does not recognise | Emails only, failing closed: no silent retry against a code that has not been classified |
The schedule for each category
Each category's steps in order, from the engine's own schedule table. A retry is amber and an email is not, so the shape of a category is readable at a glance: soft and network open with a quiet retry, and the other four never retry at all.
Reading the sequences page
The page at /recovery/sequences reads across your whole recovery history by category. For each step it shows how many went out, the open rate, the click rate and the most recent subject line used. A retry step shows how often the retry worked instead.
How recovery emails are written
Every email is written at send time. The AI is given the customer's first name, the plan, the amount, how long they have been a customer, the decline category, where the message sits in the sequence, your brand voice, and your merchant context when you have set it.
What comes back is checked before it goes anywhere: an email carrying hollow phrasing, hedging, or anything that reads like a billing system wrote it is rejected and the template goes instead. Delivery is never held up by the AI layer.
Understanding your dashboard
Stat cards
Nine cards sit across the top of the recovery dashboard. The range buttons in the header move them together.
| Card | What it shows |
|---|---|
| Recovered | What came back in the selected range. |
| Currently at risk | The total across every payment still in an active sequence. |
| Recovery rate | The share of closed payments that came back. |
| Active sequences | How many payments are being worked right now. |
| Win-backs active | How many cancelled customers are in a win-back sequence. |
| Cards expiring | Cards inside the alert window. |
| Avg. days to recover | How long a recovery takes, on average. |
| Best decline category | Which category is recovering best for you. |
| Emails sent | Recovery emails sent in the selected range. |
Date range
The range buttons in the header change the window every card and chart reads from.
Webhook health
The dashboard shows whether Stripe is still reaching Foxhound. A webhook inside the last day reads as receiving normally, nothing for a day reads as quiet, and nothing for more than three days is flagged as a problem worth checking. A brand new connection that has not seen one yet says so rather than reading as a failure.
What counts as billable
A recovery is billable only when a Foxhound action provably preceded payment: a scheduled retry succeeded, a dunning email was clicked or otherwise engaged (not just opened), or a card was updated through a Foxhound page. Everything else is Stripe's own baseline recovery, recorded and shown to you, never billed.
A click only counts if it came within 14 days before the payment came back. A customer who clicks and then pays two months later was not brought back by that email, so the recovery records as Stripe's own baseline and is free.
Troubleshooting
A payment is not showing up
- Is the Stripe account still connected? Settings and Stripe connections lists every live connection on this account.
- Has Stripe finished its own retries? The payment appears as soon as it fails, marked as Stripe's to retry. Foxhound's sequence starts when Stripe stops.
- Is the payment on the account you are looking at? If you hold more than one, check the account switcher in the header.
- Is Stripe still reaching Foxhound? The webhook health line on the dashboard says so.
An email is not going out
- Is the address suppressed? A customer who unsubscribed, hard bounced, or reported an email as spam is suppressed, and Foxhound will not send to them again.
- Is the step actually due? The timeline on the payment page shows when each step is scheduled.
The recovery rate looks low
- How many closed payments are behind it? A rate over a handful of payments moves on every one of them. Give it a billing cycle.
- What is the decline mix? Fraud and revoked recover less by nature. The decline breakdown on the dashboard shows yours.
- Are the emails being opened? Low open rates on the sequences page point at deliverability rather than at the copy.
- Is the brand voice set? Copy written without one is more generic than copy written with one.
A customer says the email never arrived
- Check the timeline on the payment page and confirm the step ran rather than sitting pending.
- Check whether the address is suppressed.
- Ask them to look in spam.
- Use Resend on the completed step to send it again.