Soft Decline

A soft decline is a card payment the issuer turns down for a reason that could change in a moment. The card is real, the account is open, and nothing about the customer is wrong. Something about this attempt did not suit: a limit was close, a check was skipped, a system was busy. Try again in the right way and the same card on the same account may well go through. That is what separates it from the other kind, where the answer is settled and trying again is a waste of everyone's time.

The split matters more than it sounds, because a large share of turned-down card payments are soft ones. A merchant that treats every refusal as final walks away from sales it could have kept. In Europe the leading cause is a payment that needed strong authentication and did not get it, so the card issuer sends it back and asks for the customer to be challenged. The rules on when that challenge is owed, and on the cases where it can be skipped, sit in the regulatory technical standards. Card scheme rules add their own limits on what a merchant may do next, and the Visa Core Rules are public for anyone who wants to read them.

What The Answer Is Telling You

Every refusal comes back with a decline code, and the code is the whole message. Some codes name a state that will pass on its own, such as a bank system that was down for a moment. Some name a step that was missed, such as authentication. Some name a state the customer has to fix, such as a balance that is short. Reading the code and acting on it is a different job from counting refusals, and only the first one wins any money back.

Soft And Hard Are Not The Same

A hard decline is the issuer saying no and meaning it: the card is reported lost, the account is shut, the details are wrong. Trying again there gets the same answer, and repeated tries can flag the merchant for card testing. A soft one is the issuer saying no for now. Treating the two the same way is a common mistake in this area, and it shows up in both directions, as lost sales on one side and needless retries on the other.

The Usual Reasons Behind One

Four causes cover most of them. Authentication was needed and was not done, which leads the field in Europe. Funds were short at that moment, which a customer can often fix within hours. The issuer's own risk rules did not like something about the attempt, such as a first payment to a new payee. Or a system somewhere timed out. Each has a different right answer, and none of them is served by sending the same request again straight away.

Authentication Turns Many Of Them Around

Where the cause is a missing challenge, the fix is to run one. The customer is sent through cardholder authentication, proves who they are, and the payment is sent again with that proof attached. The issuer then sees a payment it was asking for and tends to approve it, and the reason so many merchants lose the sale here is that they show a plain failure message instead of taking the customer through the extra step, which takes about twenty seconds.

Retry Rules Come From The Schemes

A merchant cannot send the same payment again as often as it likes. The card schemes cap how many attempts are allowed for a given order, over what period, and they charge for going past it. The caps differ by scheme and by the reason code that came back. A sensible retry plan waits, spaces the tries out, changes something between them, and stops. Sending the same request four times in a minute is the pattern that draws a fine.

Recurring Payments Feel It Most

Subscriptions depend on this. A recurring payment that comes back soft is a customer who has not cancelled and still wants the service, so giving up on the first try loses revenue that was not at risk. Retrying on a payday, or a few days later, recovers a good share of them. Using a network token also helps, since it keeps the card current when the plastic is replaced.

Quiet Revenue Leaking Away

The damage is quiet, which is why it lasts. A merchant with a middling approval rate and no soft-decline work may be turning away points of revenue it had already earned. Nobody complains, because the customer just leaves. The number only shows up when someone breaks refusals down by code and asks how many of them were recoverable. Where a business has exemptions available under the rules, an SCA exemption can keep the challenge off low-risk payments altogether.

Recovering The Sale

Start by logging the reason code on every refusal, because nothing else works without it. Group the codes into recover now, recover later and do not bother. Step up to authentication where that is what was asked for, and do it in the same session rather than by email the next day. Build a retry schedule that respects the scheme caps and spaces attempts by days, not seconds. Tell the customer something useful. A message saying the bank wants to check this payment gets a better response than one saying the payment failed. Track recovery as its own number, separate from the headline approval rate. This piece on smart 3D Secure covers the authentication side, and smart routing is designed to help send the second attempt down a different path.

‍