A client funds a prop firm challenge at 23:40 on a Sunday. The card is declined with code 51, insufficient funds. The checkout shows a red box, the client shrugs and goes to bed. On Tuesday afternoon their salary lands. Nobody asks them again, so the sale is gone.
That single sequence is what dunning exists to fix. Dunning is the process of chasing a payment that failed: the retry schedule the system runs on its own, plus the messages sent to the payer while it does. In subscription businesses it is a standard part of the billing stack. In trading firms it is usually missing entirely, because deposits are treated as one-shot events and nobody owns the failure.
Soft declines and hard declines are different problems
The first thing any retry logic has to do is read the decline reason and split it into two buckets. A soft decline means the issuer said no to this attempt, in these conditions, right now: insufficient funds, issuer unavailable, do not honour, velocity limit, a 3DS challenge the client abandoned. Nothing about the card is broken. Retrying later can work, and often does.
A hard decline means the card itself is finished for your purposes: stolen, lost, closed account, invalid number, pick up card. Retrying a hard decline is worse than useless. It burns your approval ratio, it can trip fraud scoring at the acquirer, and in some schemes repeated attempts on a card flagged as stolen create their own compliance record. The rule is simple: hard declines never retry, they go straight to a message asking for a different method.
The trap is that decline codes arrive filtered. Your processor maps dozens of issuer responses into a handful of generic categories, and the generic bucket labelled "do not honour" hides everything from a spending limit to a silent fraud block. Ask your provider for the raw issuer response code and store it against the attempt. Without it you are retrying blind. This is the same visibility problem that shows up in decline reasons and in the wider work of lifting payment approval rates.
Retry timing beats retry count
The instinct is to retry immediately. It is almost always wrong. An immediate retry on an insufficient funds decline hits the same empty balance, and the issuer's own risk model reads a burst of identical attempts as card testing. Space them out instead, and vary the day of the week so at least one attempt lands after a typical payday.
Three or four attempts spread over a week or two is a normal shape for a recurring charge: something like the next morning, then three days later, then a week out. For a one-off deposit the window is much tighter, because the client's intent decays fast. There the retry is really a prompt, not a silent charge, and it belongs in an email or in-app message within a few hours.
Never silently re-attempt a one-off deposit days later without telling the client. A charge they no longer expect is a chargeback waiting to happen, and "I did not authorise this" is a dispute you will lose. Silent retries belong to recurring billing with clear terms, not to funding events.
What the dunning messages should actually say
Most dunning email is written by the billing team and reads like a debt notice. The tone matters more than the schedule. A client whose card failed is not delinquent, they are inconvenienced.
Three things belong in the first message: what happened in plain words, what you are going to do about it, and one button that fixes it now. "Your bank declined the payment for your Phase 1 account. We will try again on Thursday. If you would rather not wait, update your card here." No invoice jargon, no red warning banner, no threat about account suspension in the first message. Save the account consequence line for the final attempt, where it is a fact rather than pressure.
Send from an address that accepts replies. A meaningful share of recovery comes from clients who reply saying their bank blocked the merchant category, at which point support can point them at a different rail. That reply also tells you something your processor never will: which issuers are blocking you and in which countries.
Card updaters, network tokens and the quiet wins
A large slice of recurring failures are expired or reissued cards, not refusals. Visa and Mastercard both run account updater services that push the new card details to merchants who are enrolled, and most processors expose this. Network tokens do something similar by holding a token that survives reissue. Neither is exotic, and both remove failures that no retry schedule can help, because the card number in your vault simply no longer exists.
If your firm bills anything on a schedule, monthly platform fees, VIP subscriptions, recurring challenge resets, this is the first thing to switch on. The rest of the plumbing for that sits in recurring billing, and the routing question of which processor sees the retry belongs to payment orchestration.
Routing the retry somewhere else
Retrying the same card through the same acquirer that just declined it is the weakest version of this. If you run more than one processor, the second attempt should go through a different one. Acquirers have different bank relationships, different local presence and different fraud thresholds, and a transaction that fails at one clears at another often enough to justify the routing rule on its own.
The same applies across rails. If two card attempts fail for a client in a country where cards are a weak method anyway, stop retrying cards and offer bank transfer or a local method. A firm running a broker or prop back office should be able to see, per client, which rails have already been tried and which are still open. That client level payment history is one of the things our Broker CRM keeps in one place, because support cannot advise on a failed deposit they cannot see.
Measure recovery, not attempts
The number that matters is recovered value divided by failed value, cut by decline reason and by country. Attempt counts flatter you. A firm running eight retries per failure can show impressive activity while recovering less than a firm running three well timed ones, and it is paying per attempt for the privilege, since many processors charge for declines.
Watch the chargeback rate alongside it. If recovery goes up and disputes go up with it, the retries are being read as unexpected charges, and the fix is in the messaging, not the schedule. The link between aggressive billing and disputes is direct, and it is covered in chargebacks.
"Half the payments people write off as lost were never refused, they were refused once. The difference between a firm that recovers them and one that does not is usually a two line rule about when to try again."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Split declines into soft and hard on the raw issuer code: soft declines can retry, hard declines never should.
- Space retries over days and across paydays rather than hammering the same card in the same hour.
- Never silently re-charge a one-off deposit later, prompt the client instead, or the retry becomes a dispute.
- Enrol in card updater or network tokens before tuning schedules, since reissued cards cannot be recovered by timing.
Frequently Asked Questions
How many times should a failed payment be retried?
For recurring charges, three or four attempts spread over one to two weeks is a common shape, with attempts landing on different weekdays. For a one-off deposit the useful window is hours, not weeks, and the retry should be a prompt to the client rather than a silent charge. Attempts beyond that mostly add processor decline fees and issuer risk flags.
What is the difference between a soft decline and a hard decline?
A soft decline is a refusal of this attempt under current conditions, such as insufficient funds, an issuer timeout or an abandoned 3DS challenge, and it can succeed later. A hard decline means the card is unusable, for example closed, stolen or invalid, and retrying it damages your approval statistics without any chance of clearing.
Does dunning apply to brokers, or only to subscription businesses?
The retry machinery applies anywhere a payment can fail, including client deposits, but the rules change. Subscription dunning can retry silently under agreed terms. Deposit recovery has to be consent-led, meaning the client is told the payment failed and given a way to pay again, because an unexpected later charge invites a chargeback.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.