> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Top Decline Reasons, Recharge > Top Decline Reasons for Recharge stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Payment Gateway](/nerve-centre/connectors#connectors-by-type) ## At a glance > The breakdown of failed-charge reasons in the period, ranked by count. The companion to [`rec_decline_rate`](/nerve-centre/kpi-cards/recharge/decline-rate): when the headline rate moves, this card explains why. Reasons are pass-through values from the underlying processor (Shopify Payments / Stripe / Authorize.Net), so the exact codes you see depend on which processor your store uses. Common Recharge clusters: EXPIRED\_CARD, INSUFFICIENT\_FUNDS, DO\_NOT\_HONOR, CARD\_NOT\_SUPPORTED, AUTHENTICATION\_REQUIRED. | | | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | Top-N (default 8) decline reason codes from `/charges` where `status = ERROR`, grouped by `error_type` and `error_code` fields. Each row: count + percentage of total declines + period-over-period delta. | | **Reason taxonomy** | Pass-through from the underlying processor. Stripe `card_declined` codes (insufficient\_funds, expired\_card, card\_not\_supported, do\_not\_honor, etc.); Authorize.Net response codes (Reason 6, 27, 36, etc.); Shopify Payments shows the same codes as Stripe. | | **Currency** | Currency-neutral (it's a count distribution). | | **First-attempt only** | Yes. Retried-and-still-failed counts the *original* reason. Retried-and-recovered no longer appears in the failure pool. | | **Cancellations / SKIPPED** | Excluded. | | **Time window** | `7D vsP` rolling default. | | **Alert trigger** | Reason-cluster spike: any single reason rising >50% absolute count vsP. `sentiment_key: decline_rate`. | | **Reading hints** | EXPIRED\_CARD spike = card-batch reissue or year-end. INSUFFICIENT\_FUNDS spike = end-of-month billing or cohort-wide thin-wallet pattern. DO\_NOT\_HONOR spike = issuer-side fraud filter, often BIN-clustered. AUTHENTICATION\_REQUIRED = SCA / 3DS misconfiguration on EU traffic. | | **Roles** | owner, finance, operations | ## Calculation Calculated automatically from your Recharge data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example "Daily Greens Co". 7-day window 26 Apr 26 to 02 May 26. Top 8 decline reasons: | Rank | Reason code | Count | % of declines | vsP (count delta) | Likely cause | | ---- | --------------------------- | ----- | ------------- | ----------------- | --------------------------------------------------------------- | | 1 | INSUFFICIENT\_FUNDS | 102 | 31.2% | +18 | End-of-month thin-wallet cohort | | 2 | EXPIRED\_CARD | 88 | 26.9% | +30 | Issuer reissue cycle | | 3 | DO\_NOT\_HONOR | 64 | 19.6% | +12 | Issuer-side fraud flag (BIN cluster suspected) | | 4 | TRANSACTION\_NOT\_PERMITTED | 21 | 6.4% | +3 | Mostly closed accounts post-fraud event | | 5 | PROCESSING\_ERROR | 18 | 5.5% | +5 | Transient processor faults | | 6 | CARD\_NOT\_SUPPORTED | 14 | 4.3% | -2 | Prepaid debit / digital-only cards being declined for recurring | | 7 | AUTHENTICATION\_REQUIRED | 11 | 3.4% | +9 | EU SCA mis-flag on UK customers | | 8 | other | 9 | 2.7% | -1 | Long tail | ```text theme={null} Diagnostic priorities (in order of expected ROI): 1. EXPIRED_CARD spike (+30 vsP, +52%) → enable / verify Account Updater → email "card expires soon" 30 days ahead 2. AUTHENTICATION_REQUIRED spike (+9 vsP, +450%) → SCA exemption mis-config → MIT exemption flag missing on rebill API call 3. DO_NOT_HONOR cluster → escalate via Recharge support if BIN-concentrated 4. INSUFFICIENT_FUNDS rise → not directly fixable, but billing-day choice helps ``` What the merchant should notice: 1. **EXPIRED\_CARD jumped 52% week-over-week.** This is highly suspect of a card-batch reissue. Check if a major issuer (Chase, Capital One, Bank of America) reissued a tranche of cards with new expiry dates in late April. Account Updater would auto-resolve most of these. Without it, the customer must update their card-on-file in the portal. 2. **AUTHENTICATION\_REQUIRED rose from 2 to 11.** Small absolute number but +450% relative. On Recharge, recurring rebills should NOT trigger SCA, MIT (Merchant Initiated Transaction) exemption applies for subscription billing. If this code appears at all on rebills, the MIT flag is not being passed correctly to the underlying processor. Bug. 3. **CARD\_NOT\_SUPPORTED at 14 declines** is mostly customers who paid with a prepaid debit card or a digital-only card during signup, neither of which supports recurring authorization. Recharge can flag these at signup with proper validation; they're an acquisition-quality issue not a decline-fix issue. 4. **DO\_NOT\_HONOR at 64** is the hardest to action because issuers don't disclose the real reason. If clustered to one BIN, it's a fraud-flag wave (escalate to Recharge support, who can engage with issuer). If spread across BINs, it's noise. 5. **INSUFFICIENT\_FUNDS at 102** is the largest cluster but the least actionable, customers genuinely don't have funds at rebill moment. Long-term fix: offer billing-day choice, allow customers to align rebill with payday. ## Sibling cards merchants should reference together | Card | Why pair it with Top Decline Reasons | | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | [`rec_decline_rate`](/nerve-centre/kpi-cards/recharge/decline-rate) | The headline rate this card decomposes. | | [`rec_success_rate`](/nerve-centre/kpi-cards/recharge/success-rate) | The complement view. | | [`rec_top_payment_methods`](/nerve-centre/kpi-cards/recharge/top-payment-methods) | Method-by-reason cross-tab reveals (e.g.) "Amex declines on AUTHENTICATION\_REQUIRED". | | [`rec_threedsecure_abandon_rate`](/nerve-centre/kpi-cards/recharge/3ds-abandonment-rate) | If AUTHENTICATION\_REQUIRED is climbing, abandons are likely rising too. | | [`rec_volume_trend`](/nerve-centre/kpi-cards/recharge/volume-trend) | Volume troughs frequently coincide with reason-cluster spikes. | | Stripe / Shopify Payments decline reasons | The native processor view; codes match. | | Recurly [`rec_top_decline_reasons`](/nerve-centre/kpi-cards/recurly/top-decline-reasons) | Cross-platform pattern compare. | ## Reconciling against the vendor's own dashboard **Where to look in the Recharge merchant portal:** [admin.rechargepayments.com](https://admin.rechargepayments.com). The closest comparable view is **Recharge Admin → Charges → Failed → group by error code**. The CSV export from this view gives the same ranked breakdown. Some reason codes only appear in the underlying processor's dashboard (Stripe Radar / Shopify Payments dispute view) with extra context Recharge admin doesn't surface. **Why our number may legitimately differ from the Recharge merchant portal:** | Reason | Direction | Why | | --------------------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Reason normalisation** | Slight differences | Different processors use different code names for the same underlying decline. Our engine normalises some (e.g. Stripe `card_declined.expired_card` and Authorize.Net Reason 8 both map to `EXPIRED_CARD` in our taxonomy). Recharge admin shows raw codes. | | **Time zone bucketing** | Boundary days off | Recharge admin: store TZ. Vortex IQ: UTC. | | **Retry-resolved declines** | Theirs may show 1 fewer count | If a charge failed with EXPIRED\_CARD on day 1 then succeeded on day 4 retry (because Account Updater pushed a new card), our snapshot taken between day 1 and day 4 still shows the EXPIRED\_CARD; Recharge admin in retrospect may purge it. | **Cross-connector reconciliation:** | Comparison | Expected relationship | When divergence is legitimate | | ---------------------------------------------------------------- | --------------------- | -------------------------------------------------------------------------------------- | | `rec_top_decline_reasons` ↔ underlying processor decline reasons | Should match closely | Recharge passes through processor codes; the same decline shows up in both dashboards. | ***
Documentation cross-reference * [`recurly.rec_top_decline_reasons`](/nerve-centre/kpi-cards/recurly/top-decline-reasons) * [`stripe.stripe_top_decline_reasons`](/nerve-centre/stripe/stripe_top_decline_reasons)
## Known limitations / merchant FAQs **"What does DO\_NOT\_HONOR actually mean?"** It's a generic-reject from the issuer with no specific reason disclosed. Could mean: fraud-flag, suspected-account-takeover, recurring-rejection-policy, account-on-hold, daily-velocity-limit-hit. The issuer doesn't say. Practical response: if clustered to one BIN range, it's likely a fraud-flag wave the issuer triggered (escalate via Recharge support); if spread across BINs it's noise. **"How do I lower EXPIRED\_CARD?"** (1) Enable Account Updater via your underlying processor (Visa AU, Mastercard ABU, Amex CARD Refresher). (2) Email "your card on file expires in 30 days, update now" 30 days before expiry. (3) Customer-portal CTA prominent on the dashboard. The first lever does most of the work; the second and third catch the rest. **"Why am I seeing AUTHENTICATION\_REQUIRED on rebills? I thought subscriptions were exempt."** PSD2 SCA does grant MIT (Merchant Initiated Transaction) exemption for recurring rebills, BUT the merchant must flag the transaction as MIT in the API call to the underlying processor. If your Recharge integration was set up before MIT exemption support landed, or your processor is misconfigured, the exemption isn't being passed. Open Recharge support ticket; they have a standard config check for this. **"INSUFFICIENT\_FUNDS is my biggest cluster, what should I do?"** Hardest to reduce because you don't control customer cash flow. Two practical levers: (1) offer billing-day choice (let customer align rebill with payday), (2) if a customer fails 2+ months in a row with INSUFFICIENT\_FUNDS specifically, their plan is mis-priced for them, offer a downgrade rather than churning them. **"CARD\_NOT\_SUPPORTED, why does this happen?"** Some cards don't permit recurring authorization: most prepaid debit cards, some virtual / digital-only cards, some corporate cards with strict policy. The customer can pay with the card once but the card refuses the saved-token rebill on subsequent attempts. Best fix: validation at signup, refuse cards that don't support recurring (Recharge supports this via the underlying processor's card-token capabilities check). **"PROCESSING\_ERROR, is that on the processor or on me?"** Almost always transient processor / network errors. They auto-retry on the next dunning cycle and usually succeed. If you see a sustained spike (more than 1, 2% of all attempted), check the underlying processor's status page. **"My reasons differ from Recharge admin, why?"** Reason normalisation. Different processors call the same decline different things; we normalise some into a unified taxonomy. Recharge admin shows raw codes. The counts should match the totals; the labels may differ. **"Can I see decline reasons by SKU / by plan?"** Not directly on this card. The cross-tab is in the Recharge admin under **Charges → Failed → group by product**. We're adding a SKU-by-reason matrix on the roadmap. *** ### Tracked live in Vortex IQ Nerve Centre *Top Decline Reasons* is one of hundreds of KPI pulses Vortex IQ tracks across Recharge and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.