Payment Recovery
Failed payments are recoverable revenue — if you work them. Payment Recovery is Floatless's dunning workbench: it finds overdue invoices, plans the right action for each (retry the card, warn the customer, or suspend service), shows you the plan before anything runs, and then executes it.
Open it at Payments → Payment Recovery.
When should I read this?
- Cards failed overnight and the queue is growing.
- You want to change how aggressively Floatless retries or warns.
- You are about to suspend accounts and want to see exactly who is affected first.
Use cases
| Scenario | What you do |
|---|---|
| First recovery pass of the week | Open the page — a preview loads automatically. Review, then Execute recovery. |
| A customer's card expires every quarter | Their invoices land in the retry lane; after the retry succeeds, everything else heals automatically. |
| You want a gentler tone for long-time customers | Adjust warning email days to fire before retries and suspensions. |
The recovery policy
The right-hand card configures the dunning engine:
| Setting | Default | Meaning |
|---|---|---|
| Retry days | 3 |
Days after failure on which payment is retried (e.g. 3, 5 retries on day 3 and day 5). |
| Warning email days | 7 |
Days on which a warning email is sent (can escalate to SMS). |
| Suspension day | 14 |
At this overdue day or later, active subscriptions are suspended. |
| Toggle switches | All on | Retry failed payments / Send warning emails / Suspend subscriptions / Disable user access. SMS is off by default. |
Preview before execution
Click Preview queue (or just open the page) and Floatless plans the actions without touching anything:
- Summary cards: Overdue invoices, Retry candidates, Warnings, Suspensions.
- The queue table lists every overdue invoice with days overdue, the planned action, status, and a message. Tabs split the lanes: All / Retries / Warnings / Suspensions / No action.
Planned actions:
| Action | Fires when | Effect |
|---|---|---|
| Payment retry | Days overdue matches a retry day | The saved payment method is charged again. |
| Warning email | Days overdue matches a warning day | The customer gets a "fix your payment method" nudge. |
| Service suspension | Days overdue ≥ suspension day | The subscription is paused (and optionally the user login disabled). |
| No action | Between policy stages | Wait — the next stage hasn't arrived. |
Execute
Execute recovery opens a confirmation with the counts: how many retries, warnings, and suspensions will run, plus the reminder that completed actions are persisted and may affect customer access. Confirm to run for real — charges are attempted, emails are queued, suspensions are applied.
The customer side of a failure
When a checkout or charge fails, customers land on a friendly failure page that explains the usual causes (insufficient funds, bank decline, cancelled checkout, network) and offers Retry Payment and Contact Support. The failure is recorded against the invoice automatically.
How this feeds reporting
Every recovered invoice improves the Failed payment recovery panel in Revenue intelligence — failed invoices, recovered count, and recovery rate — so you can measure whether your policy actually works.
Common issues
- Retries all failed. Usually an expired card. The warning email includes a secure payment-update link (valid 24 hours) so the customer can fix it themselves.
- A customer was suspended by mistake. Resume the subscription from its detail page and re-run nothing — suspension only happens at/after the configured day.
- Preview keeps showing the same actions. Planned actions persist until executed or the policy window passes; execute or adjust the policy.