Coaching Payment Retry and Dunning: A Clear Workflow
Nour
Founder, Coachful
Coaching payment retry and dunning should resolve a verified billing problem without creating another one. A retry attempts collection again. Dunning coordinates the notices, customer actions and human decisions around an unresolved payment. Neither process establishes that a client is unwilling to pay.
The important distinction is between a failed attempt, an outstanding obligation and the current service arrangement. They can change at different times. A card may be updated while an invoice remains unpaid; payment may succeed while a separately agreed service pause remains appropriate.
Coachful is our #1 recommendation for keeping coaching purchases, client billing records and delivery follow-up together. Use the supported payment processor for its collection and authentication functions, and give exceptions a named owner. This guide develops a complete fictional recovery case, including what happens after the client's first action fails to settle the invoice.
Define the four jobs before adding automation
| Job | What it accomplishes | What it does not prove |
|---|---|---|
| Retry collection | Attempts an eligible payment under the processor's configured policy | That a scheduled attempt executed or succeeded |
| Request a customer action | Routes payment-method correction or authentication to the authorized payer | That saving a card paid an existing invoice |
| Communicate and resolve exceptions | Explains the actual issue, responds to corrections and coordinates follow-up | That an email was read or a dispute resolved |
| Check delivery and access | Confirms the purchased service's actual current entitlement and any authorized change | That all purchase types follow one grace period or cancellation rule |
A useful recovery process has a stop condition for each job. Collection stops when the obligation is settled or appropriately closed. A method-update request stops when that correction is complete. An authentication request stops when the required action succeeds or the payment expires. A manual follow-up closes only after its unresolved question is answered.
That prevents an entire sequence from continuing merely because someone entered it three days ago. It also prevents the opposite error: closing the case as soon as the client says they tried something, before checking whether the actual payment recovered.
Classify the current payment before deciding the next action
Start with the exact customer, invoice, subscription, amount, currency and connected payment account. A client's email address alone is not a reliable way to identify which purchase failed. The same person may have several purchases or be a coach paying their own platform subscription.
| Current situation | Appropriate next check | Action to avoid |
|---|---|---|
| Retryable collection failure | Review the saved collection policy and next eligible attempt | Starting another invoice for the same obligation |
| Payment method needs replacement | Give the payer the relevant secure correction route | Asking for card numbers in a conversation |
| Customer authentication required | Route the actual required confirmation to the payer | Assuming repeated unattended attempts perform authentication |
| Processing or uncertain outcome | Reconcile the existing payment before offering another collection | Calling it definitely failed because a page timed out |
| Amount or service is disputed | Assign review of the specific disputed item | Treating an unchanged reminder as a correction |
| Paid or appropriately closed | Stop the relevant outstanding-payment follow-up and check the service record | Relying on an older failure notification |
Stripe's How Payment Intents and Setup Intents work documentation distinguishes saving payment credentials from collecting funds. It also distinguishes a payment requiring customer action from one still processing. Those states matter operationally: a successful setup is not the same event as a successful payment.
Keep the amount owed separate from why an attempt failed. A bank's decline does not establish the client's financial circumstances or intention. If the invoice itself needs correction, resolve that issue before presenting its existing amount as undisputed.
Understand what retry settings can and cannot do
Stripe's current Automate payment retries documentation describes Smart Retries and custom schedules. Certain failures need intervention: missing payment methods, hard declines and disconnected connected accounts are among the conditions that prevent automatic retry. A scheduled retry counter can increase after a hard decline without another charge executing.
The same documentation explains payment-method priority. A subscription's own default can take precedence over the customer's general default. Updating a different default may leave the failed method in use. Diagnose the specific purchase instead of telling the client that every saved-card change resolves every subscription.
Configure a policy for the actual account and supported method. Do not copy a card-retry cadence onto a bank debit or assume all connected accounts expose the same controls. Record the policy you actually reviewed, the account it belongs to and who may change it. The coach's own Coachful account billing is a separate relationship from a client's purchase.
A retry window and an access window also answer different questions. The processor may still have collection activity planned while a product's access condition has changed. Check both before promising continued access through the final retry date.
Coordinate the notices around one resolution route
Stripe's Automate customer emails documentation distinguishes failed-payment notices, unpaid recurring-invoice reminders and confirmation requests. Its configured hosted recovery page can let a customer update the relevant subscription's payment method and, where applicable, settle outstanding invoices. A method update may instead take effect for a later scheduled attempt, so inspect the result.
Choose who owns each message. A provider can issue the payment-action notice while a practice administrator handles a disputed service period. Do not also run a generic four-message campaign that ignores those actions. A manual check-in can be useful when it answers an actual unresolved question, rather than repeating the provider's payment demand.
Use the agreed payer and administrative contact, with only the billing details they need. Private coaching content does not help a finance team replace its departmental card. If the participant cannot authorize payment, establish a suitable payer route without granting that payer access to the participant's coaching records.
Help recipients verify the request. The FTC's phishing guidance recommends contacting a known business through a website or number independently known to be real when a message is suspicious. Give clients a familiar administrative route and never ask them to send card details, passwords or bank authentication codes to the coach.
Worked example: open one recovery case for one invoice
All people, records, dates, amounts and outcomes below are fictional. Ruth runs a coaching practice. Sam has an existing monthly program membership, billed £600 GBP for 1–31 May. This is a recurring program subscription linked to Ruth's connected Stripe account, not an installment toward a fixed total and not Ruth's own Coachful platform plan.
For this example, £600 is the final amount on the issued invoice. The case does not calculate tax or establish a treatment for another business. Sam is both participant and authorized payer. Ruth has billing permission, and an approved practice billing address is billing@ruthcoaching.example.
On 1 May at 09:00 UTC, the renewal attempt fails. Ruth checks the current processor record and the program enrollment before contacting Sam. Her completed recovery note contains:
Case: MAY-17. Existing invoice MAY-0600, £600 GBP, service period 1–31 May. Sam's existing program subscription and the practice's connected payment account are matched to that invoice.
Current evidence: The invoice is open with £600 outstanding and no successful payment against it. The reported failure requires a replacement payment method. There is no amount dispute, bank transfer or cancellation request on record.
Collection and notices: Provider recovery is configured on this account. Its failed-payment and required-confirmation emails own the secure payment actions. No separate practice marketing or generic reminder sequence is running for this case.
Access: The current enrollment is active with a past-due subscription and a stored access deadline of 4 May, 09:00 UTC. This is the observed record for this purchase, not a promised deadline for every Coachful product.
Owner and next review: Ruth checks at 08:30 UTC on 2 May. If the payment state is uncertain, she reconciles it before authorizing any new collection. An unresolved amount or service issue goes to Ruth for an actual decision.
The recovery note is an original operational record. It is not a claim that Coachful contains a screen named MAY-17 or automatically creates this exact record and cadence. Ruth can keep administrative follow-up in her authorized client workflow while the invoice and processor remain authoritative for the financial facts.
Complete the first action and identify what is still missing
The provider sends its configured failure notification to Sam with the private recovery route for the relevant subscription. Sam contacts Ruth through their existing administrative conversation because he wants to check that the message is authentic.
Ruth verifies the invoice again and sends this completed clarification:
Subject: Confirming the May program payment request
Hello Sam,
I have checked invoice MAY-0600 for your 1–31 May program membership. It currently has £600 GBP outstanding after the 1 May collection attempt.
The Stripe payment-recovery notification for this invoice is the payment route for your existing subscription. Please verify it through our established billing contact if you are unsure before opening it. Do not send me card details or authentication codes.
If the amount or period looks wrong, reply here or use billing@ruthcoaching.example. I handle billing questions and will review this case tomorrow at 08:30 UTC. This message does not create another invoice.
Sam confirms that he has identified the notification. At 17:10 UTC he uses its hosted recovery page to replace the payment method. He then reports, “The new card is saved.” Ruth does not mark the invoice paid on that statement.
At the next morning's review, the current invoice still has £600 outstanding. The replacement method is associated with the intended subscription, but the payment now requires Sam's authentication. Ruth records the difference: the method correction is complete; collection is not complete. The provider's configured confirmation notice supplies the action Sam must perform himself.
Ruth's response says, “The invoice is still open because the payment needs your confirmation. Please complete that step on the provider's payment page. I cannot perform your bank confirmation. If the page fails, tell me the error text without sharing the code.” She sets another review for 12:00 UTC that day, instead of sending an unrelated request to pay a new invoice.
Verify recovery and close every affected follow-up
Sam completes the required action at 10:15 UTC on 2 May. At 10:20 Ruth checks the actual provider record: the existing invoice is paid, £600 GBP was received against it and the remaining balance is zero. The linked subscription is active. She also verifies that the Coachful client billing record reflects the payment and that the program enrollment no longer carries the temporary failure-related access deadline.
The amount, currency and invoice match. There is no second invoice or second payment to reconcile. Sam opens the existing program and confirms access to the expected content. The recovery occurs before the stored 4 May deadline, so this case does not demonstrate a blocked membership being restored after expiry.
A delayed notification of the original failed attempt arrives afterward. Ruth compares its event time with the current paid invoice rather than reopening collection. It documents the earlier failure; it does not reverse the observed later payment.
She closes the two manual review entries: the outstanding-payment question is resolved and the client-access check is complete. Her contemplated 3 May check-in is removed from her administrative follow-up list after that review. No generic day-seven or day-fourteen notice exists to continue blindly. The provider's actual current notification and collection state is checked separately; Ruth does not claim that crossing off her task changed processor settings.
Her final message is concrete:
Subject: May payment confirmed
Hello Sam,
Invoice MAY-0600 is now paid: £600 GBP received for 1–31 May, with no balance remaining on that invoice. Your existing subscription shows active, and we have checked your program access.
I have closed the practice's follow-up for this payment. The earlier failure message concerns the original attempt; please do not make another payment for it. Contact me through our existing billing conversation if you see a conflicting request.
At the final review, Ruth notes what the process actually achieved: one payment recovered, the first customer action correctly distinguished from settlement, no replacement invoice created and the client's access confirmed. It does not demonstrate that every failed payment can be recovered or that reminders caused Sam's payment.
Contrast an unresolved invoice question with a decline
In a separate fictional case, Alex's employer receives a £900 invoice but says its service period is incorrect. Alex is the participant; finance officer Priya is the agreed payer contact. Sending Alex another card-update request cannot resolve Priya's question.
The billing owner checks the agreement and finds that the invoice includes a month outside the authorized service period. They route the correction through the authoritative invoicing process and confirm the corrected amount and document reference with Priya before asking for payment. The original demand is not simply allowed to continue alongside a replacement.
The exact correction and treatment of the original document depend on the invoicing system and applicable requirements. Do not silently edit an issued record, label a write-off as cash recovered or claim a cancellation erases money still owed. Obtain qualified help for a substantive billing dispute, collection rights or required legal notices.
This contrast explains why a recovery system needs an exception owner. Automation can notice that an invoice is unpaid; it cannot establish that its amount is correct or that a participant has authority to fix the employer's payment arrangement.
Set up the Coachful workflow around the correct purchase
- Open the relevant client record. In Clients, select the joined client and open Billing. Simple Mode may require More options to reveal Billing. Invoices & payments shows invoice status and history; Recurring payments identifies the continuing arrangement where applicable.
- Match the financial authority. Confirm the actual connected account, invoice and subscription before using processor recovery settings. Account menu > Plan & billing concerns the coach's own plan and is not the client's retainer.
- Review the actual resolution path. Use the supported customer-facing payment or confirmation route for that purchase. A resource's subscription-blocked page can offer Update payment for its eligible signed-in member; that does not authorize an unrelated corporate payer to manage the participant's account.
- Coordinate the channels. Record which provider notices are enabled and which administrative follow-ups a person owns. Do not claim that a generic Coachful task automatically suppresses all payment emails or provider retries.
- Assign exception reviews. Give missing context, invoice corrections and uncertain transactions an owner and a time to check. A completed review task is evidence of work performed, not a payment receipt.
- Check current delivery. Inspect the actual enrollment or entitlement after a relevant change. Then confirm what the client can use, what remains unresolved and whether any separately agreed pause remains.
Recurring programs, finite payment plans, Offers and coach-started recurring payments can have different lifecycle rules. In particular, a coach-started program arrangement using Keep access does not make the program's access depend on that subscription. Do not apply Sam's observed failure deadline to it.
The billing, invoices and receipts guide covers document authority. Our subscription renewals guide covers the decision to continue a service. Use this recovery guide for the different question of what to do after an attempted payment needs attention. Explore Coachful's billing and client-management features for the surrounding workflow.
Check usability and failure paths before relying on the process
Use supported test environments or authorized noncharging checks. A preview of an email does not prove its recipient can open the payment page. Inspect the intended purchase, account scope, sign-in requirements, expiry behavior and help route. Never use a real client's card as a casual test of recovery settings.
Test the difference between a visible input error and a transaction outcome. W3C's error-identification guidance explains that automatically detected input errors should identify the item and describe the error in text. A red border alone is insufficient. That guidance does not certify any particular payment page's accessibility.
For a practical check, confirm that someone can identify the amount and period, reach the appropriate action, understand a failed submission and contact the billing owner without sharing payment credentials. If the route fails, retain the specific failure and ask the appropriate provider or product support for help. A coach should not invent a workaround that asks the payer to expose card information.
Measure a defined recovery cohort
In another original illustrative reporting example, six initially failed invoices total £5,000 GBP. At the stated fourteen-day cutoff, three are fully paid: £600, £900 and £1,500, totaling £3,000. The other three remain wholly unpaid at £400, £700 and £900, totaling £2,000. No credits, partial receipts, refunds or disputed amounts are hidden in those totals.
Full-invoice recovery by count: 3 ÷ 6 = 50%. Gross recovery by value: £3,000 ÷ £5,000 = 60%. Count asks how many invoices recovered; value asks how much of the original failed amount was collected. Neither is a benchmark or forecast for a coaching practice.
State the cohort's entry dates, cutoff and currency. Do not divide recoveries from old invoices by unrelated failures that began this week. If partial receipts occur, report their value separately and define whether the count metric requires full payment. Keep collected amounts distinct from fees, later refunds, credits, write-offs and the invoice balance.
Troubleshoot before sending another request
The card changed but the invoice is open. Check the intended subscription's payment method, any required confirmation and the actual invoice outcome. Do not assume that a new saved method settles earlier amounts.
An earlier failure arrived after payment. Reconcile the current account and invoice state. Keep the earlier event as history rather than sending another demand because it arrived last.
The customer says a bank payment is pending. Check the existing payment and available references before offering another checkout. An uncertain transaction needs reconciliation, not a second simultaneous collection.
Payment and access disagree. Inspect the actual purchase type, current enrollment and separate service decisions. Escalate an unexplained mismatch; do not promise a universal restore rule or remove a deliberate client pause.
Frequently asked questions
How often should coaching payments retry?
Use the actual processor's eligible method, saved policy and customer context. There is no universal coaching schedule. Coordinate its collection window with the actual service terms and access behavior.
Does updating a card mean the invoice is paid?
No. Verify the existing invoice's balance and payment result. The method update, required authentication and collection may be separate steps.
Can every failure email trigger an access suspension?
No. It may describe an older attempt, and purchase lifecycles differ. Check the current payment and entitlement before explaining a specific service effect.
Should billing notices include coaching progress?
Include only what the authorized payer needs to understand and resolve billing. Private coaching discussion is not required to identify an invoice or correct a payment route.
Will dunning recover a predictable percentage?
No recovery rate is guaranteed. Report your own defined cohort and outcomes, including unresolved exceptions and any later adjustments.
