Recovery Rate

50–70%

Soft Decline

Stripe Decline Code · Glossary

withdrawal_count_limit_exceeded

Recoverable·50–70%·Updated May 2026

What It Means

What withdrawal_count_limit_exceeded actually means.

withdrawal_count_limit_exceeded fires when the customer has hit the maximum number of withdrawals or debit transactions permitted on their account within a defined time period — the card or bank account is active, the funds may be present, but the issuing bank has capped how many times money can leave the account in a given window. It is a soft, time-bound decline — the account resets automatically when the period rolls over, making this one of the more recoverable codes in Stripe's taxonomy once the reset window is correctly identified.

Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →

Why It Happens

The root causes.

1Savings account federal withdrawal limit — The most structurally common cause: savings and money market accounts in the US are historically limited to 6 withdrawals per monthly cycle (Regulation D legacy rules) — customers paying subscriptions from savings-linked debit cards hit this ceiling and trigger the code mid-cycle
2Bank-imposed daily or monthly debit cap — Many issuing banks, particularly in India, Southeast Asia, and Latin America, impose hard limits on the number of debit transactions per day or month on basic checking and debit accounts — subscription charges hitting on a day where the customer has already maxed their debit count trigger withdrawal_count_limit_exceeded
3Prepaid card reload cycle limit — Prepaid card products often restrict not just spending amounts but transaction frequency within a reload cycle — a subscription firing late in the cycle hits the count ceiling before the customer reloads
4Corporate card transaction frequency cap — Business-issued cards with finance-team-enforced transaction count limits return this code when a merchant's subscription charge pushes the card over its period count ceiling
5Multiple subscriptions on same card — cumulative count — A customer with several SaaS subscriptions billing on the same day from the same card can collectively exhaust their transaction count limit — your subscription is simply the one that tips them over the threshold

What NOT to Do

Common mistakes that make it worse.

✕ Don't retry immediately or within the same withdrawal period

The count limit is enforced within a defined rolling window — retrying within that same period produces the exact same failure. Worse, each retry attempt itself counts as an additional withdrawal attempt at some issuers, accelerating the customer toward a harder block or fraud flag. Wait for the period to reset before any retry.

✕ Don't conflate it with card_velocity_exceeded and apply the same retry logic

While these codes are cousins, card_velocity_exceeded is typically about spending amount; withdrawal_count_limit_exceeded is purely about transaction frequency count. The reset window and customer communication differ meaningfully — a spending cap reset on a credit card follows a statement cycle; a withdrawal count limit on a savings account follows a calendar month boundary. Applying identical timing to both underperforms on both.

✕ Don't send an alarming payment failure email for what is often a same-day recoverable event

Many withdrawal_count_limit_exceeded failures on daily debit count limits reset at midnight — firing a "your payment failed, please update your card" email over what will self-resolve in hours creates unnecessary customer anxiety and drives card update abandonment on accounts that need zero changes.

Retry Timing

Optimal retry schedule.

withdrawal_count_limit_exceeded is a period-reset-aware retry code — the entire strategy hinges on identifying the reset window type.

Recovery Benchmark

What good looks like.

Metric	Result
Overall recovery rate (all sub-types)	50–70%
Recovery on daily count reset (silent retry)	65–75% — resets within 24 hours
Recovery on monthly savings limit	45–60% with correctly timed retry
Recovery on prepaid cycle limit	30–45% (depends on customer reload behavior)
Recovery on corporate count cap	15–20% (alternate method dependent)
Recovery with blind immediate retries	8–12% (hits same count window)

A 65%+ overall recovery rate is achievable on withdrawal_count_limit_exceeded when your retry scheduler is period-reset-aware. The daily debit limit sub-type alone — handled with a 25-hour silent retry — recovers at 65–75% with zero customer interaction. This is one of the rare codes where the automation does almost all the work if the timing is right.

At Scale

How to handle it at scale.

Automated

✓Webhook trigger: invoice.payment_failed → check failure_code === 'withdrawal_count_limit_exceeded' → immediately classify limit type using card BIN (savings-linked debit, prepaid, corporate, consumer checking) and customer geography
✓Period-reset-aware retry scheduler:
✓Daily limit BIN → schedule silent retry at hour 25–28 (midnight reset + buffer)
✓Weekly rolling cap → schedule retry at Day 7 + Day 8 window
✓Monthly savings/Reg D limit → schedule retry Day 1 of next calendar month; email customer Day 5 with soft notification
✓Corporate count cap → skip retry, trigger alternate payment method email immediately
✓Silent retry execution: For daily and weekly resets, retry in the background with zero customer-facing output — if the retry succeeds, close the event silently; only trigger customer communication if both the silent retry and a second attempt fail
✓Email Day 5 for monthly sub-type: Soft framing — "We noticed your payment is temporarily on hold — we'll retry automatically at the start of next month. You can also add a backup payment method to avoid any interruption" — accurate, non-alarming, and drives backup method adoption without demanding immediate card replacement
✓Alternate method prompt — Day 10: For any sub-type where retries haven't resolved by Day 10, present a clear alternate payment method flow — bank transfer, PayPal, credit card — framed as "add a backup payment method to avoid this in the future" rather than "your card failed"
✓Multi-subscription collision detection: If the customer has multiple subscriptions across different products billing on the same day and this failure fires on the last one charged, consider staggering your billing date by 24 hours on retry — this avoids the same-day transaction count collision on subsequent cycles

Manual Escalation

→High-ACV accounts on monthly savings limit: Human outreach on Day 7 if no silent retry success — a personal check-in framed as "your payment is queued for retry — just wanted to make sure you're aware" prevents surprise access restriction and drives proactive alternate method adoption
→Annual plan customers: A large one-time annual charge is more likely to be the transaction that tips a daily or monthly count over the limit — for annual plan customers hitting withdrawal_count_limit_exceeded, offer the option to split into quarterly payments to reduce per-cycle transaction count exposure
→Corporate account count cap exhaustion: Direct conversation with the billing contact about switching to ACH, wire, or Stripe Invoices — corporate finance teams hitting transaction count limits often prefer invoice-based billing as a permanent structural fix
→Recurring pattern — same customer, monthly: If a customer hits withdrawal_count_limit_exceeded on consecutive billing cycles, schedule your retry for the 1st of the month proactively and recommend they add a credit card or bank transfer as a primary method — a savings account with recurring monthly limit friction is not a reliable long-term payment method for subscription billing

FAQs

Frequently asked questions.

What does the Stripe withdrawal_count_limit_exceeded decline code mean?

withdrawal_count_limit_exceeded means the customer has exceeded the maximum number of withdrawals or debit transactions permitted on their account within a defined time period. The card is active and the account may be funded, but the bank has enforced a transaction frequency cap. The restriction resets automatically at the end of the period — making it one of the more recoverable decline codes with correctly timed retries.

What are the most common causes of a withdrawal_count_limit_exceeded error in Stripe?

Common causes include savings account monthly withdrawal limits from legacy Regulation D rules, bank-imposed daily or monthly debit transaction count caps common in India and Southeast Asia, prepaid card reload cycle transaction limits, corporate card finance-team-enforced frequency caps, and multiple SaaS subscriptions billing on the same day collectively exhausting a card's daily transaction count limit.

Should I retry a payment after a withdrawal_count_limit_exceeded decline?

Yes, but only after the limit period resets. For daily transaction count limits, schedule a silent retry at 25–28 hours. For monthly savings account limits, retry on the 1st of the next calendar month. For corporate card count caps, skip retries and route to an alternate payment method immediately. Never retry within the same withdrawal period — it will always fail and may trigger additional bank flags.

Should I notify my customer when Stripe returns withdrawal_count_limit_exceeded?

Not immediately for daily or weekly limit sub-types. Run a silent background retry at the period reset window first — if it succeeds, no customer notification is needed. Only send a customer email if both the silent retry and a follow-up attempt fail, or if the sub-type is a monthly savings limit where a 5-day notification helps the customer plan or add a backup payment method.

What is the recovery rate for Stripe withdrawal_count_limit_exceeded failures?

Overall recovery rates are 50–70% across all sub-types. Daily transaction count limit sub-types recover at 65–75% with a correctly timed 25-hour silent retry. Monthly savings limit sub-types recover at 45–60% with a month-boundary retry and a Day 5 customer notification. Corporate card count caps recover at only 15–20% and require an alternate payment method switch. Blind immediate retries recover only 8–12%.

What to do next

You are here

withdrawal_count_limit_exceeded

Decline code reference

↓→

Check recoverability

Stripe Failure Lookup

See what's recoverable — and what isn't →

↓→

Then

Automate recovery for every decline code →

Before you retry

Most withdrawal_count_limit_exceeded failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.

See what withdrawal_count_limit_exceeded costs me →

Stop leaving revenue on the table

withdrawal_count_limit_exceeded is recoverable. Most teams don't have the retry logic to prove it.

Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.

See what's leaking →All 30 decline codes →