For the complete documentation index, see llms.txt. This page is also available as Markdown.

Building a Dunning Recovery Journey

Overview

Most subscription churn isn't a decision — it's a failed payment. A card expires, a charge bounces, and a paying customer quietly lapses through no intent of their own. Dunning recovery turns that silent failure into a one-click fix: a "your payment didn't go through — update it here" flow you link from a billing email, that captures a fresh payment method and settles the outstanding balance so the subscription keeps running.

This guide builds that recovery flow. It's deliberately small and focused — the whole point is to remove every step between a worried customer and a working card.

The example we'll build

Meridian, a media-subscription service, has a customer whose renewal charge just failed. Meridian's billing system emails them a "payment failed" notice with a Fix my payment link. The link opens a short recovery flow: confirm the account, enter a new card, settle the past-due invoice, done — subscription restored, no support ticket.

Before you begin

  • A payment page / hosted page configured so customers can submit a payment method and pay an invoice (hosted pages tie back to the payment gateways in your billing system). Manage these under Payments → Hosted Pages.

  • The recovery flow must open in the right account context (it operates on an existing customer and their outstanding invoice), so it's linked from your billing email or the customer portal, not run anonymously.

A note on what tool to use

Dunning is about collecting a payment, not changing what the customer is subscribed to — so it's built from a payment page (capture method / pay invoice), optionally wrapped in a short Customer Self-Service journey for confirmation and messaging. This is distinct from a subscription-change journey, which amends the plan rather than settling a balance.

1. Build the recovery page

  1. In Content → Pages, create a Payment-type page (or start from a payment template).

  2. Drop in the payment component, which embeds your provider's hosted page so the customer can enter a new card securely. The hosted page must be registered first under Settings → Hosted Pages (reached from your user menu, bottom-left).

  3. The page should clearly show what's being fixed: the failed amount and the subscription it keeps alive — context, not just a card form.

A one-page form works, but a tiny Customer Self-Service journey lets you add confirmation and branching:

Confirm account → Update payment & pay invoice → Confirmation

  • Update payment & pay invoice — the payment step captures the new method and settles the outstanding invoice through the hosted page.

  • Confirmation — "You're all set — your subscription is active" reassurance.

The recovery flow only works if the customer can reach it the moment they're notified:

  • Put the flow's URL in your billing system's payment-failed / dunning email as the primary call to action ("Fix my payment").

  • You can point a branded host straight at the flow — a subdomain mapping to the payment page (or to the journey's entry step) keeps the recovery URL on your own domain. See the custom-domains guide.

4. Branch on the outcome

Not every recovery succeeds on the first try — handle both paths:

  • Payment succeeds → confirmation, subscription restored.

  • Payment still fails (declined again) → branch to a "try a different method" step, or a contact-us / support hand-off so a human can help before the subscription is cancelled for non-payment.

5. Measure recovery

Watch how much revenue the flow saves on the Analytics funnels — recovery links opened → payment updated → invoice settled. A low open rate points at the email; a low completion rate points at the page or the gateway.

Get creative

  • Proactive card-expiry flow. Don't wait for the failure — link the same flow from a "your card expires next month" email to update the method before a charge bounces.

  • Self-serve from the portal. Surface a "payment needs attention" banner in the customer portal that opens the recovery flow, so customers who log in can fix it without the email.

  • Grace-period messaging. Tell the customer how long they have before service is interrupted — urgency recovers more payments than silence.

Tips

  • Keep it to the essentials. Every extra field costs you a recovery. Confirm, collect a card, settle, done.

  • Show the stakes. Name the subscription and amount being fixed so the customer understands what they're protecting.

  • Use a payment page, not a change-plan journey. Dunning settles a balance and updates a method; it doesn't amend the plan.

FAQ

Is dunning a journey or a payment page?

At its core it's a payment page (capture method + pay invoice). Wrapping it in a short Customer Self-Service journey adds confirmation, messaging, and branching for the still-failing case — recommended, but the payment page is the engine.

How do customers reach it?

From the payment-failed email your billing system sends (the primary "Fix my payment" link), and optionally a "payment needs attention" prompt in the customer portal. Put it on a branded host with a subdomain mapping if you want the URL on your own domain.

What if the new card fails too?

Branch to a "try another method" step or a support hand-off, so a human can intervene before the subscription lapses for non-payment.

Last updated

Was this helpful?