← Decline Codes
Soft Decline

Stripe Decline Code · Glossary

card_velocity_exceeded

card_velocity_exceeded fires when the customer has hit a spending ceiling, transaction frequency limit, or credit limit set by their issuing bank — the card itself is valid, the customer is real, and the account is active, but the bank's internal velocity controls are blocking any further charges until the limit resets or is increased.

Recoverable·45–65%·Updated May 2026

What It Means

What card_velocity_exceeded actually means.

card_velocity_exceeded fires when the customer has hit a spending ceiling, transaction frequency limit, or credit limit set by their issuing bank — the card itself is valid, the customer is real, and the account is active, but the bank's internal velocity controls are blocking any further charges until the limit resets or is increased. It is a soft-to-hard decline depending on the limit type — spending caps and daily limits reset automatically, making some occurrences highly recoverable; credit limit exhaustion requires customer action before any retry can succeed.

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

Why It Happens

The root causes.

  • 1Daily or weekly transaction count limit exceededThe issuing bank caps how many individual transactions can be processed within a rolling time window — hitting that count ceiling triggers card_velocity_exceeded regardless of available balance, common on debit accounts and prepaid cards
  • 2Daily or monthly spending cap reachedThe card has an issuer-set or customer-set spending ceiling (common on corporate cards, virtual cards, and prepaid accounts) — once the cumulative spend within the period crosses the cap, all further charges are blocked until the period resets
  • 3Credit limit exhaustedFor credit cards, the customer has used their available credit to the ceiling — the charge would push them over their credit limit, triggering a velocity-style decline
  • 4Card testing / fraud velocity triggerThe bank's fraud engine detected multiple charge attempts in a short timeframe — potentially from card testing activity or duplicate charge attempts — and fired a velocity block to protect the cardholder
  • 5Corporate or virtual card budget limit hitBusiness-issued virtual cards (Float, Brex, Ramp) often have per-card or per-category budget caps set by finance teams — hitting the programmatic budget limit for your merchant category returns card_velocity_exceeded

What NOT to Do

Common mistakes that make it worse.

Don't retry immediately or repeatedly

card_velocity_exceeded from a transaction count or spending cap perspective is time-bound — retrying within the same velocity window that triggered the block will fail identically every time. Rapid successive retries are particularly damaging here: the bank's fraud engine may interpret multiple retry attempts on a velocity-blocked card as card testing behavior and escalate the block from a soft velocity cap to a harder fraud flag.

Don't treat all occurrences identically — the reset window varies wildly

A daily spending cap resets at midnight. A monthly credit cycle resets in 30 days. A corporate card budget resets quarterly. Applying a flat "retry in 3 days" rule to all card_velocity_exceeded failures ignores this variance entirely — you'll retry too early for credit cycle resets and too late for daily cap resets, burning attempts inefficiently at both extremes.

Don't send a generic "update your payment method" email first

Unlike expired_card or restricted_card where a new payment method is the only fix, many card_velocity_exceeded failures self-resolve when the velocity window resets. Leading with a card update CTA for a limit that will reset in 24–48 hours creates unnecessary friction and drives card update abandonment on accounts that would have recovered automatically with a simple retry.

Retry Timing

Optimal retry schedule.

card_velocity_exceeded requires limit-type-aware retry timing — the single most important variable is what type of velocity limit was hit.

Recovery Benchmark

What good looks like.

MetricResult
Overall recovery rate (all sub-types)45–65%
Recovery on daily/weekly cap (silent retry)65–75% — resets automatically
Recovery on monthly credit cycle35–50% with timed retry + email
Recovery on corporate/virtual card budget15–25% (alternate method dependent)
Recovery with blind immediate retries10–15% (hits same velocity window)
Recovery with silent retry at correct reset window+25–35% lift over generic timing

A 60%+ overall recovery rate is achievable on card_velocity_exceeded when your retry scheduler is aware of velocity window types. The biggest single lever is silent retry timing precision — teams that retry at the correct reset window for each sub-type dramatically outperform those using a flat retry interval. For daily cap resets especially, a correctly timed 25-hour silent retry recovers 65–75% with zero customer interaction required.

At Scale

How to handle it at scale.

Automated

  • Webhook trigger: invoice.payment_failed → check failure_code === 'card_velocity_exceeded' → immediately attempt to classify velocity limit type using: customer geography, card BIN (corporate vs. consumer vs. prepaid), account tenure, and charge amount relative to plan price
  • Silent retry scheduler — time-aware: Build limit-type detection into your retry engine:
  • Consumer card + low charge amount → assume daily cap → schedule silent retry at hour 25–28
  • Consumer card + large charge amount (annual plan) → assume credit limit → schedule retry Day 10 + Day 20
  • Corporate/virtual card BIN → assume budget cap → skip retries, trigger payment method switch email
  • No customer email for daily cap sub-type: If your classification indicates a daily/weekly reset, attempt the silent retry first — only trigger customer notification if the silent retry also fails
  • Email Day 3 for credit cycle sub-type: Soft notification — "We had trouble processing your payment — if your card balance was recently high, it may clear up in a few days. We'll retry automatically, but you can also add a backup payment method." — this framing is accurate, non-alarming, and drives backup method adoption without demanding immediate card replacement
  • Alternate method offer — Day 10: For credit limit sub-types that haven't recovered by Day 10, present a clear alternate payment method CTA — the customer's credit limit may not clear in time for your billing cycle
  • Corporate card BIN flag → immediate route to alternate method: Corporate and virtual card velocity blocks rarely self-reset in a billing-friendly timeframe — route these immediately to an ACH, invoice, or alternate card flow rather than waiting on a reset

Manual Escalation

  • High-ACV accounts on credit cycle reset path: Human outreach on Day 5 if no silent retry success — a personal check-in from a CSM framed as "we noticed your payment is pending — just wanted to make sure everything's okay on your end" converts 20–25% of stalled high-value accounts before automated retries complete their cycle
  • Annual plan customers: card_velocity_exceeded on annual charges is almost always a credit limit or spending cap issue — the large one-time amount pushes them over their ceiling. Personal outreach offering to split the annual charge into quarterly installments (if your billing model supports it) is a high-converting recovery approach specific to this scenario
  • Corporate account budget exhaustion: Direct conversation with the account's billing contact about switching to ACH, wire transfer, or Stripe Invoices — corporate finance teams often prefer invoice-based billing over card billing and will welcome the offer
  • Velocity pattern review: Export all card_velocity_exceeded failures monthly and segment by charge amount, geography, and card type — recurring high-amount failures from annual plan customers in specific markets reveal pricing or billing model misalignments worth addressing at the product level

FAQs

Frequently asked questions.

What does the Stripe card_velocity_exceeded decline code mean?

card_velocity_exceeded means the customer has exceeded a spending limit, transaction count cap, or credit ceiling set by their issuing bank. The card is valid and the customer is genuine — the bank's velocity controls are blocking further charges until the limit resets or is increased. Recovery depends entirely on what type of limit was hit and when it resets.

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

Common causes include hitting a daily or weekly transaction count limit, reaching a daily or monthly spending cap, exhausting available credit on a credit card, triggering a fraud velocity check from multiple rapid charge attempts, or hitting a programmatic budget limit on a corporate or virtual card issued by tools like Brex, Ramp, or Float.

Should I retry a payment after a card_velocity_exceeded decline?

Yes, but only at the correct reset window for the limit type. For daily spending caps, schedule a silent retry at 25–28 hours — the limit resets at midnight bank local time. For monthly credit cycles, retry at Day 10 and Day 20. For corporate card budget limits, skip retries entirely and route to an alternate payment method immediately.

Should I email my customer when Stripe returns card_velocity_exceeded?

Not immediately for daily or weekly cap sub-types. Attempt a silent background retry at the correct reset window first — if it succeeds, no customer email is needed. Only trigger customer notification if the silent retry also fails, or if the sub-type is a credit limit or corporate card budget that requires customer action to resolve.

What is the recovery rate for Stripe card_velocity_exceeded failures?

Overall recovery rates are 45–65% depending on limit type. Daily and weekly cap sub-types recover at 65–75% with a correctly timed silent retry. Monthly credit cycle sub-types recover at 35–50% with timed retries and a customer notification. Corporate card budget limits recover at 15–25% and require an alternate payment method switch.

Before you retry

Most card_velocity_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 card_velocity_exceeded costs me →

Stop leaving revenue on the table

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