A renewal fails and nothing visible breaks. The customer keeps logging in, the product keeps working, and the failure shows up only as a status change in a billing dashboard nobody opened that morning. By the time someone looks, the account has closed itself out, and the customer never made a decision about leaving.

A SaaS dunning sequence is the set of retries and messages your billing system runs between that first decline and the moment you stop asking. This guide covers what the decline code should change about your next step, and how far apart to space the retries. It also covers what the emails should say, and what to do for a customer whose card will not work on any attempt. EukaPay is where that last case ends, with a second payment rail the customer can settle from.

The sequence starts when a scheduled charge comes back declined. Your billing system moves the account into a past-due state, records the decline code the issuer returned, and schedules the next attempt. Everything after that is a design decision you made in advance, so the quality of the sequence is set before any customer ever sees it.

A soft decline means the issuer refused this attempt but the card is still alive. Insufficient funds is the common case, and it can clear on its own within days. A hard decline means the card itself is finished: closed account, stolen card reported, or an issuer instruction not to try again.

The distinction splits your sequence in two. A soft decline is a timing problem, and retrying is a reasonable answer. A hard decline is a payment-method problem, and no number of retries fixes it. Branching on the code is what separates a sequence that recovers revenue from one that runs its schedule and gives up.

Give the account real states instead of a boolean. Active is the paid state. Past due means the sequence is running and the customer still has full access. Restricted means access is reduced but the data is intact. Cancelled is the end.

Keeping restricted separate from cancelled lets a customer come back without rebuilding their workspace. It also gives your emails something honest to say at each step, instead of a vague consequence.

There is no universal number, and the count is the wrong variable to tune first. Three or four attempts spread across two to three weeks is the common shape, but the spacing does more work than the total.

Retries that land close together all hit the same account balance in the same state, so they tend to fail together. Spreading them out gives the underlying condition time to change: a payday lands, the customer moves money, and the issuer's hold expires.

Aligning one attempt with the start of the following month is often worth more than a fourth attempt in the same week. Log the outcome of every attempt with its decline code, because it tells you whether your schedule is recovering payments or recording the same refusal several times.

When the code says the card is gone, stop retrying it and switch the sequence to asking for something new. That means a card update, or a different payment method entirely. Continuing to retry a dead card spends your remaining days in the past-due window and recovers nothing.

This is the branch most sequences skip, and it is where the recoverable revenue is. The customer has not decided to leave. They have a payment instrument that no longer exists, and your sequence is still requesting the wrong action.

Three to five messages across the same window is the usual shape, escalating from information to a named consequence. The tone question matters more than the count, because the recipient is a paying customer who has not done anything wrong.

Say what happened, say what it means for their access right now, and give them one action. A card update link that works without a password reset is the whole email. Leave out the apology padding and leave out the word "failure" applied to the customer.

Do not lead with a threat. At this point nothing has changed for them, and saying so is what keeps the message credible when a later one does carry a deadline.

The final message is the one that needs a date in it. Name the day access changes, name what stays available after that day, and repeat the single action. A customer who reads a specific date and a specific consequence is more likely to act than one who reads that their account is "at risk".

Set your grace period so the sequence finishes inside it, and let the customer pause the account instead of cancelling. A pause keeps the relationship and the data, and turns a permanent loss into a delayed one. There is more in our guide to

subscription billing solutions

.

EukaPay covers the case most sequences leave open: a customer whose card will not complete the renewal on any attempt. Most billing systems build the first two routes and stop, so the customers who need the third are the ones already written off. An invoice they settle in stablecoins or crypto turns that write-off into a completed renewal. It works the same way for a buyer whose card sits outside your acquirer's footprint. Our overview of

recurring crypto invoices

covers the setup.

EukaPay does not run your dunning sequence. The retry schedule, the decline-code branching, the account states, and the messages stay in your own billing system, which is where they belong. What EukaPay covers is the payment itself: invoices, payment links, checkout, and subscriptions that send invoices on a recurring schedule at intervals from daily to annually.

All four products use instant crypto-to-fiat conversion at a locked exchange rate to remove your exposure to crypto price swings, support for most major cryptocurrencies like BTC, ETH, LTC, SOL, USDC, USDT, and settlement in USD, EUR, GBP, and CAD to your bank account. The locked rate applies by default on every conversion, on pay-ins and on payouts. A crypto payment confirms on-chain, so protection against chargebacks is a property of the payment method.

For a SaaS operator, that adds a route to the end of a sequence that currently ends in a write-off. The customers who reach the last email are already telling you the card is not the answer. More context sits in our piece on

SaaS challenges in 2026

.

Create an account

to send your first invoice, then read the invoices and subscriptions endpoints in the

API documentation

to wire the trigger into the end of your dunning sequence.

What is a dunning sequence in SaaS billing?

It is the series of automated payment retries and customer messages your billing system runs after a subscription charge is declined. The goal is to recover the payment before the account cancels.

How long should a SaaS dunning sequence run?

Most run two to three weeks, matched to the grace period during which the customer keeps access. The window should be long enough for a payday or an issuer hold to change the outcome.

Should a dunning sequence retry a hard decline?

No. A hard decline means the card is closed or the issuer has told you to stop, so further attempts on it cannot succeed. Branch to a card update request or a different payment method instead.

How many dunning emails should you send?

Three to five across the sequence works for most self-serve products, escalating from an informational note to a message naming the date access changes. One clear action per email.

Does EukaPay run dunning or payment retries?

No. EukaPay sends invoices, payment links, checkout pages, and subscriptions that invoice on a recurring schedule. Retry logic, plan management, and billing cycle control stay in your own system.

Can a customer pay a failed renewal in stablecoins or crypto?

Yes. You can send a EukaPay invoice or payment link for the outstanding amount, and the customer settles it from a wallet without a card being involved.

Which cryptocurrencies can a customer pay with?

EukaPay supports most major cryptocurrencies like BTC, ETH, LTC, SOL, USDC, USDT.

Which currencies does EukaPay settle to?

Fiat settlement reaches your own bank account in USD, EUR, GBP, and CAD, and merchants can choose crypto settlement instead.