Skip to main content
Card class: Non-Hero • Category: Payment Gateway

​
At a glance

The breakdown of failed-charge reasons in the period, ranked by count. The companion to rec_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 countsTop-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 taxonomyPass-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.
CurrencyCurrency-neutral (it’s a count distribution).
First-attempt onlyYes. Retried-and-still-failed counts the original reason. Retried-and-recovered no longer appears in the failure pool.
Cancellations / SKIPPEDExcluded.
Time window7D vsP rolling default.
Alert triggerReason-cluster spike: any single reason rising >50% absolute count vsP. sentiment_key: decline_rate.
Reading hintsEXPIRED_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.
Rolesowner, 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:
RankReason codeCount% of declinesvsP (count delta)Likely cause
1INSUFFICIENT_FUNDS10231.2%+18End-of-month thin-wallet cohort
2EXPIRED_CARD8826.9%+30Issuer reissue cycle
3DO_NOT_HONOR6419.6%+12Issuer-side fraud flag (BIN cluster suspected)
4TRANSACTION_NOT_PERMITTED216.4%+3Mostly closed accounts post-fraud event
5PROCESSING_ERROR185.5%+5Transient processor faults
6CARD_NOT_SUPPORTED144.3%-2Prepaid debit / digital-only cards being declined for recurring
7AUTHENTICATION_REQUIRED113.4%+9EU SCA mis-flag on UK customers
8other92.7%-1Long tail
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

CardWhy pair it with Top Decline Reasons
rec_decline_rateThe headline rate this card decomposes.
rec_success_rateThe complement view.
rec_top_payment_methodsMethod-by-reason cross-tab reveals (e.g.) “Amex declines on AUTHENTICATION_REQUIRED”.
rec_threedsecure_abandon_rateIf AUTHENTICATION_REQUIRED is climbing, abandons are likely rising too.
rec_volume_trendVolume troughs frequently coincide with reason-cluster spikes.
Stripe / Shopify Payments decline reasonsThe native processor view; codes match.
Recurly rec_top_decline_reasonsCross-platform pattern compare.

​
Reconciling against the vendor’s own dashboard

Where to look in the Recharge merchant portal: 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:
ReasonDirectionWhy
Reason normalisationSlight differencesDifferent 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 bucketingBoundary days offRecharge admin: store TZ. Vortex IQ: UTC.
Retry-resolved declinesTheirs may show 1 fewer countIf 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:
ComparisonExpected relationshipWhen divergence is legitimate
rec_top_decline_reasons ↔ underlying processor decline reasonsShould match closelyRecharge passes through processor codes; the same decline shows up in both dashboards.

​
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 or book a demo to see this metric running on your own data.