Debit Card Generator — Test Debit Numbers

A debit card number looks exactly like a credit card number. Same networks, same lengths, same Luhn check digit, same BIN ranges. Whether a card draws on a deposit account or a credit line is recorded in the issuer’s BIN table, not in the digits themselves. This generator produces synthetic numbers in those shared formats for testing.

The generator defaults to Maestro because it is the only network in the picker that was issued as debit and nothing else, which makes it the useful default for debit-specific tests. That is a convenience, not a guarantee: every other network here issues debit and credit products from overlapping ranges, and no generated number can promise a funding type.

Debit vs credit: what the number does and does not tell you

This is the part worth reading, because it is the assumption that breaks payment code most often.

What the number does tell you

• The card network — Visa, Mastercard, Maestro, and so on, from the prefix
• The number’s length, and whether it is well-formed
• Whether the Luhn check digit is correct
• The IIN/BIN, which identifies the issuing institution — but only if you look it up

What the number does not tell you

• Whether the card is debit or credit
• Whether it is prepaid
• Whether it is a consumer or a commercial card
• The account balance, or whether the account exists at all
• The issuing country, which also requires a lookup

The honest exceptions

A few products were issued as debit only, on ranges reserved for them, and for those the prefix does imply the funding type:

• Maestro — debit-only, Mastercard’s European workhorse, now being retired
• Visa Electron — debit with mandatory balance checking, largely superseded
• V PAY — Visa’s European chip-only debit brand, also being phased out
• Some Mastercard debit ranges — reserved for debit products by specific issuers

Notice what those exceptions have in common: two of the three are disappearing. As Maestro and V PAY are replaced by Debit Mastercard and Visa Debit, the debit products move onto the same ranges as their credit equivalents, and the prefix stops carrying the signal it used to. The general rule is not just still true, it is becoming more true: a definitive answer requires a BIN lookup.

Why the ranges overlap in the first place

It is not an oversight. An issuer receives BIN ranges from the network and assigns products within them as its portfolio changes, so the same six-digit prefix can front a debit product this year and a credit product next year. The move from six-digit to eight-digit BINs under ISO/IEC 7812-1:2017 made this finer-grained — an eight-digit BIN often does map to a single product — but it also means any lookup keyed on six digits is now reading a prefix that may cover several different products. If your BIN table is a static file with six-digit keys, it was already approximate and is getting less accurate every year.

In code, the practical consequence is that one of these functions cannot be written and the other can:

// ❌ Not possible. There is no property of the digits that encodes funding type,
//    so any implementation of this is a guess wearing a function signature.
function isDebit(cardNumber) { /* … */ }

// ✅ Ask something that maintains an issuer database.
async function getCardType(bin) {
  const res = await fetch(`https://your-bin-service.example/lookup/${bin}`);
  if (!res.ok) return 'unknown';

  const { type } = await res.json();   // "debit" | "credit" | "prepaid" | "unknown"
  return type;
}

// And design for the answer you will actually get some of the time.
const fundingType = await getCardType(pan.slice(0, 8));
const surcharge = fundingType === 'credit' ? creditSurcharge : 0;

The default in that last line is deliberate: when the lookup fails, charge nothing extra. A BIN lookup tool and our explainer on IINs and BINs cover what those databases actually contain.

Why the distinction matters

If the funding type is unknowable from the number, it is fair to ask why anyone cares. Six places where it changes real behaviour:

1. Interchange. Debit interchange is capped in several markets. In the US, Regulation II holds large issuers to 21 cents plus 0.05% of the transaction — a rule a district court vacated in August 2025, with the vacatur stayed pending appeal, so the cap still applies for now. In the EU the caps are 0.2% for consumer debit and 0.3% for consumer credit.
2. Surcharging. Where surcharging is permitted at all, the rules usually differ by funding type — US card network rules bar surcharging debit outright. In the EU and UK, PSD2 bans surcharging consumer cards of either kind. Getting this wrong is a compliance problem, not a rounding error.
3. Authorisation holds. A hold on a debit card reduces the cardholder’s available money immediately. On a credit card it consumes credit line. The same $200 pre-authorisation is an inconvenience in one case and a declined rent payment in the other, which is why release timing gets complaints on debit and not on credit.
4. Partial authorisation. Debit cards support partial approvals more consistently — the issuer approves what the balance covers and leaves the rest for another tender. If your checkout treats a partial approval as a failure, you decline transactions you could have split.
5. Retry strategy for subscriptions. Debit failures skew toward insufficient funds, which is a timing problem: retrying just after a typical payday recovers a meaningful share. Credit failures skew toward limits and expiry, where the same retry schedule just burns attempts and network fees.
6. Authentication. SCA exemptions and issuer challenge behaviour are not uniform across products, so a flow tested only on credit cards can meet its first challenge in production. Our test card numbers reference lists the sandbox cards that force one.

Debit card networks and formats

Maestro’s 12–19 digit range is the row to pay attention to. It is where validation breaks, and it will keep breaking until the last of those cards expires. For the equivalent ranges on the credit side, the Visa page carries the full format table.

Sources: Mastercard — BIN Lookup data elements, Adyen — Debit Mastercard replacing Maestro, Federal Reserve — Regulation II · Verified: 2026-08-03

Network status and interchange figures above were last checked against provider documentation on 3 August 2026. Providers do change what they publish — the official link beside each claim is authoritative.

Testing scenarios

• Variable length. Generate Maestro numbers at 12, 13, 16 and 19 digits and confirm each is accepted. This single test catches the hard-coded-16 bug that affects a surprising share of checkout forms.
• BIN lookup integration. Mock the lookup and assert three paths: debit, credit and unknown. The unknown path is the one nobody writes and everybody eventually hits.
• Insufficient-funds retry. Simulate the decline, then assert that your retry schedule differs from the one you use for a limit-based decline.
• Partial authorisation. Approve less than the requested amount and check that the remainder is collected rather than the whole transaction abandoned.
• Surcharge calculation. Confirm the fee follows the funding type, and that an unknown type produces no surcharge.
• Missing CVC. Some Maestro cards were issued without a printed security code, so a form that requires CVC unconditionally locks those cardholders out.

What this generator cannot do

• It does not produce a card tied to a real bank account.
• It does not produce a card with a balance — see what these numbers actually are.
• It does not produce a specific bank’s debit card, and no generator can.
• It does not guarantee that a generated BIN is a debit BIN in the real world. The prefix ranges above describe the products, not any particular issuer’s assignment.

For disposable numbers issued against a real account, that is a different thing entirely and the virtual card generator explains where those come from. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.