foxhound
Sign in

Decline code

Card Error

`card_error` is Stripe's code for a fault that occurs while reading or validating the card itself during a transaction attempt, distinct from `processing_error`'s broader network-and-system framing. Stripe's own documentation describes it plainly: an error occurred while processing the card. Nothing about this code reflects a considered decision by the issuing bank to reject the charge; the transaction failed before it ever reached that decision point.

Back to decline codes
card_errorRetries automatically
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

This surfaces most often from a malformed or incomplete response passed back through the card network while Stripe or the issuer's system was reading the card's stored data, a timing gap in that same read-and-validate step, or a transient fault on the issuer's side specifically tied to validating the card details rather than evaluating the charge itself. It sits close to `processing_error` in cause, both are technical rather than a decision, but it is scoped tighter: to the card-reading and validation step specifically, rather than the transaction pipeline as a whole. For a recurring subscription charge, none of this has anything to do with the customer's balance, standing, or the card's legitimacy.

How to fix it

Treat it the same way as other soft, technical declines: a short-delay retry resolves the large majority of occurrences without ever involving the customer. A first retry within a few hours catches most transient card-read faults. If the same charge keeps failing with this exact code across several spaced-out attempts, that pattern is worth escalating to a direct customer message rather than continuing to retry indefinitely, since a card that consistently fails validation can reflect a genuine underlying data problem, a corrupted card-on-file record, for instance, that only a fresh card entry actually fixes.

How Foxhound recovers it

A Foxhound-scheduled silent retry runs first, timed for the specific decline pattern rather than an immediate repeat. If the retry succeeds, the customer never sees anything happened. If it does not, Foxhound moves to a dunning email sequence across the following weeks, written in the merchant's own brand voice, with a hosted card-update link on every email as a passive fallback channel.

Questions

  • They're closely related technical fault codes, both reflect a system-level hiccup rather than a considered decision by the issuer, but `card_error` is scoped specifically to the card-reading and validation step, while `processing_error` covers a broader range of technical breakdowns across the transaction pipeline.

  • No particular card type is inherently more prone to it. It's a processing-path issue tied to how the card data was read or validated during that specific attempt, not a property of the card itself.

  • No. A quick, silent retry that succeeds is invisible to the customer, which is exactly the intent behind treating this as a soft, retryable decline rather than an immediate customer-facing failure.

  • Yes. If it keeps recurring against the same card across multiple spaced-out retries rather than clearing after one or two attempts, that pattern is worth a direct customer message asking them to re-enter their card, rather than continuing to retry against a record that may be the actual problem.

  • No. It reflects a technical fault in reading or validating the card during the attempt, not a risk-based decision by the issuer or by Stripe's own fraud systems.

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