foxhound
Sign in

Decline code

Incorrect Number

`incorrect_number` means the card number submitted with the charge doesn't pass validation or doesn't match a real, issuable card. Stripe's own definition: "The card number is incorrect." Almost always this comes down to a typo: a digit transposed, dropped, or misread while entering the card.

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

This decline shows up heavily around manual entry moments: a new customer signing up and typing their card number by hand, or an existing customer updating their payment method after a prior failure. Long card numbers, usually sixteen digits, are easy to mistype, especially on mobile keyboards or when reading the number off a physical card. Because the number itself fails basic validation before it even reaches the issuing bank in a meaningful way, this is a submission problem, not a reflection of the customer's actual card or account.

How to fix it

No amount of retrying changes a wrong card number into a right one. Every attempt against the same incorrect digits produces the same decline. The only way forward is the customer re-entering the number correctly. Here's the honest picture of what actually happens today. Foxhound's decline classifier places recognized declines into one of four named buckets: soft, network, expired, or fraud, with an unknown bucket for anything unrecognized. `incorrect_number` does not have a dedicated case in the four named buckets. Anything the classifier doesn't specifically recognize falls to the unknown bucket, which fails closed rather than retrying: no automatic retry runs against it. So an `incorrect_number` failure goes straight to a card-update email rather than a silent retry, which is the right outcome, since a retry has no way of succeeding against a card number that was simply typed wrong. That's exactly why going straight to a card-update request works better than a retry ever could: a short, plain message asking the customer to confirm their payment details, without dwelling on the specific reason, tends to get faster action than waiting would.

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. The number typically never gets far enough for a genuine bank-side decision. It fails Stripe's own check because the digits don't form a valid, real card number, almost always from a typo.

  • No. The wrong number stays wrong across every attempt. Only a corrected number changes the result.

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

  • Ask them to re-enter their card number carefully on the payment-update page. That resolves it faster than any automatic retry can.

  • It tends to cluster around manual entry, especially on mobile keyboards, where a long card number is easy to mistype or misread.

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