This Maestro card generator produces Luhn-valid test numbers across Maestro’s range. The network is worth its own page for one property no other mainstream brand has: the number can be anywhere from twelve to nineteen digits long, which means every assumption your validation makes about length is testable against a single brand.

Test card only

Credit Card Number Generator

Generate dummy card details for development and QA. Nothing is stored or sent to a server.

Card network
These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments.

Maestro card number format

PropertyValue
BIN ranges50, 56–69
Length12–19 digits
Check digitLuhn (mod 10)
Security codeCVC2, 3 digits — absent on some cards
FundingDebit only
StatusRetiring — no new EEA issuance since July 2023

Maestro breaks every length assumption

Eight valid lengths. Not “sixteen, but occasionally nineteen” — genuinely eight, from twelve digits to nineteen, all in circulation at the same time.

That single fact invalidates a family of shortcuts that are otherwise almost safe:

  • A fixed maxlength on the input truncates longer cards
  • A submit button that enables at sixteen digits never enables for a twelve-digit card, and fires too early for a nineteen-digit one
  • A 4-4-4-4 mask produces a ragged display at every length except sixteen
  • A CHAR(16) column pads or truncates on the way in
  • A \d{16} regex rejects most of the range

There is a second lockout that has nothing to do with length. Some Maestro cards were issued with no printed security code. A checkout that marks CVC required for every brand makes those cards impossible to use — the cardholder has nothing to type. The field should become optional when Maestro is detected, which is a brand-conditional rule most forms do not have. Some Maestro cards also never supported online transactions at all, being chip-and-PIN only; those will fail at the processor regardless of what your form does, and the honest response is a clear decline message rather than a validation error implying the customer typed something wrong.

Detection order decides the answer

Maestro claims 50 and the whole of 5669. Discover holds 65 and 644649, which sit inside that block, and UnionPay holds 62, also inside it. All three claims are legitimate — the ranges are co-allocated and the real network is determined by the issuer rather than the prefix alone.

For code, this means the order of your checks is not a style choice. It changes the output:

// Order matters: check the specific ranges before Maestro's broad one.
function detect(n) {
  if (/^(6011|64[4-9]|65)/.test(n))   return 'discover';
  if (/^62/.test(n))                  return 'unionpay';
  if (/^(5[1-5]|2[2-7])/.test(n))     return 'mastercard';
  if (/^(50|5[6-9]|6[0-9])/.test(n))  return 'maestro';
  return 'unknown';
}

Move the Maestro line up and every Discover and UnionPay card in the shared block is misidentified. The failure is quiet — brand marks are wrong, brand-conditional rules like CVC length or surcharge take the wrong branch, and nothing throws. A test that asserts a 65 number resolves to Discover and a 62 number to UnionPay, run through the whole chain rather than individual expressions, is the one that catches it.

The full Maestro expression, for a single-brand check:

const MAESTRO = /^(50|5[6-9]|6[0-9])\d{10,17}$/;

MAESTRO.test('500000000000');        // true  — 12 digits, shortest valid
MAESTRO.test('5000000000000000000'); // true  — 19 digits, longest valid
MAESTRO.test('50000000000');         // false — 11 digits, too short
MAESTRO.test('5500000000000000');    // false — Mastercard's block, not Maestro

Where Maestro is accepted, and for how long

Maestro was Mastercard’s European debit workhorse, strongest in Germany, the Netherlands, Belgium and across Central and Eastern Europe, and it appeared widely in point-of-sale acceptance where online acceptance was patchy.

That is changing on a published timetable. Issuers in the European Economic Area could not issue new Maestro cards after 1 July 2023, and Debit Mastercard is the replacement. Cards issued before the cutoff stay valid until they expire, which takes the last of them to 2027 at the latest.

The practical reading for a developer: Maestro is a shrinking share of traffic but not yet a zero one, and the length handling it forces you to get right is the same handling every other network benefits from. When the last Maestro card expires, the twelve-to-nineteen digit rule is still the correct rule — see the debit card generator for how the funding-type question outlives the brand.

What to keep after Maestro is gone

It is tempting to treat the retirement as permission to delete the special cases. Most of them should stay, and separating the two categories is worth doing deliberately.

Delete when the last card expires: the Maestro branch in your brand-detection function, the Maestro logo asset, and any Maestro-specific copy in your checkout. These describe a brand that no longer exists.

Keep permanently: the twelve-to-nineteen digit length rule, because it is what ISO/IEC 7812 permits and other networks use the wider parts of it. The brand-conditional security-code handling, because American Express still needs four digits and other products still vary. The detection-order discipline, because Discover and UnionPay continue to share ranges regardless of what happens to Maestro. And the habit of warning rather than blocking on validation failures, which never depended on Maestro at all.

The pattern generalises: a network retiring removes a brand, not the reasons the flexible rules existed. Code that hard-codes sixteen digits will still be wrong on the day the last Maestro card expires — it will just take longer to find out.

Testing scenarios

  • Every length. Generate twelve, thirteen, sixteen and nineteen digit numbers and run each through the form end to end. This one test finds most hard-coded lengths in a codebase.
  • Detection order. Assert 65, 644 and 62 prefixes through the full chain, not the Maestro expression alone.
  • Optional CVC. Confirm the security-code field becomes optional when Maestro is detected, and that submitting without it works.
  • Mask behaviour. Type a twelve-digit number and a nineteen-digit one and watch the grouping; a fixed 4-4-4-4 mask will look broken at both.
  • Column width. Nineteen digits, stored and read back, compared byte for byte.

Official test numbers

For processor behaviour rather than format coverage, use the gateway’s own numbers. Adyen documents 6771 7980 2100 0008 for Maestro, PayPal publishes 6304 0000 0000 0000, and Braintree uses the same. The test card numbers reference collects them by gateway with the decline codes each one produces.

Mastercard’s own guidance on the Maestro transition is published at Mastercard, and Adyen maintains a clear summary of the Debit Mastercard replacement.

The retirement timeline above were last checked against provider documentation on . Providers do change what they publish — the official link beside each claim is authoritative.

Because the shared ranges make detection ambiguous, the validator is the quickest way to see which network a 6x number resolves to under a correctly ordered chain. The length reference lists what every network permits, which is the table to check a maxlength against. The tool directory has the remaining generators, and the FAQ covers the limits of checksum validation.

Frequently Asked Questions

Anywhere from twelve to nineteen. Maestro is the one mainstream network that used the full range ISO/IEC 7812 permits, which means eight different valid lengths rather than one. Any validation stricter than that range will reject real cards.
Because the length check hard-codes sixteen, which is the most common card-validation bug there is. Maestro is simply the network that finds it fastest. Validate the checksum and accept twelve to nineteen digits, then let the processor make the real decision.
No, and this one causes real lockouts. Some Maestro cards were issued without a printed security code at all. A checkout that marks the CVC field required for every brand makes those cards unusable, so the field should be optional when Maestro is detected.
Because Maestro claims 56–69 as a broad block while Discover holds specific ranges inside it, notably 65 and 644–649. Both claims are legitimate. The consequence is that detection order decides the answer: check Discover’s specific ranges before Maestro’s broad one, or a large share of Discover cards will be labelled Maestro.
Yes, gradually. Mastercard stopped new Maestro issuance in the European Economic Area from 1 July 2023, replacing it with Debit Mastercard. Cards issued before that date remain valid until they expire, which runs to 2027 at the latest — so validation still has to accept them for now.
No. They are Luhn-valid and correctly formatted, which is what makes them useful for testing length handling and detection order. No issuer has them on file, so any real processor declines them.