Library · Payment orchestration · How to run this
Soft vs hard decline: next action
A decline is not one word. Soft means the issuer left a path to try again. Hard means the card or the issuer said stop. Treating every decline as retryable is how you burn authorization caps and dump a second merchant account.
Pair: Soft vs hard decline playbook on Payment orchestration. Kill vs updater after hard fail: token kill vs updater. Wallet path fails before a card auth: wallet decline recovery. Whether hops recovered orders or only burned auths is a different job: When retries pollute a merchant account. The day list after a rebill fails is a different job: Dunning by decline family.
Soft vs hard on this account
Soft. NSF / insufficient funds. Some do-not-honor. CVV or AVS mismatch when you can fix the data. A 3DS fail when this MID is enrolled and your rule allows a fall-back. Retry on this merchant account. One clean retry, or a short same-MID wait for NSF. Do not open a new account to chase the sale.
Hard. Pick-up, lost, stolen. Invalid or no account. Issuer fraud or security block. Kill the token. Ask for a new card if the shopper is still there. Do not retry the same PAN. Do not hop it.
We do not invent a private list of issuer response numbers. Read the family your gateway returned. If the portal renamed it, believe the family, not the nickname.
Next action by family
Do not honor. Soft catch-all. One retry on this MID. Then stop unless this issuer’s file looks like NSF. Do not cascade five times. Do not open a “healthier” MID for the same card.
Insufficient funds. Soft. Retry later on this same MID. Do not burn a new account’s cap to chase money that was not there.
CVV / AVS fail. Soft data problem. Retry once with the correct data, or with 3DS if that is your rule. Do not strip CVV to force an auth.
3DS failed. Soft authentication problem. Fall back only if this MID is enrolled and the rule says so. Do not send the same shopper around every 3DS MID.
Pick up card. Hard. Kill the token. Never hop.
Invalid / no account. Hard. Ask a new card. Do not retry this PAN.
Fraud / security. Hard. Stop. Log the BIN. Do not retry for conversion.
After you pick the row
If the family is hard, the cascade must not see that PAN again. If the family is soft, measure whether the retry recovered without stacking chargebacks. That measurement is the pollution calculator.
Do not strip security data. Do not invent a second merchant account as a retry path for a dead card.
Related: MIDs (the account the retry still sits on), Subscriptions (rebill day lists), fraud block vs issuer, Chargebacks (fraud blocks that become disputes).
Procedure
- Read the family your gateway returned.
- Hard fails stop on this account.
- Soft declines may get one retry here. Do not open a new MID for the same card.
- Measure soft retries with the pollution calculator. Dunning owns the rebill day list.
Failure modes
- Treating every decline as retryable.
- Hopping a hard fail onto a spare merchant account.
- Stripping CVV to force an auth.
- Inventing a private issuer code table and ignoring the family.
Worked example
None on this page yet. When one lands it will be a real case: what broke, the number, and what changed. Not a composite.
Glossary
- Soft decline
- Issuer left a path to try again on this merchant account. NSF, some do-not-honor, fixable CVV/AVS.
- Hard decline
- Pick-up, invalid, issuer fraud. Kill the token. Do not hop.
Work with us — We run this job on your accounts. Services
FAQ
- Should every decline go into the cascade?
- No. Hard declines stop. Soft declines may get one retry on this same merchant account. Cascading everything burns caps.
- Can I send a pick-up-card fail to a healthier merchant account?
- No. Kill the token on this account. Hopping a hard fail is how you trash the spare.
- Is this the same as the rebill dunning calendar?
- No. This is the next action on a live auth. Dunning is the day list after a rebill fails.