Soft decline vs hard decline
A soft decline means 'try again later' (no funds, bank glitch). A hard decline means 'stop asking' (stolen, closed, invalid).
See it
What it is
A soft decline is the issuer saying 'not right now': insufficient funds, a velocity or spending limit, an issuer system that was temporarily unreachable, a suspected-fraud flag that a customer can clear. The same card may well work tomorrow, so retrying is legitimate. A hard decline is 'never': stolen or lost card, closed account, invalid number, revoked authorization, pickup card. Retrying that is pure waste.
This distinction is the entire input to a retry policy, which is why every recovery system starts by classifying the decline code rather than the boolean success flag. Map your provider's codes into three buckets: retry later, ask the customer for a new payment method, or route them through an authentication step. Then let dunning and retries branch on the bucket instead of treating all failures alike.
Gotchas: the most common decline reason in the wild is 'do not honor', which is a generic shrug and can be either flavor, because issuers deliberately do not tell you why they refused a card. Card networks also police retries, capping attempts per declined transaction and charging fees for hammering hard declines, and a merchant ID with a bad approval ratio starts getting declined on good charges too.
Ask AI for it
Write a decline classifier for our payment integration. Take the provider's decline code and network response code and return one of three outcomes: RETRY (insufficient funds, issuer unavailable, processing error, velocity or withdrawal limit exceeded, try again later), REQUIRE_NEW_METHOD (lost or stolen card, pickup card, invalid account or number, closed account, revoked authorization, expired card after one update attempt), and REQUIRE_AUTHENTICATION (authentication required or 3DS challenge needed). Treat generic codes like 'do_not_honor' and 'generic_decline' as RETRY but cap them at two attempts. Keep the mapping in one table with the raw codes as keys so it is auditable, log every unmapped code with a safe default of REQUIRE_NEW_METHOD, and expose the outcome to the dunning and retry scheduler instead of a plain success boolean.