Subscription Failed-Payment Recovery: Recharge Dunning and Klaviyo Messaging
Coordinate Recharge retry logic with Klaviyo email and SMS so payment failures recover cleanly, successful charges exit immediately, and support can see the real account state.
- Separate retry orchestration from customer messaging
- Build state-based recovery exits
- Measure recovered contribution instead of clicks
What owns subscription payment recovery?
The subscription platform and payment processor own charge state and retry execution. Klaviyo owns customer communication only when you deliberately assign it that role. Do not create a second retry schedule in marketing automation or imply that a payment has succeeded before the authoritative charge event says so.
Recharge documents automatic retry behavior and optional Failed Payment Recovery strategies. The exact retry schedule, notification ownership, error types, and event payload depend on the account. Record those settings before writing a single message.
What states should the recovery system distinguish?
Distinguish a recoverable payment failure, a retry in progress, a customer-action-required state, a recovered charge, and a terminal cancellation. Each state needs one owner and one next action so platform retries and marketing messages do not conflict.
Payment-recovery state model
| Criteria | Customer message | System action | Exit |
|---|---|---|---|
| First payment failure | State what needs attention and link to a secure update path | Recharge follows the configured retry strategy | Successful charge, cancellation, or terminal failure |
| Retry pending | Remind only when a new action or deadline exists | Wait for authoritative retry timing | Next charge result |
| Payment method updated | Confirm the update only if the platform confirms it | Allow the provider to retry under its rules | Successful or failed charge |
| Recovered | Confirm service continuity when useful | Stop every recovery message | Successful collected charge |
| Terminal or cancelled | Explain final state and support path | Stop retry-specific promotion | Closed subscription or resolved support case |
Use current state, not message count, to decide what sends next.
Export visual
How do you map Recharge events into Klaviyo?
Create controlled test subscriptions and trigger each event the account will use. Inspect the Klaviyo profile activity feed and record metric name, integration version, charge ID, subscription ID, error, retry date, amount, currency, product, status, and secure management URL. A metric may not appear until it has fired at least once.
Build from authoritative state
- 01InventoryRecord provider retry and notification settings
Know who retries, when, how many times, and which native messages already send.
- 02EventsTrigger every relevant test state
Inspect real profile events and payloads; never copy event names from an old screenshot.
- 03OwnershipChoose one sender per notification job
Disable or retain provider messages deliberately so Recharge and Klaviyo cannot duplicate them.
- 04LogicBuild filters and exits around charge state
Successful charge, cancellation, and terminal resolution stop recovery immediately.
- 05QARun real failures and recoveries
Test secure links, retries, state latency, channel consent, support suppression, and reporting.
The provider is the source of truth for money movement; Klaviyo reacts to that truth.
Export visual
What should the messages say?
Be specific without exposing sensitive payment details. Identify the brand and subscription, state that the recent payment could not be completed, explain the consequence and next known retry when authoritative, and link to the secure provider-hosted update path. Do not collect card data by reply, form field, or ordinary landing page.
Email can carry context and support detail. SMS should be reserved for consented recipients when immediacy justifies cost and interruption. Both channels must stop when the charge succeeds or the subscription closes.
How do you prevent duplicate and stale recovery messages?
Maintain a notification inventory with state, owner, channel, timing, source event, and exit. If Recharge sends a native card-declined notice, the equivalent Klaviyo touch must either be disabled or assigned a different job. Before each later message, check current authoritative state rather than relying only on the original trigger.
Should another recovery message send?
Suppress queued reminders and return the profile to the correct active-subscriber lifecycle.
Do not mix payment recovery with cancellation winback.
Use the authoritative retry date and secure update link.
Route to support or engineering and withhold state-specific claims.
A stale reminder after successful payment destroys trust faster than a carefully timed message can recover it.
Export visual
How do you QA subscription dunning?
Trigger every documented failure state in a test environment, verify retry timing and customer links, and confirm recovery or cancellation exits all remaining messages. Reconcile Recharge, payment-provider, storefront, and messaging events before trusting the dashboard.
Failed-payment recovery QA
- Provider retry settings and native notifications are documented
- Every required metric has fired on a controlled test profile
- Event fields and data types are recorded
- Recharge and Klaviyo have one owner per message job
- Secure payment-update links work for each portal state
- No template exposes full payment credentials or requests them by reply
- Successful charge exits all queued recovery messages
- Cancellation and terminal failure exit the active recovery path
- Multi-subscription customers receive the correct subscription context
- Email and SMS consent are evaluated independently
- Quiet hours and account-wide message pressure are applied
- Support cases can suppress inappropriate automation
- State latency and out-of-order events have a safe fallback
- Reporting reconciles recovered charges to provider records
Test failure, update, successful retry, repeated failure, cancellation, and ambiguous-state paths—not only the happy path.
Export visual
What should payment-recovery reporting measure?
Track failed charges, customers entering recovery, attempted retries, payment-method updates, recovered charges, recovered revenue, time to recovery, terminal failures, cancellations, support contacts, incentive cost, and later refunds. Reconcile recovery to provider transaction records; email clicks are diagnostic, not the financial result.
Recovered contribution
collected recovered revenue − COGS − fulfillment − recovery incentives − service cost − expected refunds- A provider record confirms collection
- The evaluation window is fixed
- Later refunds and cancellations are included
- Messages receive attribution only under the documented model
Recovered charges matter only when the business collects durable contribution.
Export visual
The ZHS operating standard is state before sequence: Recharge owns the payment truth, Klaviyo communicates only from verified state, and every success or closure stops recovery immediately.
Need help implementing this?
We build and manage complete email & SMS programs for DTC brands. Get a custom plan for your brand.
Apply Now