Skip to main content
Metrics type: Supporting Metrics • 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.

​
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:
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

​
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: Cross-connector reconciliation:

​
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.