Home / Guides

What a do_not_honor or generic_decline means on a Stripe renewal

Updated November 5, 2026

A renewal that fails with do_not_honor or generic_decline was refused without a specific reason. Trying the same card later doesn't reveal why. Here's what Stripe records, how Smart Retries treat the two codes, and a short note you can send.

What the two codes mean

When a subscription renews, Stripe charges a saved card without the customer in checkout. Stripe calls that off-session. The card issuer's systems decide whether to approve it. They look at spending habits, the account balance, and card data such as the expiration date, the address, and the CVC (declines). If the issuer says no, Stripe passes on a decline code.

Two codes don't name a cause. On the decline codes page, do_not_honor means "The card was declined for an unknown reason." generic_decline means "The card was declined for an unknown reason, or Stripe Radar or Adaptive Acceptance blocked the payment." Stripe's next step for both is the same: the customer needs to contact their card issuer for more information.

The code is on the failed payment in the Dashboard. In the API, decline_code on the PaymentIntent's last_payment_error is the same reason, and outcome.reason on the charge uses decline codes too. Card issuers categorize most declines as generic_decline, so the exact reason is often unclear. For privacy and security reasons, issuers discuss the details only with the cardholder, so don't quote a code in the email. A named reason, such as insufficient funds or an expired card, has its own code. Other renewal codes are in the decline code guide.

What can sit behind an unknown reason

Stripe doesn't list a single cause for these two codes. It does say what to inspect. If the card details are correct, ask the customer to contact their issuer. For a clearer look at a generic_decline or do_not_honor, the card declines page says to examine the data that came with the charge. If the CVC check or the Address Verification Service (AVS) check failed when the customer added the card, ask them to confirm both before you charge it again.

The same page says a card issued in one country, used from an IP address in another, might be a legitimate decline because of possible unauthorized use. It also says exceptions happen, particularly when a customer is traveling and uses the card from somewhere else. Separately, customers who use cards issued in a different country from the one where you registered your Stripe account might see an increased rate of declines. Stripe doesn't give a rate. The customer has to contact the issuer to authorize that charge.

Stripe also names common reasons a card payment fails at all: not enough funds or credit, incorrect card data (the number, the CVC, or the expiration date), and suspected fraud, including a large purchase or many transactions in a short time. Not enough funds has its own code. So do a wrong number, CVC, or expiry date. The code fraudulent means Stripe suspects the payment, and Stripe says to present that to the customer the same way as generic_decline. An issuer that won't give a reason can still return do_not_honor or generic_decline. Some cards are restricted as well. FSA and HSA cards are often limited to certain businesses, such as healthcare, and some issuers might not allow purchases from certain countries, or from outside their own. In either case the customer has to ask the issuer about the restriction.

generic_decline is not always the issuer. The code also covers a block by Stripe Radar or by Adaptive Acceptance. Radar blocks high-risk payments, including ones that break a rule you set or that score as high risk. When Stripe blocks a payment, it does not ask the issuer to authorize it. Stripe's example of a blocked payment has outcome.type of blocked and network_status of not_sent_to_network. Its example of an issuer decline has outcome.type of issuer_declined and network_status of declined_by_network. Read those fields before you tell a customer to call their bank.

Adaptive Acceptance, for users with IC+ pricing, can block a payment to avoid network costs, including excessive retry penalties and payments that are unlikely to be authorized. The example outcome uses the reason low_probability_of_authorization. A block at the highest risk level uses highest_risk_level. That reason is on the hard-decline list, covered below. If a rule you configured blocked a payment you recognize as legitimate, find it in the Dashboard and add it to the allow list. Stripe says that does not retry the payment. It stops your other rules from blocking later attempts that match.

Whether a retry helps

Stripe says many failed payments are recoverable, and Billing can retry a failed subscription or invoice payment. Smart Retries uses an AI model to pick the times from time-dependent signals. For new Stripe accounts, Stripe turns Smart Retries on and sets them for up to 8 retries within 2 weeks. You can choose how many attempts, over 1 week, 2 weeks, 3 weeks, 1 month, or 2 months. A custom schedule, with Smart Retries turned off, allows up to three retries, each a set number of days after the previous one. Each failure sends an invoice.payment_failed event. attempt_count on that event is how many attempts have been made, and next_payment_attempt on the invoice is when Stripe will try next.

A retry charges the first saved method in this order: the subscription's default payment method, its default source, the customer's default payment method, then the customer's default source. It runs that method again. It doesn't ask the issuer why the last attempt failed.

Neither do_not_honor nor generic_decline is a hard decline. Stripe won't automatically retry incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, revocation_of_all_authorizations, authentication_required, highest_risk_level, or transaction_not_allowed. For those, retries stay scheduled but only run after a new payment method is added. These two codes aren't on that list, so a scheduled retry can still charge the same card. Stripe also skips retries when no payment method is on file, the card is India-issued, or a Connect account has been disconnected.

A retry only changes when that saved method is charged, unless you have replaced the method. The docs don't say that either of these codes clears on its own. Check the advice code on the charge outcome before you assume another try is welcome. try_again_later means a retry is allowed. do_not_try_again means don't reuse this card for this charge. confirm_card_data means some card detail was wrong. An error can carry an advice code next to the decline code, and neither code tells you which one you received. The advice code do_not_try_again is not the same as the deprecated decline code of that name, which the codes page also defines as an unknown reason. Neither one is on the hard-decline list above, so a scheduled retry can still run unless the outcome reason is on that list.

Stripe recommends no more than eight retries for charges that permit retries. Card networks limit repeat attempts, and extra tries can look like fraud. After the last attempt, your settings cancel the subscription, mark it unpaid, leave it past due, or pause it when it's eligible. See the past_due guide. How retries and reminder emails divide the work is in Smart Retries vs dunning emails.

What the customer can do

Stripe's listed next step for both codes is that the customer contacts their card issuer. The issuer only discusses the decline with the cardholder. If the CVC or the address check failed, the customer needs to confirm those details. If the card is restricted, or the issuer is blocking a charge because of where it comes from, the issuer is who can speak to that. Stripe's next step for an expired card is a different card, and for insufficient funds it is another payment method. For these two codes, another card is what you offer when this one won't be approved, or when the saved details were wrong. Incorrect card data is one of the cases where Stripe says to correct the error or use a different card.

On a renewal the customer wasn't in checkout, so they may not know the charge failed. Stripe's off-session guidance is to tell them, and to ask them to come back to your site. In Stripe's customer emails, turn on Send emails when card payments fail if you want Stripe to send that note. Stripe emails the customer after each failed payment, says the recent subscription payment failed, and links them to update the payment method so a later attempt can succeed. The link can go to a Stripe-hosted page or to a page you host.

On the Stripe-hosted page, the customer can update the payment method for that subscription and pay outstanding invoices, if that applies. If they only update the method, Stripe uses it the next time a payment is scheduled. Stripe doesn't add that hosted link when the subscription is set to send the invoice manually. The hosted link stops working if the subscription becomes canceled, incomplete_expired, or unpaid, or the current renewal period ends. A reminder is most useful while the subscription is still past_due. Because Stripe sends one email after each failure, a retry schedule can mean several notes about one invoice. If you write your own, turn Stripe's failed-payment email off so the customer hears from one sender.

What you should do

Read the outcome before you write. If the payment was blocked and never sent to the network, the issuer didn't make this decision. Check Radar and, on IC+ pricing, Adaptive Acceptance. A rule block that you recognize as legitimate is an allow-list change, and that change doesn't rerun the charge. If the reason is highest_risk_level, treat it as the hard decline it is: retries wait for a new payment method.

If the issuer declined it, don't invent the cause. Don't mention fraud, a lost or stolen card, or the balance. Stripe's guidance, when the code really is fraudulent, lost_card, or stolen_card, is not to share that detail and to present it as generic_decline. These two codes already withhold the reason. Leave it withheld.

Then follow the advice code. try_again_later can wait for the retry schedule, with a light note. do_not_try_again means don't charge this card again for this payment, so ask for a different one even if a retry is still on the calendar. confirm_card_data means ask them to check the details on the card. Point the link at the method Stripe will actually retry. When the subscription has its own default payment method, updating only the customer's default leaves later attempts on the old card.

A message you can send

Don't name the code. Don't threaten to cancel, and don't invent a fee. One link, from an address you read.

Send that note when the outcome is an issuer decline. If Stripe blocked the payment and never sent it to the network, don't tell the customer their bank declined it. If the advice code is do_not_try_again, don't add a line that says you'll try the same card again. If you write a second note, keep this tone.

Where Calmretry fits

Calmretry works on top of your own Stripe account and doesn't replace Smart Retries. It notices failed subscription payments, including ones declined as do_not_honor or generic_decline, and sends a short sequence of gentle reminders from you, each with a secure link to update the card. Emails stop when the invoice is paid, voided, or the subscription is cancelled. It never touches funds or card data. If you use it, turn off Stripe's failed-payment email so your customer hears from you once.

Sources

• Stripe Docs: Decline codes
• Stripe Docs: Declines
• Stripe Docs: Card declines
• Stripe Docs: Automate payment retries
• Stripe Docs: Automate customer emails