Recurly's Dunning Cycle is the built-in system that automatically re-attempts a subscription payment after it first fails, on a schedule of retry days and reminder emails you configure once per plan and currency in Recurly's own settings. Alongside it sits Account Updater, a genuinely distinctive feature that quietly refreshes stale card data through the Visa and Mastercard networks. Both are real, working mechanisms — not placeholders — and together they recover a meaningful share of failed payments without any extra tooling. But recovering some failed payments and recovering everything recoverableare two different claims, and the gap between them is where a surprising amount of quietly lost revenue tends to sit: a fixed cycle that treats every decline the same way, an email template that doesn't change based on why the card failed, a hard stop once the configured attempts run out, and a strength (Account Updater) that only ever solves one specific slice of the problem.
This guide walks through how Recurly's Dunning Cycle and Account Updater actually work under the hood, the specific settings worth checking today, the handful of gaps that are easy to miss because Recurly never surfaces them as a warning, and an honest look at what a recovery layer added on top of Recurly can and cannot do that Recurly's native tools don't already cover. Revova connects to Recurly directly (read-only) alongside Stripe, Paddle, Braintree, and Chargebee, so the limitations described here are ones we have had to design around ourselves, not secondhand speculation about a platform we don't actually integrate with.
Key takeaways
- Recurly's Dunning Cycle is rule-based and configurable per plan and currency — a fixed schedule of retry days and reminder emails, not a per-decline machine-learning model like Stripe Smart Retries.
- Account Updater is a genuine differentiator — it automatically refreshes expired or reissued card data via the Visa/Mastercard networks, with zero customer action required. It does not help with true declines like insufficient funds.
- The default configuration commonly sends the same email copy regardless of decline reason — an expired card and a temporarily insufficient-funds decline get identical wording, even though the right customer action differs completely.
- Once the configured Dunning Cycle is exhausted, the account typically is canceled or left past_due per your expiration setting, and nothing automatically retries that specific account again afterward.
- A recovery layer added on top of Recurly (like Revova) can add decline-aware email branching and a historical scan across already-exhausted accounts, without replacing Recurly as the system of record for billing.
How Recurly's Dunning Cycle actually works
Recurly's Dunning Cycle lives in the billing settings of your Recurly site, and — like the equivalent setting in most subscription billing platforms — it applies at the plan and currency level rather than being something you configure per individual customer. When a subscription payment attempt fails, whether the failure comes back from Braintree, Stripe, or whichever gateway you have connected underneath Recurly, the account moves into a past_due state. From there, Recurly runs through the cycle you configured: a set number of retry attempts, spaced a set number of days apart, each one paired with a reminder email sent to the account holder around the same time.
This is meaningfully different from how Stripe's own Smart Retries feature works at the charge level, and conflating the two is a common source of confusion. Stripe Smart Retries uses a model trained across Stripe's network of transactions to estimate the statistically best moment to re-attempt a specific declined charge. Recurly's Dunning Cycle, by contrast, is a configuration you set — the same day intervals apply to every past_due account on that plan and currency, regardless of the specific reason the card was declined. If Stripe happens to be the gateway underneath your Recurly account, some of that charge-level retry intelligence can still be in play for the individual attempt itself, but the cycle wrapped around it — how many attempts, how far apart, what emails go out — is the configurable layer Recurly itself controls.
Same word, two different mechanisms
What the default Dunning Cycle actually looks like
A typical Recurly Dunning Cycle spreads a handful of retry attempts across roughly the first one to two weeks after a payment first fails, then stops. Exactly how many attempts and how many days apart is something you set per plan and currency in Recurly's dunning settings — there is no single universal default that applies to every account, so the specific numbers below are illustrative of the shape of a cycle, not a claim about what your account is currently configured to do. What matters structurally, regardless of the exact numbers you've set: the cycle is finite, it runs on calendar days rather than being aware of weekends or the customer's likely payday, and it stops completely once the last configured attempt has run.
The practical risk in this shape is the same one that shows up in almost every rule-based (non-adaptive) retry system: a cycle tuned for the average case can be badly mistimed for any specific account. A customer whose card was declined for insufficient funds right before a payday might recover instantly on a retry scheduled two days later — or might still be short on day 2 and recover cleanly on day 11, well past where a tight cycle already gave up. Widening the cycle to cover more of that variance is possible, but it trades off against how long a subscription sits in a past_due state before either recovering or being canceled, which has its own cost in a customer's perception of your billing reliability.
Account Updater: a real strength, worth crediting honestly
Recurly's Account Updater is the one feature in this comparison that is genuinely distinctive rather than a variation on what every subscription billing platform already offers. Rather than waiting for a payment to fail because a card expired or was reissued, Account Updater periodically checks stored card data against the Visa and Mastercard account updater networks and refreshes it automatically — a new expiration date, a new card number after a reissue — with zero action required from the customer. When it works, the payment that would otherwise have failed on an expired card simply succeeds, silently, and nobody ever sees a decline at all.
The honest caveat, and the reason this section exists rather than just being folded into a features list, is that Account Updater solves exactly one category of payment failure: stale card data on a card that is otherwise still valid. It has no effect whatsoever on a decline caused by insufficient funds, a bank flagging the charge as suspicious, a closed account, or any other reason the issuer actually rejects the charge rather than the card number or expiration date simply being out of date. Coverage also depends on the issuing bank and card network actually participating in the update program, which is common for major U.S. and international issuers but not universal — Account Updater raises your recovery rate on one real, common failure mode, it does not eliminate failed payments as a category.
Not a substitute for the rest of your recovery stack
The gaps a default Recurly configuration doesn't cover
None of what follows is a bug in Recurly — it is simply outside what a configurable, rule-based Dunning Cycle plus a card-data-refresh feature are designed to do by default. These are the three gaps we see most often when looking at a merchant's existing Recurly setup, roughly in order of how much recoverable revenue each one tends to represent.
| Gap | What Recurly does by default | What it costs |
|---|---|---|
| Decline-reason branching | Sends the same templated email at each scheduled step, regardless of why the payment failed | A customer with an insufficient-funds decline gets the same wording as one with a fraud-flagged charge, instead of the message that actually fits their situation |
| Historical exhausted accounts | Stops retrying entirely once the configured Dunning Cycle ends; the account stays past_due or canceled | Accounts that failed months ago and never recovered sit untouched indefinitely unless someone manually revisits them |
| Send-time personalization | Sends reminder emails on the scheduled calendar day, not tuned to a specific customer's likely payday or timezone | A well-timed reminder converts meaningfully better than the same copy sent at a mistimed moment — timing is left on the table |
Gap 1: no automatic branching by decline reason
Recurly generally surfaces the specific decline detail your connected gateway returns, and you can see it manually on the transaction record. What the standard Dunning Cycle configuration does not do out of the box is route that decline reason into different email copy or different retry timing automatically. An insufficient-funds decline, a bank flagging the charge as suspicious (a do_not_honor-style response), and — separately from what Account Updater already handles — a card that failed for a reason other than stale data are different situations that call for different messages and, arguably, different retry cadences, yet a default Recurly configuration commonly sends the same wording for all of them unless you build that branching logic yourself.
Our separate guide on soft decline vs. hard decline covers the underlying distinction in more depth: a soft decline (insufficient funds, a temporary processor issue) is usually recoverable with time and a well-timed retry, while a hard decline (a closed account, a card flagged as stolen) will keep failing no matter how many times you retry it — it needs the customer to actually update their payment method. A Dunning Cycle that retries a hard decline repeatedly on the same card is not just ineffective, it wastes attempts and annoys the customer with repeated failure notices for something a retry was never going to fix.
Gap 2: accounts that already exhausted the cycle stay untouched
This is the gap we see cost the most, quietly, over time. Once Recurly's configured Dunning Cycle runs out for a given account and the expiration action fires (commonly canceling the subscription), nothing in Recurly automatically comes back to that specific account later. It sits past_due or canceled, permanently, unless a person manually revisits it, the customer proactively reaches out to update their payment method, or a separate process specifically re-approaches that historical backlog.
The reason this backlog builds up invisibly is structural, not a failure of attention: a Dunning Cycle is designed to handle a failure once, at the time it happens, and then hand off to whatever expiration action you configured. It was never designed to periodically re-scan old, already-exhausted accounts on its own — that would be a fundamentally different kind of system, closer to what our historical payment recovery guide describes in more general terms across any processor, Recurly included.
Gap 3: send timing is calendar-based, not customer-aware
A reminder scheduled for “day 5” fires on day 5 for every affected customer, regardless of that customer's typical payday, timezone, or how likely their specific bank is to have cleared a temporary hold by then. This is a smaller effect than the first two gaps, but it compounds with them — a decline-reason-aware email sent at a mistimed moment still recovers less than the same email sent when the customer is actually in a position to act on it.
How to configure Recurly for better recovery today
None of the following requires leaving Recurly or adding a new tool — these are adjustments available directly in Recurly's own settings, worth checking regardless of whether you eventually add a recovery layer on top.
- Open your current Dunning Cycle settings for every plan and currency and write down what they actually are.Most teams configured this once, at setup, and haven't revisited it since — confirm the number of attempts, the day intervals between them, and the expiration action currently set.
- Confirm Account Updater is actually turned on.It is a genuine, free win for expired-card churn specifically, and it is easy to assume it is running when it isn't enabled or when your issuing banks aren't all participating in the update program.
- Separate your hard-decline handling from your soft-decline handling.For declines that clearly need a new payment method, the highest-leverage change is making the first email explicit about that — “update your payment method” rather than a passive “we'll try again” — since retrying the same card repeatedly on a hard decline wastes every remaining attempt in the cycle.
- Widen (or shorten) the cycle based on your actual billing cycle, not a default. A monthly plan and an annual plan carry very different stakes for how long an account should stay past_due before the expiration action fires — our annual plan renewal guide covers why annual renewals in particular benefit from a longer runway than a default monthly-tuned cycle gives them.
- Rewrite the default email copy to be specific and actionable.Generic “your payment failed” wording performs worse than copy that states plainly what happened and what the one next action is — see our dunning email examples and templates for copy patterns organized by exactly this kind of decline-reason branching.
- Confirm your Dunning Cycle emails are actually reaching the inbox. A perfectly configured cycle sending well-branched copy still recovers nothing if the emails are landing in spam — check SPF, DKIM, and DMARC per our dunning email deliverability guide, since this is a separate layer entirely from anything in Recurly's own settings.
What a recovery layer can honestly add on top of Recurly — and what it can't
Being precise about the boundary here matters more than a feature list. Recurly remains the system of record for your subscriptions and billing logic — that does not change when you add a recovery layer on top, and no tool that connects read-only to Recurly should claim otherwise. What a recovery layer like Revova adds is specifically the gaps covered above: decline-reason-aware email copy generated automatically instead of one generic template, and a historical scan across accounts that already exhausted Recurly's own Dunning Cycle. Account Updater keeps doing what it already does well — refreshing stale card data — and a recovery layer does not need to, and should not try to, replicate that.
✓ Pros
- +Recurly's Account Updater and Dunning Cycle are already configured and working — no need to rip anything out or migrate billing logic.
- +Adjusting the cycle, email copy, and expiration-action settings directly in Recurly costs nothing and can meaningfully improve recovery on its own.
- +A recovery layer connects read-only, so Recurly stays the single source of truth for subscription state.
✕ Cons
- –Decline-reason branching and a historical scan require either custom engineering work inside Recurly's webhook/API layer, or a separate connected tool — neither is free.
- –A recovery layer cannot fix a deliverability problem in your sending domain by itself — that still requires the SPF/DKIM/DMARC work covered in our deliverability guide.
- –Some of what a recovery layer adds (AI-personalized copy, automatic historical scans) is genuinely new functionality, not something you can toggle on inside Recurly's existing settings.
Full plan details, including exactly what's included on Starter versus Pro, are on the Revova pricing page.
How to audit your current Recurly setup, starting today
- Pull up your Dunning Cycle settings for every active plan and currencyin Recurly and confirm the retry count, day intervals, and expiration action match what you'd actually choose today, rather than whatever was configured at initial setup.
- Verify Account Updater is enabled and check its recent match rate if Recurly surfaces one — this tells you how much of your expired-card churn is already being silently fixed versus still slipping through.
- Read your current Dunning Cycle emails as if you were a customer who was just temporarily short on funds, and separately as one whose bank flagged the charge as suspicious — if the email reads identically for both, that is the decline-reason gap described above, live in your account right now.
- Filter your accounts for a past_due or canceled status older than your configured Dunning Cycle window, and count how many there are — that count, multiplied by average transaction value, is a rough floor on what the historical-exhausted-account gap has already cost.
- Check your sending domain's SPF, DKIM, and DMARC recordsindependently of anything in Recurly's settings — a cycle-and-copy problem and a deliverability problem look identical from the outside (low recovery rate) but need completely different fixes.
- Run a historical scan against your actual Recurly billing dataif you want a precise number rather than a rough estimate — this reads account state directly and does not depend on Recurly's own Dunning Cycle having been configured correctly at the time.
For Recurly's own documentation on configuring the Dunning Cycle, retry schedules, and Account Updater, see Recurly's dunning management documentation.
Frequently asked questions
What is Recurly's Dunning Cycle, exactly?
Recurly's Dunning Cycle is the built-in system that automatically re-attempts a subscription payment after it first fails, on a schedule you configure per plan and currency inside Recurly's own settings, while sending a matching sequence of reminder emails to the account holder. You set the number of retry attempts and the number of days between them once, and every account that enters a past_due state from that point forward follows the same configured cycle until it either recovers or the cycle runs out and the configured expiration action fires.
What does Recurly Account Updater actually do?
Account Updater is a real, distinctive feature: it automatically refreshes stored card data — a new expiration date or a reissued card number — by checking against the Visa and Mastercard account updater networks, without requiring the customer to do anything. It genuinely helps with one specific cause of failed payments: a card that expired or was reissued but is otherwise still valid. It does nothing for a decline caused by insufficient funds, a bank flagging the charge as suspicious, or any other reason the card issuer actually rejects the charge rather than the card data simply being stale.
Does Recurly use machine-learning-based smart retries like Stripe does?
No. Recurly's Dunning Cycle is rule-based and configured by you — a fixed set of retry days that applies uniformly to every past_due account on that plan and currency, regardless of the specific decline reason returned by the gateway. Stripe Smart Retries, by contrast, uses a model trained across Stripe's own transaction network to pick a statistically better retry time for a specific declined charge. If Stripe happens to be the gateway underneath your Recurly account, some of that charge-level timing intelligence can still apply to the individual attempt, but the cycle wrapped around it — how many attempts, how far apart, what emails go out — is the configurable layer Recurly itself controls.
What happens when Recurly's Dunning Cycle finishes without recovering the payment?
That depends on the expiration action you configured for the plan — commonly the subscription is marked canceled or the account is left past_due, and nothing in Recurly automatically retries that specific account again after that point. The account's billing history still shows the failed attempts, but the built-in cycle itself does not revisit it, unless a person manually intervenes, the customer proactively updates their payment method, or a separate process specifically re-approaches that historical backlog.
Can I customize the Dunning Cycle email templates in Recurly?
Yes — Recurly lets you edit the subject line and body of each email in the cycle, and you can use merge fields for the account holder's name, plan, and amount due. What the standard Dunning Cycle configuration does not do natively is automatically change that email copy based on the specific decline reason the gateway returned. An expired card, a temporarily insufficient-funds decline, and a bank-flagged charge commonly receive the same templated wording at each scheduled step unless you build separate branching logic yourself, which is one of the gaps covered later in this guide.
How many retry attempts should I configure in Recurly's Dunning Cycle?
There is no single correct number, and the right count depends on your billing cycle length, average transaction value, and how tolerant your customers are of repeated reminder emails. What holds true regardless of the exact count: a cycle with too few attempts spaced too close together mostly just re-catches the same instantly-failing hard declines and burns through its remaining attempts on accounts that were never going to recover on a retry alone. A cycle spread too far apart risks a recoverable soft decline sitting un-retried long enough that the customer has already found an alternative or emotionally churned before Recurly tries again.
Does Recurly tell me the specific decline reason for a failed payment?
Recurly generally surfaces whatever decline detail the connected gateway returns, visible on the transaction record inside Recurly's dashboard. The nuance is that Recurly's own Dunning Cycle and default email templates don't automatically route that decline reason into different retry timing or different email copy — the data is there to see manually, it just isn't automatically branched by Recurly's standard configuration without custom work on your end.
Can I run Recurly's Dunning Cycle and a third-party recovery tool at the same time?
Yes, and for many teams that is exactly the right setup — Recurly stays the system of record for subscriptions and billing, while a recovery layer on top adds what the native Dunning Cycle doesn't do by default: decline-reason-aware email branching and a historical scan across accounts that already exhausted the cycle and went unrecovered. Revova connects to Recurly read-only for exactly this reason — it doesn't replace Recurly's billing engine, it adds a recovery layer around what Recurly already tracks.
Is Account Updater a substitute for a dunning or recovery strategy?
No, and treating it as one is a common mistake. Account Updater solves a narrow, specific problem — stale card data on an otherwise valid card — silently and automatically, which is genuinely valuable. It does not touch the much larger set of failures caused by insufficient funds, temporary bank holds, or a card being flagged as suspicious, all of which still need a working Dunning Cycle, decline-aware messaging, and in many cases a recovery layer on top to close the remaining gap.
How is this different from your general historical payment recovery guide?
They cover two different layers. Our separate historical payment recovery guide describes, in processor-agnostic terms, why any dunning system — Recurly's included — stops looking at an invoice once its own schedule ends, and how a historical scan closes that gap regardless of which platform is underneath. This guide is specific to Recurly: how its Dunning Cycle and Account Updater actually work, what they do and don't cover today, and the concrete settings worth checking in a Recurly account specifically.
Recurly's Dunning Cycle is only as good as what it can't see
Revova connects read-only to Recurly, adds decline-reason-aware recovery emails on top of your existing Dunning Cycle, and scans your full billing history for anything that already exhausted dunning and went unrecovered. 14-day free trial, no credit card, 30-day money-back guarantee.
Start my 14-day free trial →No credit card · Free Lost Revenue scan · 30-day money-back guarantee
