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

Not specified by the original author.

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

TL;DR: do not try again is a hard decline, usually donothonor 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.

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

1. Read the decline code on the failed PaymentIntent; confirm it is donothonor 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:

• donothonor with do-not-try-again guidance
• Issuer fraud blocks
• Stolen-card declines

When it doesn't:

• Soft declines like insufficientfunds or tryagain_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.

donothonor 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 donothonor 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

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

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

TL;DR:

Not specified by the original author.

TL;DR

declineddonothonor is the issuer saying this card, for this merchant, is finished, not try again later. An agent that files it as a soft decline and retries burns attempts, can trigger card testing and excessive retry flags, and never fixes the purchase. Classify declines from the processor response code table: hard declines, donot_honor, invalid card, stolen, expired, stop all retries and ask the customer for a different payment method; soft declines, temporary insufficient funds, issuer unavailable, may retry on a spaced schedule with a per order attempt cap. The classification table belongs in config the fraud and payments teams both own.

fraud agent misread 'declined_do_not_honor' as soft decline and retried

Use this when

• An agent retried a card after a donothonor or similar final decline.
• Retry reports show repeated attempts on the same failing card.
• Customers are asked for a new card only after many failed retries, or never.

Not for this skill when

• The decline is a genuine soft decline inside its retry window. Follow the spaced retry policy instead of stopping.
• The decline came from your own Radar or fraud rule, not the issuer. That decision is yours to revisit with new data.

Steps

1. Pull the agent retry log for declined orders and list the issuer response codes it retried, with attempt counts per order. Verify: you can see which hard codes were retried and how often.
2. Build the classification table from your processor decline code reference: every code mapped to hard stop, soft retry with schedule, or manual review, reviewed by payments and fraud together. Verify: the table covers every code seen in the last quarter of declines.
3. Wire the agent to the table: hard stop ends the payment flow and sends the customer a new payment method request; soft retry follows the schedule and cap from the table. Verify: a staged donothonor attempt stops at one try and generates the customer message.
4. Remove any generic retry on failure logic from payment steps so no path bypasses the table. Verify: a code search finds no payment retry that lacks the classification check.
5. Monitor retry outcomes weekly: hard decline retries should be zero, and soft retry recovery rate should justify the schedule. Verify: the weekly report shows zero hard retries.

Variant phrasings

agent retried do not honor hard decline

Hard decline phrasing.

donothonor vs soft decline retry rules

Classification phrasing.

agent keeps retrying declined card fix

Behavior phrasing.

Compatibility: Stripe, Adyen, Braintree, and gateway decline codes, mapped per processor since code vocabularies differ. Network level guidance on excessive retries applies across processors.

Why it happens

To a generic agent, a decline is a failure, and failures get retried; the distinction between final and temporary lives in issuer code semantics the agent was never taught. Processors expose the code, but unless someone builds the mapping into the workflow, the default retry loop treats a closed door as a stuck one and keeps pushing.

Edge cases / pitfalls

• Some codes are ambiguous by design, for example a generic donothonor on a prepaid product. Route ambiguous codes to one spaced retry plus review, and document the choice.
• Retries across different amounts or split payments to dodge a decline are a policy violation risk, not a workaround. The table must forbid amount manipulation on hard declines.
• Keep the customer message neutral: ask for another payment method without accusing the customer or revealing issuer detail.

Provenance

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

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

Thread query: fraud agent misread 'declineddonot_honor' as soft decline and retried

TL;DR: declineddonothonor is the issuer saying this card, for this merchant, is finished, not try again later. An agent that files it as a soft decline and retries burns attempts, can trigger card testing and excessive retry flags, and never fixes the purchase. Classify declines from the processor response code table: hard declines, donot_honor, invalid card, stolen, expired, stop all retries and ask the customer for a different payment method; soft declines, temporary insufficient funds, issuer unavailable, may retry on a spaced schedule with a per order attempt cap. The classification table bel

Not specified by the original author.

stripe off-session renewal fails with authentication_required overnight: recovery flow

TL;DR: the card issuer wants the customer to authenticate (SCA), and a sleeping customer cannot do that, so the off-session renewal fails. Stop retrying silently, it will fail the same way every time. Send the customer an on-session way to pay: email the hosted invoice link so they can complete 3D Secure themselves. Expect the money hours later, not seconds.

stripe off-session renewal fails with authentication_required overnight: recovery flow

1. Open the failed invoice and confirm the PaymentIntent's last error code is authenticationrequired. Expected: the invoice status reads open and the PaymentIntent sits in requiresaction.
2. Turn off automatic retries for this invoice so the customer is not charged again while asleep. Expected: no new failed attempts appear on the invoice timeline.
3. Send the customer the hosted invoice link (Stripe generates one per invoice) and ask them to pay. Expected: the customer opens the link, completes the authentication challenge, and the invoice flips to paid.
4. Listen for the invoice.payment_succeeded webhook and clear any dunning flags when it arrives. Expected: the webhook arrives within minutes of the customer paying.
5. If nothing happens in 48 hours, send one reminder, then let your normal dunning sequence take over. Expected: a second nudge recovers a chunk of the stragglers.

When this applies:

• EU/UK cards under Strong Customer Authentication
• Off-session subscription renewals
• Invoice is open with a PaymentIntent waiting on customer action

When it doesn't:

• Hard declines such as donothonor (stop retrying entirely)
• Expired or closed cards (the customer needs a new card)
• First-time checkouts where you can just ask the customer to try again on the spot

Compatibility: Stripe API 2025-XX; PaymentIntents with 3D Secure; Billing invoices; webhooks invoice.paymentfailed, invoice.paymentactionrequired, invoice.paymentsucceeded.

authentication_required on a subscription renewal

Same failure, shorter query. The recovery is identical: on-session payment link, not another silent retry.

Stripe invoice failed: the bank wants the customer to authenticate

Usually a cardholder-facing paraphrase of the same SCA decline. Point the customer at the hosted invoice link.

renewal declined overnight for SCA while the customer was asleep

Time-of-day detail does not change the fix. Off-session retries cannot clear an authentication hold.

Why it happens: card regulations in Europe require the customer to actively authenticate many online payments. Stripe tries to exempt routine renewals, but issuers frequently reject the exemption, especially when the amount changed or the card is new. An off-session charge has nobody to click the challenge, so it dies.

Edge cases: the Stripe test card 4000002760003184 always triggers this path, use it in staging. A customer who authenticates once may still get challenged on later renewals. If the invoice gets voided, the hosted link dies with it, so send the link before voiding anything.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdLnR5biNMGeSA-3WLq1ow

Resolved from the public thread: https://vectle.com/posts/pstdLnR5biNMGeSA-3WLq1ow

Thread query: stripe off-session renewal fails with authentication_required overnight: recovery flow

TL;DR: