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.
| What it counts | COUNT(charges WHERE status = ERROR) ÷ COUNT(success + error in window) × 100. First-attempt declines on charges first attempted in the window. |
| Charge type breakdown | Recurring rebill declines dominate (typically 80, 95% of all declines). Recharge Checkout first-orders decline at a lower rate (fresh card, customer engaged). Plan-swap declines are rare. |
| Currency | Currency-neutral (it’s a rate). |
| Refunds / disputes | Not relevant (post-success outcomes). |
| Cancellations / SKIPPED | Excluded entirely. |
| Time window | 7D vsP rolling default. |
| Alert trigger | >8% absolute, OR +25% relative spike vs prior week. sentiment_key: decline_rate (gauge inverted: lower is good). |
| Reason breakdown | This card is a single rate; per-reason split is in rec_top_decline_reasons. |
| Recovery, not visible here | Recharge dunning retries 1, 4 times over 3, 7 days. Recovered ones flip to SUCCESS and stop counting here. Permanent failures feed involuntary churn. |
| 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.| Outcome on first attempt | Charges | % of attempted |
|---|---|---|
| Successful | 4,810 | 93.6% |
| Declined: INSUFFICIENT_FUNDS | 102 | 2.0% |
| Declined: EXPIRED_CARD | 88 | 1.7% |
| Declined: DO_NOT_HONOR | 64 | 1.2% |
| Declined: CARD_NOT_SUPPORTED | 14 | 0.3% |
| Declined: TRANSACTION_NOT_PERMITTED | 21 | 0.4% |
| Declined: PROCESSING_ERROR (transient) | 18 | 0.4% |
| Declined: other / minor reasons | 20 | 0.4% |
| Total declined | 327 | 6.4% |
| Total attempted | 5,137 | 100% |
- 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
| Card | Why pair it with Decline Rate |
|---|---|
rec_success_rate | Complement view. |
rec_top_decline_reasons | The first card to open when this rate jumps. |
rec_top_payment_methods | Method mix often explains rate movement. |
rec_volume_trend | Decline-rate spikes coincide with volume troughs. |
rec_chargeback_rate | Different (post-success), but high decline + high chargeback = card-on-file age problem. |
| Stripe / Shopify Payments authorisation rate | Underlying processor view. |
Shopify checkout_abandonment_rate | Storefront analogue for first-purchase decline. |
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:| Reason | Direction | Why |
|---|---|---|
| Time zone bucketing | Boundary days off | Recharge admin: store TZ. Vortex IQ: UTC. |
| Retry-queue snapshot timing | Brief discrepancy | A failed charge that succeeds on retry day-3 disappears from this card retroactively. Catches up on next sync. |
| Cancelled-during-dunning treatment | Theirs may exclude cancelled retries, ours includes them as ERROR | If a customer cancels their subscription mid-dunning, the in-flight failed charge stays as ERROR in our view (the attempted charge did fail). Recharge admin sometimes filters these out. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
rec_decline_rate ↔ Stripe / Shopify Payments decline rate | Recharge usually higher | Recharge rebills hit older cards; decline rate runs 1, 3 pp higher than fresh-checkout traffic on the same processor. |
rec_decline_rate + rec_success_rate ≈ 100% | Yes | Complementary. |
rec_decline_rate ↔ recurly.rec_decline_rate | Similar shape | Recurly’s multi-processor failover can pull its rate 1, 2 pp lower for high-volume merchants. |
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.