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.
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.
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
51 / NSF - retry against the next likely funding cycle.
See decline code in the glossaryDo not honor / 05 - retry differently
A vague issuer-side refusal that often clears on retry through a different channel.
See payment linksVelocity exceeded - wait, then retry once
Issuer cap-hit; the next day usually resolves it.
See decline ratio in the glossarySCA required - step the customer up
65 / SCA required - the issuer wants 3DS authentication.
See SCA in the glossaryHow 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
Each scheduled payment carries its own retry pattern based on expected reason codes.
Surface only the exceptions
When automatic retries fail, the booking surfaces as an exception with the reason code attached.
Trigger customer contact at the right point
Customer contact is the last step, not the first.
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.
Reason-code-aware retries
The scheduler retries by reason code rather than blindly - so insufficient-funds waits for the funding cycle, SCA-required gets a re-authentication link, velocity waits for the next day.
Booking-level decline analytics
Decline patterns by reason code, issuer BIN, channel and customer segment are visible against the booking record - so the prevention work targets real causes.
Customer contact as a last step
Where automatic recovery fails, the customer gets a clear, booking-referenced re-authentication link rather than a vague support message.
See how this works around your bookings.
Bring one payment, reporting or cash-position problem. We will show how felloh connects the booking-level money trail behind it.
Book a walkthrough