What a card validation test checks
A card validation test confirms that the card data a customer typed into your payment form is structurally valid and internally consistent before your code sends it to a processor. It checks the Luhn checksum, the total digit length, the issuer prefix, the expiry date, and the security code format. It does not confirm that the account is open, funded, or authorized. Only the issuing bank can answer that, and only in response to an authorization request.
Keeping those two ideas apart matters. Format validation catches typos and dropped digits on your own form, which happens with roughly 1 in 20 manually entered numbers. Authorization catches closed, stolen, or overdrawn accounts. Confusing the two produces code that rejects good customers and approves bad ones.
Prerequisites
- A sandbox account with your payment processor
- The list of test card numbers that processor publishes
- One sample number for each card brand you accept
- Access to your form's input handling code
Run the validation test
- Strip spaces and hyphens from the number, then confirm every remaining character is a digit.
- Run the Luhn check. Starting at the rightmost digit, double every second digit, subtract 9 from any result above 9, then add all digits together. The sum must be divisible by 10.
- Compare the leading six to eight digits against the issuer identification number ranges your processor documents for each brand.
- Check the total length against the brand. American Express uses 15 digits, Visa and Mastercard use 16, and the broad ISO range allows 14 to 19.
- Validate the expiry as a month between 1 and 12 paired with a year that has not passed.
- Check the security code length. Visa, Mastercard, and Discover use 3 digits; American Express uses 4.
- Submit the same payload to the processor sandbox and compare the response to your local result. A format-valid number that the sandbox declines is behaving correctly.
- Log the result code and the last four digits only. Never write the full number or security code to an application log.
Reading the response
Validation errors
A validation error means your own check or the processor's format check failed. The customer can fix this by retyping, so return a field-level message that points at the exact input.
Decline codes
A decline comes from the issuer after the number passed every format check. Do not retry declines automatically on the same card. Show the customer the general reason and offer a different payment method.
Sandbox versus production
Sandbox test numbers are built to trigger specific responses, including approvals, declines, and timeouts. Treat them as fixtures for your test suite, not as proof that a live card will behave the same way.
What not to do
Never test a live card to see whether it works. PCI DSS forbids storing sensitive authentication data, including the security code, after an authorization, and running live cards through test transactions creates real holds for real cardholders. Use processor-supplied test numbers and your own sandbox credentials.