foxhound
Sign in

Decline code

Card Velocity Exceeded

`card_velocity_exceeded` is Stripe's decline code for a card that has hit a balance, credit limit, or transaction amount limit set by the issuer. Per Stripe's own definition, it covers all three: available balance, credit ceiling, and per-transaction amount caps. It is treated as a soft, retryable decline. Worth stating plainly: Foxhound's decline classifier doesn't have a named rule specifically for `card_velocity_exceeded`. It isn't one of the codes the classifier singles out for particular handling. Any code the classifier doesn't recognize by name falls through to the default category, which is soft, the safe assumption that a decline is temporary and worth retrying rather than a hard stop. That's exactly what happens here. This isn't a case of Foxhound doing something bespoke for velocity-related declines specifically. It's the classifier's fallback behavior doing its job on a code it doesn't have special logic for.

Back to decline codes
card_velocity_exceededNo automatic retry
Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

The name suggests a count of transactions in a time window, and that reading isn't wrong: velocity limits are exactly the kind of check that catches a card getting charged repeatedly in a short span, whether from one merchant with retry logic or several merchants firing charges close together. Subscription businesses can trigger this in either direction: a merchant's own retry attempts stacking up too quickly, or a customer's card being charged by several different recurring services within the same billing window. A charge amount well beyond a card's typical transaction size can also trip a per-transaction limit even when the account's overall balance would otherwise cover it.

How to fix it

Yes, with the same caveat that applies to any velocity-related decline: retrying too soon, or retrying too many times in a short window, can make the underlying problem worse rather than better, since velocity limits are specifically designed to catch repeated attempts. A retry spaced further apart than usual, giving the velocity window time to reset, is more likely to succeed than a quick second attempt. Space retries out generously rather than firing them close together, since a tight retry pattern is the exact behavior a velocity limit is built to catch. Keep retry counts within card network caps (35 attempts per 30 days for Mastercard, 15 for Visa), and don't escalate retry frequency just because the first attempt failed. If repeated spaced-out retries still fail, a direct customer message is a reasonable next step.

How Foxhound recovers it

This code has no dedicated bucket in the recovery engine's classification sets, so it fails closed rather than defaulting to a silent retry: no repeat charge runs against a code Foxhound cannot classify. Recovery goes straight to the same email sequence expired cards get, carrying the hosted card-update link, until this code earns its own bucket.

Questions

  • No. It isn't one of the codes the classifier names specifically, so it falls through to the classifier's unknown category. That category fails closed rather than defaulting to a silent retry: no automatic retry runs, and recovery goes straight to a card-update email instead.

  • Per Stripe, it covers a card exceeding its balance, credit limit, or transaction amount limit. It's broader than just "too many transactions."

  • Yes. Rapid retries look like exactly the pattern a velocity limit is designed to catch, so spacing retries further apart works better than firing them back to back.

  • In principle, yes: a delayed retry once the velocity window resets is a reasonable approach. In Foxhound's classifier specifically, this code doesn't have a dedicated bucket yet, so it currently fails closed to the unknown category instead of auto-retrying, and goes straight to a card-update email.

  • No, if anything the opposite. The classifier's default for an unrecognized code is to fail closed rather than retry silently, so an unclassified code gets more caution, not less. It just means no bespoke retry rule exists yet for this specific code string.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit