Library · Payment orchestration · Guide
Wallet decline recovery — claim map
GuideWallet decline recovery — claim mapBack to article
Wallet fail → one card path. Not a MID cascade. Filter the claim. Soft/hard card playbook is a different page.
| Claim | Reality | Do | Do not |
|---|---|---|---|
| Wallet decline = cascade the token to another MID | No. Offer a card (or alternate wallet) path once | Show card form; keep the cart | Hop the same wallet credential across spares |
| Wallet fail is the same as card NSF | No. Often device, bank-app, or network path — not an empty card balance signal | One alternate path; then read any card decline family | Run the NSF day list on a wallet token |
| Auto-retry the wallet five times | No. Burn and friction without a new path | Fail once clearly; offer card | Silent wallet loops |
| Soft/hard card playbook applies before any card auth | No. That map needs a card issuer response. Wallet fail is earlier | Use decline playbook only after a card attempt returns a family | Map wallet errors onto pick-up / NSF rows blindly |
| 3DS on the wallet retry fixes everything | No. Wallet path and 3DS placement are different jobs | Card path first; place 3DS per your rule on that auth | Stack challenges on a dead wallet session |
| There is a good wallet approval benchmark here | No. We do not invent one. Measure your first-try wallet vs card fallback | Type your own rates on first-try / net pages | Paste a slide “wallet should be 95%” |
Filter the claim. A wallet decline is usually a path fail. Offer a card form once. Do not cascade the wallet token. Card soft/hard rules apply only after a card auth exists.
Pairing procedure: Recover a wallet decline with a card path. Topic: Orchestration.
Work with us — We run this job on your accounts. Services