A card validation test checks whether payment card data is formatted correctly before it reaches an issuer. It runs the Luhn check digit, matches the number against issuer identification ranges, and confirms the expiry, CVV length, and billing fields follow network rules. No authorization request is sent, so a pass confirms format only, not that the account is open or funded.
What a card validation test checks
Most processors split validation into field-level rules. Each field has a fixed format the gateway can verify without a network round trip.
- Check digit: the Luhn algorithm (Mod 10) catches single-digit typos and most adjacent transpositions.
- Issuer range: the first six to eight digits, the IIN or BIN, must fall inside an issuer range for that network.
- Length: primary account numbers run 12 to 19 digits under ISO/IEC 7812. Most consumer cards use 16.
- Expiry: the month must be 01 to 12 and the date must not sit in the past.
- Security code: three digits for Visa, Mastercard, and Discover, four for American Express.
- Billing data: postal code and street number formats feed the AVS check later in the flow.
Validation, authorization, and authentication: what is the difference?
These three steps run in order, and each answers a different question.
- Validation asks: is this string shaped like a card number?
- Authorization asks: will the issuer approve this amount for this account?
- Authentication (3-D Secure) asks: is the person at the keyboard the cardholder?
A number can pass validation and fail authorization in the same second. A closed account, a reported card, and a zero balance all fail at the issuer, not at the form.
How to run a card validation test in a sandbox
- Pull the test card numbers from your processor's developer docs. Each gateway publishes its own set with known success and decline responses.
- Send each test number through the checkout form the way a shopper would. A unit test on the validation library alone misses what the browser and the JSON serializer do to the value.
- Add negative cases: a number with a broken check digit, a 15-digit Amex pasted into a Visa field, an expiry of last month, and a two-digit CVV.
- Read the error messages. The test passes when the shopper sees a useful message and the gateway logs the right validation or decline code.
- Repeat the suite after any change to the payment form, gateway settings, or checkout code.
Why a card validation test fails
- Stripped leading zeros. Spreadsheets and serializers treat a card number as an integer and drop digits. Store PANs as strings.
- Transposed digits. Switching two adjacent digits breaks the Luhn sum, which is the point of the algorithm.
- Stale test data. Sandbox numbers with hard-coded expiry dates go out of range as the calendar moves.
- Unknown test numbers. A number that is valid by Luhn can still bounce if your gateway's test list does not include it.
- Whitespace and dashes. Strip spaces and hyphens before validation, or the length rule fails.
Does a passing card validation test prove the card works?
No. Validation is a format check with no issuer involvement, so it cannot confirm that an account exists, holds funds, or belongs to the person typing. Only an authorization or a zero-dollar account verification request reaches the issuer.
This is also why services that promise live card status from a validation pass mislead buyers. A Luhn-valid number is easy to generate, and a generated number says nothing about a real account.
Compliance rules for validation testing
PCI DSS treats the CVV and the full PAN as sensitive authentication data. Requirement 3.2 forbids storing the security code after authorization, even in encrypted form.
- Use synthetic test numbers in every non-production environment.
- Never test with live card numbers you do not own or hold written permission to use.
- Keep PANs out of logs, error traces, and analytics events.
- Tokenize stored payment data so the raw number never sits in your database.
Frequently asked questions
How often should a card validation test run?
After every release that touches checkout, plus a scheduled run each quarter. Payment form bugs tend to appear when a library update changes how input is handled.
Can a card validation test detect a stolen card?
No. Format checks carry no signal about ownership or fraud. Issuers and fraud vendors detect misuse through authorization patterns, velocity rules, and device data, not check digits.
Is Luhn the same as card validation?
No. Luhn is one rule inside validation. A full test also covers issuer ranges, field lengths, expiry logic, and CVV format.