Card Validation Test Guide: Luhn, CVV, and Sandbox Checks

A card validation test checks that a payment form or API accepts well formed card data and rejects bad data before anything reaches the processor. The fastest way to run one is a sandbox account from a processor such as Stripe, Adyen, or Braintree, paired with that sandbox's published test card numbers. Those numbers pass the Luhn checksum and trigger specific responses, so you can exercise approvals, declines, and 3-D Secure challenges without touching a real account.

What a card validation test verifies

A card validation test is a QA pass over the data your checkout collects before it is sent to an acquirer. You are checking format, not credit. The card number must satisfy the Luhn checksum and match the expected length for its BIN. The expiry must be a real calendar month and a date the form still accepts. The security code must fit the format tied to the card brand. The name field must survive accents, hyphens, and apostrophes.

• Luhn checksum: a mod 10 calculation defined in ISO/IEC 7812-1 that catches single digit typos and most adjacent transpositions.
• BIN range: the leading six to eight digits identify the issuer and brand, which sets the expected total length.
• Expiry: month 01 through 12, year inside the range your form allows, and not in the past.
• Security code: three digits for most brands, four for American Express.
• 3-D Secure: whether the issuer asks for a challenge step before authorization.

Use case: run these checks on every build of the payment form, and again after any change to the input mask, the locale, or the validation library.

Sandbox test numbers compared with production smoke tests

Processors publish test card numbers that behave like live cards inside a sandbox. Stripe, for example, documents numbers that trigger approvals, named decline codes, and authentication challenges. They let you build a repeatable suite without exposing a real account.

Sandbox test numbers

• Pros: deterministic responses, no real money, safe to run in continuous integration.
• Pros: decline and challenge flows can be triggered on demand.
• Cons: they do not expose issuer quirks in your production configuration.
• Cons: a passing sandbox run says nothing about settlement or chargebacks.

Production smoke tests

• Pros: confirms live keys, live routing, and the real authentication rules.
• Pros: catches a misconfigured merchant account.
• Cons: costs real money and creates refunds and fees.
• Cons: it cannot be automated freely, because each run touches a genuine card.

Recommendation: keep the sandbox suite as the default release gate, and run one small production smoke test with your own card after credential or routing changes.

The Luhn check and its limits

Luhn is a checksum, not proof of ownership. A number can pass Luhn and still belong to nobody. Treat it as a typo filter that stops obviously mistyped data from reaching the processor and burning an authorization attempt.

Do not build business logic on top of it. A valid checksum does not mean the account is open, funded, or authorized. Only the issuer's authorization response tells you that, and the answer can change within minutes.

• Pros: cheap, offline, no network call, easy to run on both the client and the server.
• Cons: no relationship to account status, balance, or fraud signals.

CVV and expiry: what you can and cannot test

You can test the format of the security code. You cannot test whether it is correct without an authorization request, because the issuer holds that answer. PCI DSS treats the code as sensitive authentication data, which must not be stored after authorization, encrypted or otherwise. A test plan that keeps codes in logs or fixtures is a compliance failure, not a test win. Expiry works the same way: you can confirm the format and reject past dates locally, but only the issuer knows whether the card is still active.

Use case: write the negative tests first, since rejected input is the path most likely to break when a form adds a new brand or a new locale.

A test matrix that covers the real failure modes

1. Valid test number, valid expiry, valid code: expect approval.
2. Number with one digit changed: expect a Luhn rejection before any network call.
3. Expired month: expect a local rejection with a clear message.
4. Past year with a valid month, and a future year with an invalid month.
5. Three digit code on a four digit brand, and the reverse.
6. Whitespace, hyphens, and mixed formatting pasted into the field.
7. Sandbox decline codes, including insufficient funds and do not honor.
8. A 3-D Secure challenge abandoned halfway through.
9. Network timeout and a double submit of the same form.

Recommendation: run the full matrix in the sandbox on every release candidate, and keep one synthetic variant in production monitoring that never retains card data.