What a card number validation test checks

A card number validation test confirms that your payment form or API endpoint accepts well-formed card numbers and rejects malformed ones before any authorization request is sent. The test covers four things: the Luhn checksum, the length range, the issuer identification number (the first six to eight digits, also called the BIN), and input hygiene such as spaces, hyphens, and non-numeric characters. You run it against processor sandbox cards, never against live cardholder data.

more on this topic

Prerequisites

• A sandbox or test account with your payment processor
• The processor's published test card numbers
• A test environment that cannot reach production endpoints
• Logging that masks all but the last four digits

How to run the test

1. Collect the test card numbers from your processor's developer documentation and label each one with the outcome it should produce.
2. Submit a known-good test number with a valid Luhn checksum and confirm the form advances to the next step.
3. Change the final digit of that same number so the checksum fails, then confirm the form returns a validation error and sends no authorization request.
4. Submit numbers shorter than the minimum and longer than the maximum length your form permits, and confirm both are rejected.
5. Paste a number with spaces and hyphens and confirm the field strips separators before validating the digits.
6. Enter letters, symbols, and an empty string, and confirm each produces a clear error message.
7. Check your server logs to confirm the full card number never appears in plain text and that only the last four digits are retained.
8. Repeat the full set against the API directly, bypassing the browser, to confirm server-side validation matches the client-side rules.

Test cases worth covering

• Valid checksum, supported length, known test BIN
• Valid checksum, unsupported length
• Invalid checksum, otherwise correct length
• Correct number with leading or trailing whitespace
• Number entered with a card type that does not match the BIN
• Repeated submissions of the same test number to check rate limiting

What to avoid

Do not test with real card numbers, including your own. Do not copy production data into a test database. Do not rely on client-side validation alone, because anyone can bypass the browser and post directly to your endpoint. If your form stores card data at all, confirm the storage path against PCI DSS requirements before you ship.

cvv validation tool