At a glance
The percentage of attempted Recharge subscription rebills that failed on the first attempt: declined by the underlying processor / issuer, fraud-flagged, or hit a soft fault. The complement of rec_success_rate. On Recharge specifically, decline rate is dominated by aging card-on-file (expired cards, replaced cards after a fraud event, closed accounts), NOT by issuer fraud filters in the way fresh-checkout traffic is. Recharge’s automated retry recovers a portion over 3, 7 days; this card is first-attempt only.
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.- 6.4% is at the upper edge of healthy but below the 8% absolute threshold. The spike vs prior period (+25.5%) is what triggered the alert; the absolute level is still tolerable. Open
rec_top_decline_reasonsto see which reason cluster grew. - EXPIRED_CARD at 88 (+30 vs prior week) suggests a card-batch reissue. Issuers reissue cards in waves; if a major US issuer reissued April-expiry cards in late-April, customers whose new cards haven’t been pushed via Account Updater fall into this bucket. Recharge Smart Dunning should recover most as customers update card-on-file in their portal.
- INSUFFICIENT_FUNDS at 102 is structural for any subscription business. End-of-month billing concentration (subscribers paid on 1st of next month) means rebills on 28, 30 of the prior month catch some customers between paychecks. Moving rebill day to mid-month for thinner-wallet segments lifts success.
- DO_NOT_HONOR cluster of 64 might indicate a fraud-flag wave. If many of those 64 share the same BIN range, the issuer may have flagged Daily Greens as a “subscription scam” risk after a customer complained. Clear up via merchant escalation; Recharge support has standard playbook.
- POS-style card-present declines do NOT exist on Recharge. All Recharge charges are card-not-present (saved tokens). So unlike Viva or Stripe Terminal, there’s no “POS noise” to subtract.
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 → Analytics → Charges → Failure rate for the same window. The Charges → Failed filter shows the underlying ERROR list; the Subscriptions → Dunning view shows what’s currently in retry. Why our number may legitimately differ from the Recharge merchant portal:
Cross-connector reconciliation:
Known limitations / merchant FAQs
“What’s a normal decline rate for Recharge?” 4, 7% on first attempt is healthy for DTC subscription brands. Below 4% suggests very strong card-on-file hygiene (or aggressive Account Updater coverage). Above 8% needs investigation. Q1 (January, February) typically runs 1, 2 pp higher across the industry. “My decline rate spiked on a single day, what happened?” The most common cause on Recharge: a cohort billing day landed and a wave of expired-card customers all attempted at once. Cross-reference withrec_top_decline_reasons and the date pattern. If EXPIRED_CARD jumped on the day matching a major issuer’s reissue cycle (often around tax-year-end in the US, calendar quarter ends), that’s the explanation.
“How does Recharge dunning recovery work?”
Configurable. Standard plans get 4 retries over 7 days (day 1, 3, 5, 7); Pro plans can configure custom retry schedules. Each retry hits the underlying processor; the issuer may approve later attempts as the customer’s account refreshes. Dunning emails (“your payment failed, please update your card”) fire on retry 1 and retry 3 typically.
“Why does Recharge decline rate run higher than Stripe one-time decline rate?”
Card age. Recharge is rebilling cards that the customer entered weeks, months, or years ago. Issuers reissue cards regularly; some never get refreshed via Account Updater. Stripe stand-alone (one-time checkout) gets a fresh card each transaction, so the card age problem doesn’t exist.
“What can I actually do to lower decline rate?”
Three top-ROI levers. (1) Enable Account Updater (covered in success rate FAQ). (2) Pre-emptive customer-portal email “your card expires in 30 days, update now”. (3) Move rebill-day for thin-wallet segments (e.g. customers who repeatedly fail on 28th of month) to mid-month after pay day; some Recharge merchants offer “billing-day choice” in customer portal.
“Recurly has multi-processor failover, does Recharge?”
No. Recharge is bound to a single processor per Shopify store (whatever’s configured in Shopify Payments / Stripe / Authorize.Net). If the primary processor declines, Recharge does not retry on a backup processor. This is one of Recurly’s competitive pitches against Recharge for high-volume merchants.
“3DS, SCA-required declines, do they show here?”
EU/UK Recharge merchants doing PSD2 SCA on rebills (rare; most rebills qualify as MIT exemption) may see SCA-required failures. They show up as AUTHENTICATION_REQUIRED in the decline reasons. Properly configured MIT exemption should make these near-zero on subscription rebills.
“Why do involuntary churn metrics not match decline rate × subscriber count?”
Involuntary churn = subscribers Recharge couldn’t recover after all retries. It’s a subset of the decline cohort: most declined-but-recovered customers don’t churn. The ratio (involuntary churn ÷ first-attempt decline rate) tells you how good your dunning is. 30, 40% retry-out is the industry baseline; <25% is excellent dunning copy + Account Updater coverage.