## TL;DR

Retry insufficient_funds (the customer may get paid soon) but do not blindly retry do_not_honor (the issuer is refusing without a reason, and retries rarely succeed). For do_not_honor, ask the customer to contact their bank or use a different card; for insufficient_funds, schedule retries over several days. Log decline codes to tune the strategy.

## Error

```text
```text
code: do_not_honor
code: insufficient_funds
```
```

## Steps

1. Capture the decline code on every failed payment intent and store it with the invoice.
   Expected: You have the data to branch retry logic.
2. For insufficient_funds: schedule retries at increasing intervals (day 1, 3, 7) since balances change.
   Expected: Retries land when funds may exist.
3. For do_not_honor: retry at most once, then prompt the customer for a different payment method or to call their bank.
   Expected: You stop burning retries the issuer will keep refusing.
4. Send code-specific messaging: insufficient_funds gets a gentle nudge, do_not_honor gets contact-your-bank guidance.
   Expected: Customers get actionable advice instead of a generic failure email.
5. Review decline-code distributions monthly and adjust retry counts per code.
   Expected: The strategy improves with real data.

## When to use

- You design dunning retry logic
- Failed payments carry do_not_honor or insufficient_funds
- You want code-aware instead of blind retries

## When not to use

- The decline is authentication_required (needs 3DS, not retries)
- Fraud tools blocked the payment (different signals)
- The card is expired or invalid (update the card, do not retry)

## Compatibility

Stripe Payments; decline codes on payment intents and charges. Smart Retries product automates code-aware retrying.

## Variant phrasings

### ### Stripe do_not_honor retry or new card

### ### insufficient_funds retry schedule Stripe

### ### card_declined codes retry strategy

## Root cause

Decline codes carry the issuer's intent: insufficient_funds is a temporary state that time can fix, while do_not_honor is a refusal the issuer will not explain and usually will not reverse on retry. Treating them the same wastes retries on one and gives up too early on the other.

## Edge cases

- Some issuers soft-decline with do_not_honor for velocity; a single retry after 24h is still reasonable
- Debit cards show insufficient_funds more often around payroll cycles; time retries accordingly
- After 3-4 failures on any code, switch to customer outreach over more retries

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_apiXRPsx4FnzzNvGXXKLig