Mastercard Generator — Test Numbers

This Mastercard generator — often searched as a master card generator — produces Luhn-valid test numbers across both of Mastercard’s BIN ranges, not just the familiar one. That matters more than it sounds, and the section below explains why: a large amount of payment code in production today rejects legitimate Mastercards because it has never been updated for the 2-series.

Mastercard number format

The 2-series problem

Mastercard ran out of room. The 51–55 block had been the whole of the network’s issuance space since the beginning, and by the mid-2010s it was close to exhausted. Mastercard announced the 2221–2720 range in 2016 and issuers began putting cards on it in 2017. In six-digit BIN terms that is 222100 through 272099.

The 2-series is not a test range, not a special product, and not regional. It is ordinary issuance, and there are a great many such cards in circulation. But an enormous amount of validation code was written when ^5[1-5] was a complete description of Mastercard, and that code is still running.

The pattern that is wrong:

const MASTERCARD_WRONG = /^5[1-5]\d{14}$/;

The pattern that is right:

const MASTERCARD = /^(5[1-5]\d{4}|222[1-9]\d{2}|22[3-9]\d{3}|2[3-6]\d{4}|27[01]\d{3}|2720\d{2})\d{10}$/;

Why the 2-series needs five alternatives

A numeric range is not a string prefix. 2221–2720 cannot be written as a simple character class, because the digits are constrained differently depending on what came before them. Splitting the range into blocks where each digit position has a clean rule gives this:

Each fragment matches four digits; the pattern above pads each to six with \d and then requires the remaining ten, for a fixed total of 16.

The boundary tests it has to pass

Range logic is where off-by-one errors live, so test the edges rather than the middle:

const cases = [
  ['2220000000000000', false], ['2221000000000000', true],
  ['2720000000000000', true],  ['2721000000000000', false],
  ['5050000000000000', false], ['5100000000000000', true],
  ['5599000000000000', true],  ['5600000000000000', false],
];

cases.forEach(([n, want]) => {
  const got = MASTERCARD.test(n);
  console.assert(got === want, `${n}: expected ${want}, got ${got}`);
});

All eight pass against the corrected pattern. Run the same eight against MASTERCARD_WRONG and two of them fail — 2221… and 2720…, the two that represent real cards. That is the bug, reproduced in four lines.

These eight are shape assertions, so they use filler digits and are not Luhn-valid. To test shape and checksum together, generate numbers with the tool above: it draws from both ranges, so a batch will exercise the 51–55 and 2221–2720 paths through your detection code. Two Luhn-valid examples, one from each range:

5-series   5425 2334 3010 9903
2-series   2221 0011 2233 4458

Mastercard product types

• Mastercard Standard / World / World Elite — tiers of the same credit product, no distinguishing pattern in the number
• Mastercard Debit — issued on the same ranges as credit
• Mastercard Prepaid — again, the same ranges
• Maestro — a separate scheme on its own BINs, covered below

As with every network, the product type is not encoded in the number. Standard, World Elite, debit, and prepaid all look alike from the digits alone; that classification lives in the issuer’s BIN table. Routing or fee logic that needs it requires a BIN lookup service — see the BIN and IIN guide.

Testing scenarios specific to Mastercard

Both ranges, separately. Generate a batch and confirm your detection labels the 2221–2720 numbers as Mastercard, not as unknown. This is the test that catches the 2-series bug.

Fixed 16-digit length. Mastercard is always 16 digits, so unlike Visa a strict length === 16 check is correct here. Reusing Visa’s more permissive length rule is harmless; reusing Mastercard’s on Visa is not.

CVC2 field length. Three digits. If your security-code field is fixed at four for American Express, Mastercard needs it to shrink back.

Brand detection timing. A leading 5 narrows the field quickly, but a leading 2 does not identify anything on its own — you need four digits before you can say the card is a 2-series Mastercard. Detection that commits after one or two digits will show the wrong mark and then have to correct itself as the user keeps typing.

Input mask. 4-4-4-4 at 16 digits, the same as Visa.

Luhn rejection. Alter the final digit of a generated number and confirm the form rejects it.

Mastercard vs Maestro

Maestro is operated by Mastercard but is a different scheme with different rules, and code that treats them as one thing will get both wrong:

The variable length is the part that breaks things: a Maestro number can be 12 digits or 19, so any length check narrower than that range will reject valid cards. The Maestro generator covers that range and the detection-order problem it creates with Discover and UnionPay, and the all-network generator includes Maestro in its picker.

Official Mastercard test numbers

Mastercard and every major gateway publish their own test numbers. Those are registered in the processor’s sandbox and return genuine authorisation responses; the numbers here do not.

The third row is the one worth noting: gateway documentation still tends to give a single 5555… example, so a sandbox test suite can pass while the 2-series path has never been exercised at all. That is precisely the gap this generator fills.

For processor behaviour, use the official numbers — Stripe and PayPal document theirs in full, and we collect the equivalents on the test card numbers reference. Card number structure in general is covered by ISO/IEC 7812.

Other networks have their own pages: Visa, American Express, and Troy. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.