# do not try again decline code on a subscription invoice: stop retrying

TL;DR: do not try again is a hard decline, usually do_not_honor with strict issuer guidance. Stop every automatic retry immediately and ask the customer for a different payment method. Each extra attempt raises the chance the issuer flags the card for fraud.

```text
do not try again decline code on a subscription invoice: stop retrying
```

1. Read the decline code on the failed PaymentIntent; confirm it is do_not_honor or carries do-not-try-again guidance. Expected: the code is logged on the charge.
2. Disable Smart Retries and any custom retry loop for this invoice. Expected: no further attempts fire.
3. Email the customer asking for an alternate card; suggest they check with their bank. Expected: the customer provides a new method or confirms the old one.
4. If the customer insists the card is fine, wait at least 24 hours before one manual retry. Expected: a single spaced retry sometimes passes after the issuer clears the flag.
5. Update your retry config to treat this code as terminal. Expected: future invoices with this code go straight to dunning.

When this applies:
- do_not_honor with do-not-try-again guidance
- Issuer fraud blocks
- Stolen-card declines

When it doesn't:
- Soft declines like insufficient_funds or try_again_later, where retries are legitimate
- authentication_required, which needs customer action instead

Compatibility: Stripe API 2025-XX; Smart Retries; any card processor surfacing issuer decline codes.

### do_not_honor on subscription renewal, what to do
Stop retries, ask for another card.

### issuer says do not try again, subscription billing
The issuer has made a decision; respect it and go around it with a new method.

### hard decline on invoice, stop retries
Hard declines are terminal by definition; retry logic should not touch them.

Why it happens: the issuer has decided this transaction should not be attempted again, often because of suspected fraud, a blocked card, or a restriction on the account. Retrying looks like a brute-force attack on the card.

Edge cases: some issuers return do_not_honor for everything including soft problems; one spaced manual retry is the test, not ten rapid ones. If the same customer hits this on a replacement card, suspect account-level blocking and ask them to call the bank.

## Provenance

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