Test Credit Card Numbers for Stripe and PayPal: How the Luhn Algorithm Works

Why Developers Search for "Test Credit Card Numbers"

Every checkout form eventually needs a card number typed into it. The payment field has to accept a Visa, reject a typo, show the right brand logo, switch the CVV field to four digits for American Express, and handle declines gracefully. None of that can be tested with a real card without risking real charges, real refunds, and a serious compliance problem.

So developers and QA engineers go looking for test credit card numbers. They usually find two very different things:

1. Official sandbox cards published by payment processors like Stripe and PayPal, which trigger specific, predictable outcomes inside those sandboxes.
2. Generated card numbers that follow real formatting rules and pass the Luhn checksum, but belong to no account anywhere.

Both are useful, and mixing them up is the most common source of confusion. This guide explains how card numbers are built, exactly how the Luhn algorithm works, which official test numbers to use for each gateway, and when a random credit card generator is the right tool instead.

Anatomy of a Credit Card Number

A card number (formally a Primary Account Number, or PAN) is not random. It is defined by the ISO/IEC 7812 standard and has three parts.

1. The Issuer Identification Number (IIN)

The first digits identify the card network and the issuing bank. This prefix is often called the BIN (Bank Identification Number). BINs were historically six digits; the industry has been moving to eight-digit BINs, a change Visa and Mastercard adopted in 2022.

The very first digit is the Major Industry Identifier. That is why almost every Visa starts with 4 and most Mastercards start with 5.

2. The Account Identifier

The middle digits identify the individual account at the issuing bank. This is the part that is genuinely unique to a cardholder.

3. The Check Digit

The final digit is calculated from all the digits before it using the Luhn algorithm. Its only job is to catch typing mistakes.

Common Prefixes and Lengths

These prefixes are what checkout forms use to detect the brand as you type. If your form shows a Visa logo for a number starting with 2221, your brand detection is missing the Mastercard 2-series range, a real bug that shipped in plenty of forms after that range was introduced.

The Luhn Algorithm, Step by Step

The Luhn algorithm (also called mod 10) was designed by IBM scientist Hans Peter Luhn and patented in 1960. It is a simple checksum, and it is used far beyond credit cards: phone IMEI numbers, Canadian Social Insurance Numbers, and many loyalty card numbers use it too.

How to Validate a Number

1. Start from the rightmost digit (the check digit) and move left.
2. Double every second digit, beginning with the digit immediately left of the check digit.
3. If doubling produces a number greater than 9, subtract 9 (the same as adding its two digits: 16 becomes 1 + 6 = 7).
4. Add up all the digits, doubled and untouched.
5. If the total is divisible by 10, the number is valid.

Worked Example: 79927398713

This is the classic textbook example. Reading from right to left:

Sum: 3 + 2 + 7 + 7 + 9 + 6 + 7 + 4 + 9 + 9 + 7 = 70. Since 70 is divisible by 10, the number passes.

Worked Example: Stripe's 4242 4242 4242 4242

The most famous test card in the world is easy to check in your head. The rightmost digit is a 2 (not doubled), so all eight 4s get doubled into 8s and all eight 2s stay as they are:

• Doubled: 8 × 8 = 64
• Untouched: 8 × 2 = 16
• Total: 80, divisible by 10. Valid.

Calculating a Check Digit

To generate a valid number, run the same process on the digits without a check digit, treating the rightmost of those as a digit to double. Then pick the check digit that brings the total up to the next multiple of 10:

export function luhnCheckDigit(partial: string): number {
  let sum = 0;
  let double = true;

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

  return (10 - (sum % 10)) % 10;
}

export function isLuhnValid(cardNumber: string): boolean {
  const digits = cardNumber.replace(/\D/g, "");
  return luhnCheckDigit(digits.slice(0, -1)) === Number(digits.slice(-1));
}

This is essentially what our Random Credit Card Generator does: it picks a real network prefix, fills the account digits using cryptographically secure randomness, and appends the correct Luhn check digit.

What Luhn Catches, and What It Does Not

The Luhn check detects:

• Every single-digit error (typing 5 instead of 6)
• Almost every swap of two adjacent digits (typing 43 instead of 34)

It misses the adjacent swap 09 ↔ 90 and some "twin" errors like 22 ↔ 55. More importantly, it offers zero security. Anyone can compute a valid check digit in a few lines of code, as shown above. Luhn exists to stop fat-finger mistakes before a request ever reaches the payment network, nothing more.

Luhn-Valid Does Not Mean "Real"

This is the single most misunderstood point about card numbers.

A number that passes the Luhn check has only proven that its digits are internally consistent. To actually charge a card, a payment goes through authorization, where the issuing bank checks:

• That the account exists
• That it is open and not reported lost or stolen
• That the expiry date and CVV match what the bank has on file
• That there are sufficient funds or available credit
• Often, that the billing address matches (AVS) and that the cardholder passes 3D Secure authentication

A generated number fails at the very first step, because no account sits behind it. That is exactly what makes it safe for testing, and exactly why it is useless for anything else.

Official Test Card Numbers by Payment Gateway

When you need to test a real payment flow end to end, use the numbers your processor publishes. Their sandboxes recognize these specific numbers and return realistic responses, including specific decline reasons.

Stripe Test Cards

Stripe's test mode accepts any future expiry date and any 3-digit CVC (4 digits for American Express). From Stripe's testing documentation:

Stripe also publishes cards that simulate failures, which is where most checkout bugs hide:

PayPal Sandbox Test Cards

PayPal's sandbox also expects a future expiry date and a 3-digit CVV (4 for American Express). A few of the numbers from PayPal's card testing page:

Gateways update these lists over time, so always confirm against the official documentation before writing them into automated tests.

When to Use a Generator Instead of Gateway Test Cards

Gateway test cards only mean something inside that gateway's sandbox. Most sandboxes reject numbers they do not recognize, so random Luhn-valid numbers are the wrong tool for testing an actual charge.

But a huge amount of card-related code never talks to a gateway at all. For that work, a generator gives you variety that a handful of fixed test numbers cannot.

Good Uses for Generated Card Numbers

• Form validation: confirm your field accepts valid numbers and rejects numbers with a wrong check digit
• Brand detection: feed hundreds of numbers across Visa, Mastercard, Amex, Discover, JCB, and Diners Club to verify logo switching and CVV length changes
• Input masking and formatting: check that 15-digit Amex numbers group as 4-6-5 and 14-digit Diners numbers render correctly
• Database seeding: populate staging environments with realistic-looking records instead of copying production data
• UI mockups and demos: fill screenshots and design prototypes with plausible values
• Load and performance tests of non-payment flows such as order history pages or admin dashboards

Our Random Credit Card Generator lets you choose the network, include an expiry date within a set range, and add a CVV of the correct length. For wider fixtures, pair it with the email, phone, and name generators, or browse the full fake data category. Our guide on creating test data for development covers building complete, realistic records.

Quick Decision Guide

Common Card-Handling Bugs These Tests Catch

Storing Card Numbers as Integers

Card numbers are identifiers, not quantities. JavaScript's Number type loses precision above 9,007,199,254,740,991, and 19-digit Visa numbers exceed that. Always store and transmit them as strings.

Rejecting Spaces and Dashes

Real users type 4242 4242 4242 4242 or paste 4242-4242-4242-4242. Strip non-digit characters before validating instead of throwing an error.

Hardcoding 16 Digits

A form that requires exactly 16 digits silently blocks every American Express (15) and Diners Club (14) customer. Validate length per brand.

Hardcoding a 3-Digit CVV

Amex uses a 4-digit security code printed on the front of the card. If your CVV field has maxlength="3", Amex customers cannot check out.

Outdated Mastercard Ranges

Brand-detection code written before the 2-series range will misidentify Mastercards starting with 2221 to 2720. Test explicitly with a 2-series number such as Stripe's 2223003122003222.

The Legal and Compliance Side

Never Use Real Card Data in Testing

The PCI Data Security Standard (version 4.0, requirement 6.5.5) states that live PANs are not used in pre-production environments unless those environments are fully protected as part of the cardholder data environment. Copying production card data into a staging database is a compliance violation, even if it is "only internal." Generated or official test numbers remove the risk entirely.

Generated Numbers Are Not a Loophole

Using a made-up card number to obtain goods, services, or free trials is fraud in most jurisdictions, regardless of whether the charge succeeds. In practice it also does not work: most subscription services run a small verification authorization when you enter a card, and a number with no account behind it is declined immediately.

Treat generated card numbers as what they are: realistic placeholder data for software you are building.

A Practical Payment Testing Checklist

Before shipping a checkout, run through this list:

• Successful payment with a gateway Visa, Mastercard, and Amex test card
• Generic decline shows a clear, non-technical error message
• Insufficient funds and expired card declines are handled distinctly
• Incorrect CVC prompts the user to re-enter only the CVC
• 3D Secure challenge completes and also fails gracefully
• Form accepts numbers with spaces and dashes
• Amex numbers accept a 4-digit CVV and 15-digit length
• Brand logo switches correctly for all networks, including Mastercard 2-series
• A number with a wrong check digit is rejected before submission
• No real card data exists anywhere in logs, fixtures, or staging databases

Conclusion

Test card numbers come in two kinds, and both belong in a developer's toolkit. Official gateway test cards let you exercise real payment flows, from success to every kind of decline. Generated Luhn-valid numbers let you test everything around the payment: validation, formatting, brand detection, and realistic seed data.

Understanding the Luhn algorithm makes the difference clear. A valid check digit proves the digits are consistent; it proves nothing about whether money exists behind them. That is what makes generated numbers safe for development, and worthless for anything else.

When you need a batch of correctly formatted numbers for a specific network, open our Random Credit Card Generator. For how the underlying randomness is produced, read understanding cryptographic randomness.