Decline Diagnostics: Find the Root Cause of a Failed Renewal

Someone refused every failed renewal, and the decline code rarely says who. Your retry logic, your gateway, your acquirer and the issuer can each kill a rebill. Most dashboards file all four under one word: declined. This page attributes a failed renewal to the layer that caused it, using the fields you already have. Then it hands the fix to that layer.

Why do recurring payments get declined even when the card is valid?

Most renewal failures are not about the card at all. Soft declines, where a later attempt can still work, are 80% to 90% of all payment failures. About 15% of recurring payments decline in a given billing cycle. A valid card fails when funds, issuer risk rules, transaction flags or your own retry schedule get in the way.

• Issuer state: 51 (not sufficient funds), 59 (suspected fraud) and 61 (exceeds approval amount limit) sit in Visa Category 2, so the issuer cannot approve right now.
• Cardholder instruction: 9G means the customer switched the card off in their banking app, and R0, R1 and R3 are stop orders placed with the bank.
• Corporate policy: 5C is the required code for Visa Payment Controls on commercial cards, so the block sits inside your customer's company.
• Your processor: Stripe's Adaptive Acceptance can block a renewal with the reason low_probability_of_authorization before any bank sees it.
• Your own data: a renewal sent without the recurring indicator reads to the issuer as a fresh card-not-present charge.

The definitions live elsewhere on this site. Issuer decline explains what each code means, and gateway decline codes covers the normalized reasons your processor shows you. This page is the diagnostic spoke. Given one failed renewal, which layer refused it, and what single change fixes that layer? That is also the honest answer to why subscription renewals fail on cards that work fine in a store.

Who actually said no: your retry logic, the gateway, the acquirer or the issuer?

Read the network status before you read the decline code. Stripe splits every failure into three origins: issuer declines, payments your own risk layer blocked, and invalid calls to its application programming interface (API). An outcome of not_sent_to_network means the issuer never saw the attempt. Decline attribution then stops inside your own stack.

Three Visa codes point at the acquirer rather than the cardholder: 03 (invalid merchant), 58 (transaction not allowed at terminal) and 92 (routing failure). A cluster of those on one merchant identifier (MID) is configuration, not credit, when the same banks approve on another MID. Since July 25, 2026 the acquirer also has to make the merchant data in an account verification match the later authorization.

Which decline signals can you act on, and which ones are generic?

Two signals carry real instruction, and one carries none. Insufficient funds and the Mastercard advice codes tell you what to do and when to do it. Do not honor sits in Visa Category 4, the generic bucket, so it carries no diagnosis. A do not honor on recurring charges is therefore a grouping job, not a retry job.

• Not enough money in the account: 40.56% of failures, and the largest single cause by a wide margin.
• Card not allowed for this charge: 8.83%, a permission problem rather than a funding one.
• Blocked at the highest risk level: 7.99%, which is a risk-layer decision and not a bank decision.
• Do not honor: 7.56%, generic by design.
• Generic decline: 5.78%, also unattributed.
• Wrong card number: 4.69%, a data-quality failure in your vault or your checkout.
• Expired card: 1.14%, which is far smaller than most teams assume.

Expired cards are rare partly because network tokens refresh expiry dates for you. A high expired-card share in your own data is a tokenization-coverage finding, not a customer-behavior finding. Visa says the network itself checks with the issuer that the card behind a token is still valid. Visa reports a 4.6% authorization lift on tokenized card-not-present traffic, measured on 2022 data.

What is the difference between a soft and a hard decline on a renewal?

A hard decline is a prohibition, and a soft decline is a permission. After a Visa Category 1 code you must not resubmit that authorization for the same credential. The first retry is already the violation. For Categories 2, 3 and 4, Visa currently permits up to 20 attempts in 30 days.

The split matters more than the label. Soft decline vs hard decline works through the full code lists, and smart retry scheduling covers the cadence. One rule binds both. Visa forbids changing data elements between a decline and a reattempt. Visa names the acquirer identifier, the merchant category code (MCC) and the point-of-sale (POS) entry mode. Moving a failing rebill onto a second MID is a rules breach, not a fix.

How do you separate a credential-drift problem from an issuer-risk problem?

Probe the credential without charging it. A zero-amount account verification asks the issuer whether the card is still good. An 85 response means the account is valid with funds unverified. Real-time Visa Account Updater returns new card data even on a declined attempt, so silence there rules out credential drift.

1. Pull the attempt record: raw decline code, advice code, network status, BIN, MID, billing cycle and attempt number.
2. Send a zero-amount account verification, because a non-zero test authorization for validity has been barred since 24 October 2026.
3. Read the answer: 00 means valid with funds sufficient for the amount, and 85 means valid with funds unverified.
4. Check whether the updater returned anything, since real-time updates come back even on declined attempts.
5. Allow the two business days an account updater file takes to reach you before you call a card dead.
6. Rule out a coverage hole, because commercial, prepaid and single-use virtual card BINs are carved out of the Visa Account Updater mandate.

Do not assume the updater fired. Stripe says it is not possible to identify which cards support automatic updates. Decline analysis by the bank identification number (BIN) takes over from there. Hold the issuer constant, vary the provider, and the gateway layer separates from the issuer layer. In one published case a BIN cohort worth 3% of volume approved at 74% against a 92.2% blended rate. That gap hid about 480,000 euros of declined volume a year.

What data do you need to attribute declines by BIN, MID, billing cycle and attempt number?

Issuer decline diagnostics start at the BIN, not at the code. Log seven fields on every attempt: raw decline code, advice code, network status, BIN, merchant identifier, billing cycle and attempt number. Checkout.com reports that 65% of businesses never receive detailed raw response codes. The first fix is usually plumbing.

• Raw decline code and advice code: at Adyen these are refusalReasonRaw and refusalCodeRaw, and raw acquirer results have to be switched on first.
• Network status: declined_by_network against not_sent_to_network is the gateway vs issuer decline split in a single field.
• API version: network_advice_code and network_decline_code only exist from Stripe API version 2024-12-18.acacia onward.
• BIN: use the eight-digit key, since Visa has issued only eight-digit BINs since April 2022.
• MID and descriptor: Mastercard counts excessive attempts per card acceptor ID, so the MID belongs in the key.
• Billing cycle: a cycle-1 failure points at signup data, a trial-end descriptor or authentication, while a cycle-14 failure points at credential drift.
• Attempt number, deduplicated by card fingerprint rather than charge ID, so your retries do not inflate your own decline rate.

What does a weekly decline diagnostic review look like?

The check is a 30-minute cross-tab with two numeric triggers. Pull the week's declines by code, BIN, MID and billing cycle, then compare them against the prior week. Investigate when the approval rate falls more than 1 percentage point week over week. Also investigate a fall of more than 0.5 points day over day.

1. Check your own 48 hours first: deploys, risk-rule edits and your processor's status page.
2. Deduplicate by card fingerprint, so one root cause does not read as nine separate failures.
3. Split the week's declines by Visa category, then by BIN, then by MID.
4. Look for concentration, because one BIN spiking while other issuers hold flat is an issuer-layer finding.
5. Cross-tab BIN against provider: hold the issuer constant and vary the gateway to expose your own layer.
6. Compare cycle 1 against later cycles, since signup data and credential drift fail for different reasons.
7. Reconcile the integrity-fee lines on your settlement report against your own retry counts.

Decline monitoring for recurring billing is a weekly job because the fix window is weekly. Diagnosis takes one to three days, and a fix lands in one to two weeks. A monthly cadence therefore misses a bad week entirely. Running the breakdown once tells you where the losses sit. Running it weekly tells you when the number moves.

Work the arithmetic on an example. Assume Northbeam Analytics has 20,000 subscribers and 4% of renewals fail each month. That is 800 failed attempts. If the published mix holds, about 324 of those are not enough money and about 9 are expired cards. Grouping the same 800 by BIN and MID would surface 110 failures on one acquirer MID returning 03 and 58. That is a configuration fix rather than a dunning problem. The mix is illustrative, not a measured result for your book.

1. Capture the raw decline code and the advice code on every attempt, not only your processor's normalized reason.
2. Check the network status first, so a block inside your own stack is never filed as an issuer decline.
3. Stop retrying on a Visa Category 1 code or a Mastercard advice code of 03 or 21.
4. Follow the issuer's timing when advice codes 24 to 30 name a wait of 1 hour to 10 days.
5. Send stale credentials to the account updater instead of retrying the old card number.
6. Notify the customer in writing and allow at least 7 calendar days to pay another way.
7. Keep attempt counts inside 20 in 30 days on Visa and 10 in 24 hours on Mastercard.
8. Reconcile integrity-fee lines on your statement against your own retry counts each month.

Which fixes belong to each layer, from account updater to retry timing to dunning?

Each layer has one fix, and the fixes are not interchangeable. Credential drift goes to the account updater, and issuer state goes to retry timing. The MID layer goes to configuration, and your own layer goes to flags and caps. Dunning closes the loop: Visa requires written notice and at least 7 calendar days to pay another way.

• Your layer: cap attempts at eight or fewer, fix the recurring indicator and POS entry mode 10, and store the network transaction ID.
• Gateway layer: turn on raw acquirer responses, review your own block list, and check whether the processor pre-blocked the attempt.
• Acquirer and MID layer: compare approval rates across MIDs, and make the verification data match the authorization data.
• Issuer layer: retry on advice codes 24 to 30, which name waits from 1 hour to 10 days.
• Credential layer: run Visa Account Updater or Mastercard Automatic Billing Updater on a schedule, not only after a decline.
• Customer layer: one dunning email, a self-serve card update link, and a 7 day grace period before access changes.

Retry harder is not a layer fix. Stripe recommends a maximum of eight retries. Stripe warns that extra attempts can read as fraud, which depresses approval on legitimate charges. Mastercard meters the same behavior, counting 10 declines in 24 hours on one card at one acceptor. Once the question "which issuer is declining my rebills" has an answer, the retry schedule stops doing the diagnosis for you.

Frequently Asked Questions