Knowledge Base

Soft declines in travel.

A practical guide to soft declines in travel — what they are, why travel sees more of them, how to retry by reason code, how to reduce them at the front door, and how soft-decline recovery fits a scheduled-payment book.

Book a walkthrough See payment optimisation

Retrytargeted by reason code

Recoverbalances before they age

Preventdeclines at the front door

Why soft declines matter in travel.

A soft decline is an issuer's "not now" answer to a payment. The card is valid, the account is open, the funds may even be there - but the issuer has refused the specific transaction in front of it. In travel, that "not now" can mean a balance payment slips past the supplier cancellation deadline, a deposit fails on the call where the customer is ready to book, or a scheduled instalment quietly stalls without anyone noticing for three weeks.

Travel sees more soft declines than retail

High average values, cross-border transactions, MOTO volume and large balance payments all push the issuer''s risk model toward more cautious responses than a £40 retail purchase would get.

The customer rarely knows

Issuers usually communicate soft declines to the merchant only. The customer often does not know their payment failed - so the recovery work falls entirely on the operator.

A missed recovery cascades

A failed balance two weeks before travel means a chase, a refund decision, a supplier-side problem and possibly a customer who travels anyway with the operator carrying the cost. Recovery within hours stops the cascade.

Section 01

How soft and hard declines differ.

The distinction is operational rather than technical. A hard decline says "do not retry this transaction"; a soft decline says "try this transaction differently, or later." Treating them the same throws away most of the recovery opportunity.

Soft = retriable

Insufficient funds, velocity limits, transient issuer-side errors and SCA step-up requirements are all soft. Each carries a different retry window and a different approach.

Hard = don't retry

Stolen-card flags, closed accounts, lost-card reports and fraud-block decisions are hard. Retrying these produces no recovery and risks chargeback flags.

Reason codes matter

The two-or-three-character response code the acquirer returns tells you which category you are in. Recovery logic that ignores the reason code is guessing.

How to retry soft declines by reason code.

The recovery logic depends entirely on why the issuer said no. A "do not honor" needs a different retry pattern than an "insufficient funds", which needs a different one again from a "velocity exceeded". Get the strategy right and you recover 40-60% of soft declines; get it wrong and you recover none of them.

Insufficient funds - wait and retry

An "insufficient funds" decline is the easiest to recover from because it almost always self-resolves on the next payday. Retry 3-5 days later, then again 7 days after that. Most insufficient-funds declines convert within 14 days without any customer contact at all - if the schedule is built to wait.

Retry 3-5 days

Repeat 7 days

Recovery rate 40-60%

See decline code in the glossary

Do not honor / 05 - retry differently

"Do not honor" is the most common soft decline and the most ambiguous - the issuer is essentially saying "we are not telling you why." Retrying via the same channel often produces the same response. Retrying with different metadata (a payment link the customer authenticates afresh, or a 3DS step-up) frequently converts. Up to a third of "do not honor" responses recover this way.

First retry Same channel

Second retry Re-auth via link

Recovery rate 25-35%

See payment links

Velocity exceeded - wait, then retry once

Velocity declines happen when the cardholder has hit a daily limit on transactions or amount. Retrying the same transaction the next day usually succeeds because the velocity counter has reset. Repeat retries on the same day after a velocity decline almost never recover and risk further flags.

Retry Next day

Repeat Avoid

Recovery rate 50-70%

See decline ratio in the glossary

SCA required - step the customer up

A "SCA required" decline is the issuer asking for a step-up. Sending the customer a payment link they can authenticate inside their banking app converts the transaction with full liability shift. This is the highest-recovery soft-decline category in travel because the issuer is essentially asking for evidence the merchant is happy to provide.

Action Send 3DS link

Liability Shifts to issuer

Recovery rate 60-80%

See SCA in the glossary

Section 03

How to reduce soft declines at the front door.

Recovery is reactive; reduction is preventive. Most soft declines in travel come from a small number of front-door mistakes that compound across a portfolio.

Authenticate by default

Routing eligible transactions through 3DS reduces issuer-side caution. An authenticated transaction is far less likely to get a "do not honor" than the same transaction without authentication.

Time payments for the cardholder's day

Issuer velocity limits often reset overnight. A balance payment attempted at 9pm is materially more likely to soft-decline than the same payment at 10am because the cardholder's daily counters are higher in the evening.

Match descriptor to the booking

Issuer fraud models look at descriptor patterns. A descriptor that names the operator clearly attracts fewer pre-emptive blocks than a generic processor descriptor.

Watch the BIN profile

Some issuing BINs are reliably restrictive on travel transactions. A pattern of declines from a small set of BINs is a sign to handle those transactions differently from the start.

How soft declines fit a scheduled-payment book.

The economics of soft decline recovery change dramatically inside a scheduled-payment book. A failed instalment that is just retried by the scheduler the next day costs almost nothing; the same instalment that has to be chased manually costs more in finance time than it returns.

Build retries into the schedule

A balance schedule that retries automatically on the right cadence per reason code recovers most soft declines without ever surfacing in a finance inbox. The schedule treats the retry as a continuation of the same scheduled payment, not a new transaction, so the audit trail stays clean.

Retry Automatic

Audit trail Continuous

Finance inbox Exceptions only

See payment scheduling in the glossary

Surface only the exceptions

After the automatic retry budget is exhausted, the booking moves to manual review with the reason-code history attached. Finance acts on declines that genuinely need intervention rather than chasing the entire decline list. Operators using exception-only surfacing typically halve the finance hours spent on decline management.

Automatic recovery 60-80%

Manual queue Exceptions only

Finance time Cut by half

See financial control

Trigger customer contact at the right point

Automated retry, then re-authentication via a fresh payment link, then customer contact - in that order. Contacting the customer first on every decline trains them to ignore the messages; contacting them only when the schedule has genuinely run out of options gets attention when it matters.

Step 1 Auto retry

Step 2 Re-auth link

Step 3 Customer contact

See payment plans

Section 05

How to handle the customer side of a soft decline.

When automatic recovery fails and the customer has to be contacted, the conversation needs to be short, specific and easy to act on. A vague "payment failed" message gets ignored; a specific "your balance for [booking], due [date], was not authorised - please tap this link to retry" gets actioned.

Reference the booking, not the transaction

The customer recognises the booking, not the transaction reference. Lead with the booking details, not the technical decline.

One action, one tap

Send a payment link that re-authenticates in the customer's banking app or via their card's 3DS flow. Asking the customer to call or email loses the recovery.

Time it to the deadline

A reminder seven days before the supplier cancellation deadline beats one the day before. Build the customer contact into the schedule, not in panic mode.

What soft-decline recovery looks like in felloh.

felloh treats soft declines as a first-class part of the scheduled-payment picture. Each decline is captured against the booking with its reason code, fed into the retry logic and surfaced as an exception only when the automatic recovery has run out of options.

See this guide running on your booking data.

Bring the workflow or rail you want to improve and we will show how felloh keeps the booking-level evidence connected end to end.