> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/guides/feature-guides/retain-and-manage/guide-dunning-recovery-journey.md). # 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. ### 2. Wrap it in a short recovery journey (optional but recommended) 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. ### 3. Link it from the billing email 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/guides/feature-guides/retain-and-manage/guide-dunning-recovery-journey.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.