How failed payments work on Paddle Billing, and what you can add

When a renewal fails on Paddle Billing, a lot happens without you: Paddle is the merchant of record, it retries the payment, and it can email the customer. That is a real advantage over building dunning yourself. It also means you need to know exactly what Paddle does, so you do not duplicate it or leave gaps.

This guide explains how Paddle Billing handles a failed subscription payment, what Paddle Retain adds, how customers update their payment details, and the parts you can improve yourself. It sticks to Paddle’s own documentation: the default dunning changelog, configure Payment Recovery and dunning, Payment Recovery, update payment details and the Paddle help article on Retain retry cadence (all accessed November 2026).

What happens when a renewal fails

For a subscription collected automatically, Paddle’s dunning guide describes the sequence:

1. The payment for the renewal transaction fails.
2. The subscription status changes to past_due.
3. Paddle sends transaction.payment_failed for the attempt, then transaction.past_due and subscription.past_due as the transaction and subscription become overdue.
4. Paddle retries the payment.
5. If a retry succeeds, the subscription goes back to active and is no longer overdue.

Default retries, with or without Retain

Paddle’s 2025 changelog made automatic payment failure retries available to all Paddle Billing users. Failed payments on automatically collected subscriptions are retried up to seven times over 30 days, even if you have not turned on Paddle Retain.

Two limits are worth knowing:

• Live accounts only. Paddle says automatic retries only run on live accounts. No retries occur in sandbox, so you cannot test the full retry schedule there.
• Automatic collection only. For manually collected subscriptions (paid by invoice), Paddle Retain does not take any action when they are past due. Paddle moved those subscriptions to past_due in 2024, but chasing them is up to you.

What happens at the end of the window

According to Paddle’s help article on retry cadence, you set what happens to a subscription when the recovery window ends: cancel it, pause it, or leave it past due. The default is cancellation after 30 days, and the window can be adjusted from the Paddle dashboard.

Choose deliberately. Cancelling is clean for reporting. Pausing keeps the subscription so the customer can come back without a new checkout. Leaving it past due keeps the door open but can leave customers with access they are not paying for, unless your app checks the status.

What Paddle Retain adds

Payment Recovery is part of Paddle Retain. On top of the default retries, Paddle’s docs describe:

Feature	What Paddle says it does
Tactical Retries	Retries failed payments at times chosen from payment method type, customer location and other details
Recovery emails	Up to four payment recovery emails
Other channels	Payment reminders in-app and by SMS
End of dunning	Can pause or cancel subscriptions automatically when all attempts are exhausted

By default, dunning in Retain runs over a 30-day period. Check in your Paddle dashboard whether Payment Recovery is turned on for your account before assuming any of this applies.

If you use Retain, let it own retries and emails. Running a second retry schedule against the same card adds attempts without adding information, and two dunning sequences in one inbox look like spam.

Letting customers update their payment details

Most hard declines only recover when the customer gives you a new card. Paddle’s update payment details guide lists the options:

1. Customer portal. Paddle’s portal is on by default and lets customers update their payment method without any screens of your own.
2. Customer portal session. You can create an authenticated deep link straight to the payment method update page for a specific subscription, so the customer does not have to sign in.
3. Subscription management URL. Paddle returns an update_subscription_payment_method link for each subscription that you can show in your app.
4. Update payment method transaction. Call GET /subscriptions/:id/update-payment-method-transaction. Where the subscription is past_due, it returns the most recent past-due transaction. Open its checkout.url, or pass the transaction ID to Paddle.js. This only works when collection_mode is automatic.

One setup step catches people: the default payment link must be set in your Paddle account and approved before customers can update payment details. Paddle also uses it in its dunning emails.

When a past-due subscription is paid after an update, Paddle sends subscription.activated and the status becomes active again.

A practical setup

Whether or not you use Retain, these steps close the usual gaps.

1. Set the default payment link and confirm it is approved. Without it, update links do not work.
2. Choose the end-of-window outcome (cancel, pause or past due) based on how your app handles access.
3. Gate access on status. Handle subscription.past_due, subscription.activated and subscription.canceled in your app. Decide how much access a past-due customer keeps, and say so.
4. Show the problem in your app. A banner for past-due customers with the subscription management link reaches people who never open dunning emails.
5. Do not double-email. If Paddle or Retain sends recovery emails, your own messages should be in-app, or clearly different (for example from the account owner, for large B2B accounts).
6. Chase manual invoices yourself. Retain does not act on manually collected subscriptions. Build a reminder sequence for those.
7. Log every failure. Store each transaction.payment_failed with the subscription, amount and outcome. After a few months you will know which customers recover by retry and which only by a new card.

What you can add on top

Paddle covers the core well: retries, a hosted update page, emails and a status model. What is left is mostly context.

• Know which customers are at risk. A failure on a long-tenured, active account is different from a failure on an account nobody has logged into for two months.
• Tie failures to what you know about the customer. Plan, usage, support history and payment method type all change what a good recovery message says.
• Measure. Count recovered versus lost per month and per cause. See involuntary churn for definitions and dunning email templates if you write your own in-app copy.

Doing this with NoChurn

For Paddle, payment collection, retries and Paddle’s own emails stay with Paddle as merchant of record. NoChurn reads your Paddle subscriptions and transactions, gives each customer a churn score from 0 to 100 using your custom data sent by API, and adds a cancel flow and win-back emails at day 30, 60 and 90. Where Paddle’s settings leave room, it can send AI-written recovery messages that you review before they go out. See NoChurn + Paddle.