DEV Community

MondayTool
MondayTool

Posted on Originally published at mondaytool.com

Stop Using Random Card Numbers in Your Checkout Tests (Use These Instead)

When you build a checkout form, you need card numbers to test it. The usual shortcut is to type 4111 1111 1111 1111 or make up some digits. That works until it doesn't, so here is what actually matters.

Random digits fail for two different reasons

1. Luhn check. Almost every card number passes the Luhn checksum. Your front-end validation (and the payment processor) rejects numbers that don't. If you type random digits, about 9 out of 10 fail before your real code even runs, and you end up debugging the wrong thing.

Here is the check in a few lines:

function isLuhnValid(input) {
  const value = input.replace(/\D/g, '') // strips spaces and dashes
  if (!value) return false

  let sum = 0
  let double = false
  for (let i = value.length - 1; i >= 0; i--) {
    let digit = Number(value[i])
    if (double) {
      digit *= 2
      if (digit > 9) digit -= 9
    }
    sum += digit
    double = !double
  }
  return sum % 10 === 0
}

isLuhnValid('4242424242424242')    // true
isLuhnValid('4242 4242 4242 4242') // true
isLuhnValid('4242-4242-4242-4242') // true
isLuhnValid('4242424242424243')    // false
Enter fullscreen mode Exit fullscreen mode

2. A Luhn-valid number is not a test number. A random number that passes Luhn can still belong to a real card issuer. In a sandbox the processor usually only accepts its own published test numbers. And
sending someone else's real card number is exactly what you don't want to do.

So the safe approach is: use the published test numbers, not generated ones.

The numbers worth keeping

These are widely published by payment providers for testing. They pass Luhn and don't ma

Brand Test number
Visa 4242 4242 4242 4242
Visa 4111 1111 1111 1111
Mastercard 5555 5555 5555 4444
American Express 3782 822463 10005
Discover 6011 1111 1111 1117
Diners Club 3056 930902 5904
JCB 3530 1113 3330 0000

Notes that save time:

  • Amex uses 15 digits and a 4-digit security code. A form that assumes 16 digits and a 3-digit CVV breaks here. Test it.
  • Diners Club uses 14 digits.
  • Check your provider's docs for failure cases (declined, insufficient funds, 3-D Secure). Those use special numbers and differ per provider.
  • Expiry can be any future date, and the CVV any 3 or 4 digits, unless your provider says otherwise.

What to test besides "it works"

  • Spaces and dashes in the number (4242 4242 4242 4242 vs 4242-4242-4242-4242).
  • Brand detection from the first digits as the user types.
  • 15-digit Amex and its 4-digit code.
  • An expired date, and a date with a wrong format.
  • Pasting a number with a trailing space.

A small tool I built for this

I got tired of looking these numbers up each time, so I built a test card generator. It gives you a card with a number from the fixed list above, plus a random name, expiry and security code. It doesn't generate real card numbers and it's not for anything except testing forms.

It runs in the browser, no sign-up: Test Card Generator

I wrote a longer version of this guide on my site: Test card numbers for sandbox testing

What other cases do you test in your checkout forms? I'd like to add the ones I missed.

Top comments (1)

Collapse
 
kyisaiah47 profile image
kyisaiah47 •

Can the generator account for provider-specific expiry rules, or can a future date from it still be rejected by the sandbox?