foxhound
Sign in

Decline code

Invalid Number

`invalid_number` means the card number submitted with the charge failed basic format or checksum validation. Stripe's own definition: "The card number is incorrect." It carries the same practical meaning as `incorrect_number`, a submitted card number that doesn't check out, though Stripe may surface it in slightly different circumstances depending on where in the validation process the number gets rejected.

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

Like its close sibling, this decline clusters around moments of manual card entry: initial signup, a payment-method update after a failed charge, or a customer switching cards. A single mistyped or transposed digit, an extra digit, a missing digit, any of these can cause a card number to fail Stripe's format check before the transaction goes anywhere near the issuing bank. This is a data-entry issue, not a statement about whether the customer's actual card works.

How to fix it

Retrying the same malformed card number produces the same failure indefinitely. There's no backoff period or attempt count that turns an invalid number into a valid one. Resolution requires the customer to submit a correct number, not more attempts at the same one. Honesty about current handling matters more than a tidy story here. Foxhound's decline classifier sorts recognized declines into one of four named buckets: soft, network, expired, or fraud, plus an unknown bucket for anything unrecognized, and `invalid_number` isn't given a dedicated case in the four named buckets. Any code the classifier doesn't specifically recognize falls to the unknown bucket, which fails closed rather than retrying: no automatic retry runs. That means an `invalid_number` failure goes straight to a card-update email rather than a silent retry, which is the correct outcome since no retry can succeed against a number that failed basic validation in the first place. That's why sending the customer straight to the payment-update page to re-enter their card number is the right fix, not a retry: it works regardless of how the underlying decline gets classified.

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

  • For recovery purposes, yes. Both mean the card number submitted with the charge didn't validate. Stripe applies them in slightly different situations, but the fix is identical: the customer needs to re-enter a correct card number.

  • No. A malformed card number stays malformed no matter how many times the same charge runs.

  • Yes. It isn't specifically classified in Foxhound's decline handling today, so it falls to the unknown bucket, which fails closed: no automatic retry runs, and it goes straight to a card-update email instead.

  • Send them straight to the payment-update page to re-enter their card number. That's the only action that actually changes the outcome.

  • Generally no. This decline usually reflects a formatting or entry error at submission, not evidence of a compromised card or fraudulent activity.

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