| Category | Typical Code | Share | Retryable | Retry Window | Root Cause | Priority Action |
|---|---|---|---|---|---|---|
| Insufficient Funds | 51, NSF | 28% | Yes | Pay period +1 day | Timing mismatch with pay cycle | Align retry to subscriber pay date |
| Card Expired | 54, 14 | 12% | No | N/A | Stale card on file | Pre-expiry update campaign |
| Generic Error / Do Not Honor | 05, 57 | 22% | Conditional | 24–48 hrs | Issuer policy or unclassified | Instrument by issuer; isolate pattern |
| Account Not Authorized | 62, 41 | 10% | No | N/A | Account restriction or closure | Subscriber notification; update flow |
| Fraud / Risk Block | 59, 63 | 11% | Never | N/A | Issuer fraud score; velocity | Do not retry; flag for review |
| Technical / Timeout | 96, 91 | 4% | Yes | 1–4 hrs | PSP or gateway error | Retry same PSP; escalate if recurring |
| Invalid Card Number / CVV | 14, 82 | 5% | No | N/A | Data entry error or test card | Re-tokenize; update payment method |
| Carrier Billing Limit Exceeded | CB-01 | 5% | Conditional | Monthly reset | Carrier spend cap reached | Retry at billing cycle reset |
| Wallet Insufficient Balance | WL-02 | 3% | Yes | 48–72 hrs | Wallet top-up pending | Notify subscriber; retry after top-up |
The "Generic Error / Do Not Honor" category at 22% is almost always an instrumentation problem, not a real decline reason. When this category is large, it means your PSP or gateway is returning catch-all codes rather than specific reasons. Reducing this through better instrumentation is often the single highest-ROI first step in any billthrough program because it reveals retryable volume that was previously invisible.
| Category | Market Share | vs Global Avg | Retryable | Market-Specific Note |
|---|
| Category | Method Share | Retryable | Optimal Retry Window | Action |
|---|
Start with instrumentation, not rules
Before building retry logic, audit what your PSP is actually returning. If more than 15% of declines are generic codes, your instrumentation is broken. Retry logic built on bad classifications will optimize the wrong things. The first deliverable in any decline program is a mapping of every code your system receives to a taxonomy category.
Separate the retryable question from the retry timing question
These are two different decisions. Whether to retry is determined by the decline category. When to retry is determined by the decline reason within that category. Insufficient funds retries on pay period alignment. Generic errors retry on 24–48 hour intervals. Technical timeouts retry within hours. Conflating these two decisions into a single retry rule is the most common mistake in dunning logic.
Never retry fraud-blocked accounts
Retrying a fraud-blocked account does not recover the subscriber. It increases the issuer's fraud score for that account and reduces the probability of future successful billing. The correct action is notification and payment method update, not retry. This is the clearest example of a retry strategy that actively makes billthrough worse over time.
Measure recovery rate by category, not overall
An overall retry recovery rate of 30% obscures everything important. Insufficient funds may recover at 55%. Fraud blocks recover at 0%. Generic errors may recover at 25% with good timing or 8% with bad timing. The metric that drives optimization decisions is recovery rate by category and by retry attempt number — not the blended rate that appears on most dashboards.
Carrier billing requires its own taxonomy branch
Carrier billing declines do not map cleanly to card taxonomy. Spend limits, network timeouts, and operator policy changes are the primary drivers and none of them behave like card decline codes. Markets with meaningful carrier billing volume — SE Asia, LATAM, parts of Europe — need a parallel taxonomy with different retry rules, different timing, and different escalation paths.