Invalid Card Number
Category: Invalid Account/Card Data Retryable: yes
Variability
Near-universal meaning
Consistently defined across the sources checked.
Retryable
yes
Retry only after the customer corrects the card number — resubmitting the same value will fail again.
Namespace: Legacy/conventional ISO 8583 field-39 code as implemented by card networks and processors — not the current ISO 8583:2023 Annex D table.
What this code typically means
The card number fails a format or check-digit (Luhn) test, or doesn't correspond to any account the issuer recognizes — a data-entry or integration problem, not an issuer risk decision. This is one of the more consistently defined codes across processors: Stripe's incorrect_number/invalid_number, Adyen's 'Invalid Card Number,' and Worldpay's 'Invalid Account Number' all describe the same underlying failure.
What to do about it
Merchant action
Prompt the customer to re-enter their card number; don't silently resubmit the same value. If this recurs for a stored/tokenized card, the token-to-PAN mapping itself may be corrupted.
Customer-facing guidance
Ask the customer to double-check and re-enter their card number.
What's happening on the issuer's side
None — this typically never reaches the issuer's risk engine; it fails a format or existence check upstream.
Cross-processor equivalents
stripe: invalid_number
commonly treated as equivalent
adyen: 8 — Invalid Card Number
commonly treated as equivalent
Cross-processor mappings are commonly treated as equivalent, not identical — every processor's own documentation notes lossy or partial mapping between raw network codes and its own vocabulary.
Sources
- Stripe — Card decline codes — fetched 2026-08-20
- Adyen — Refusal reason codes — fetched 2026-08-20
- Worldpay ISO 8583 Reference Guide V2.58 — Debit/Credit Response Code Mappings — fetched 2026-08-20
- ISO 8583:2023 Annex D — Action codes (current standard, 4-digit) — fetched 2026-08-20
Concept + retry philosophy
Decline Codes: why they're opaque and how to retry them