Credit Card Validator Test: Sandbox Numbers and Checks

What does a credit card validator test check?

A credit card validator test verifies that a checkout form accepts card numbers that follow the format rules and rejects broken input before a payment request leaves the browser. It runs against sandbox test numbers, so no real cardholder data is involved. A full test covers number length, the Luhn checksum, the issuer range, the expiry date, and the security code length.

Skip these checks and two things break. Bad input reaches the processor, which returns a vague error the customer cannot fix. Sensitive data also travels farther through your stack than it needs to.

How the Luhn algorithm works

The Luhn algorithm (also called the mod 10 check) catches most typos in card numbers. It works on the digits alone and needs no database or network call.

1. Starting from the rightmost digit, double every second digit.
2. If a doubled digit is 10 or higher, subtract 9.
3. Add all digits together.
4. If the total divides by 10, the number passes.

Take 4242 4242 4242 4242. The digits sum to 40, so the number passes. Change one digit and the check fails.

Luhn is a typo detector, not a fraud check. A made-up number that satisfies the math will pass. That is why processors still authorize every transaction at the bank.

Test card numbers for sandbox environments

Large processors publish test numbers that work only in test mode. Stripe, PayPal, Adyen, and Braintree each document their own sets, and none of them work against a live account.

• 4242 4242 4242 4242 - Visa test card, any future expiry, any 3-digit code
• 5555 5555 5555 4444 - Mastercard test card
• 3782 822463 10005 - American Express test card, 4-digit code
• 4000 0000 0000 0002 - card that always returns a decline
• 4000 0000 0000 9995 - card that returns insufficient funds

Use decline numbers to test the unhappy path, not just the approval path. A form that prints "payment failed" for every decline wastes a customer's time. Map the decline code to a plain message such as "your bank declined this card" or "check the expiry date".

What should a validator check beyond the number?

Card length and issuer range

Visa numbers run 13 to 19 digits, Mastercard 16, American Express 15. The first digits (the issuer identification number) reveal the brand, which decides the security code length.

Expiry date

Confirm the month sits between 1 and 12 and that the date has not passed. Compare against the last day of the expiry month, not the first.

Security code

Visa, Mastercard, and Discover use 3 digits. American Express uses 4. A validator that forces 3 digits on an Amex card blocks a valid customer.

Spaces and formatting

Strip spaces and dashes before you run the checksum. Customers paste numbers with spaces from their banking app, and a validator that rejects those looks broken.

Building a validator test checklist

Write these cases once and run them on every deploy. Each one is a few lines of code and saves hours of support tickets.

1. Valid number from each brand you accept.
2. Number with one digit changed, which must fail the checksum.
3. Number with a correct checksum but a wrong length.
4. Expiry date in the past, and expiry month of 00.
5. Security code with the wrong digit count for the brand.
6. Decline number, to confirm the error message shown to the shopper.

Common mistakes in validator tests

• Testing only the happy path and never the decline, expiry, or malformed input cases.
• Treating a client-side check as the only defense. Server-side validation is required.
• Logging the card number or security code in plain text.
• Writing a custom brand regex when the processor already returns the brand.

Never test with real card numbers

PCI DSS forbids storing sensitive authentication data such as the security code after authorization. Using a real card number that is not yours is card fraud under state and federal law.

Buying, selling, or trading real card numbers is a federal crime under 18 U.S.C. 1029, with penalties that include prison time. A payment integration guide has no business on that side of the market.

When you need production-like behavior, use the processor's test mode. It mocks approvals and declines without moving money.

Frequently asked questions

Does Luhn validation prove a card is real?

No. Luhn shows the digits are internally consistent. Only an authorization request through a processor confirms the card is open and funded.

Which test card should I use first?

4242 4242 4242 4242. It is the sandbox default at most processors and triggers a successful charge in test mode.

Can I test a validator without a payment processor?

Yes. Write unit tests around your format and checksum functions and feed them the published brand test numbers.

Should the validator block the form on a failed Luhn check?

Yes. Show the error inline next to the field and keep the submit button disabled until the number passes.