Debit Card Generator
Pick a card network and get a Luhn-valid test card number with a random name, expiry date and CVV. Not linked to any bank account and holds no money.The Debit Card Generator produces a fake debit card for testing: a card number that passes the Luhn checksum and uses the real prefix and length for the network you choose, along with a random cardholder name, an expiry date one to ten years out, and a three-digit CVV. Pick from 32 networks, including Visa, Visa Electron, Mastercard, Maestro, RuPay, Discover, JCB, UnionPay, Mir and Verve. It's for developers and QA testers who need realistic-looking card data in a form, a mockup or a demo database, and it's deliberately not able to move money.
To be clear up front, because this is the most common question that brings people here: the cards are not real, have no balance, are not linked to any bank account, and will be declined by any live payment processor. There is no such thing as a free debit card number with money on it, and any site claiming to offer one is a scam.
How to use it
- Choose a card type from the dropdown. Visa is selected by default.
- Press Generate Debit Card. A card appears showing the number, expiry date, cardholder name, CVV and the network's logo.
- Use Copy Card to put the details on your clipboard, or Download Card to save them as a small .txt file named after the card number. Both include a random US address and a disclaimer line along with the card fields.
Every click produces a new card. Nothing is stored on our side.
What makes the number "valid"
A card number has three parts, and the generator gets all three right so that form validation accepts it:
- Issuer prefix (IIN/BIN) – the first digits identify the network. The generator uses the published ranges: Visa starts with 4, Mastercard with 51–55 or 2221–2720, Maestro with 5018, 5020, 5038, 6304, 6759 or 6761–6763, American Express with 34 or 37, Discover with 6011 or 65, RuPay with 60, 65 or 81–82, JCB with 3528–3589, UnionPay with 62.
- Length – 16 digits for most networks, 13 or 16 for Visa, 15 for American Express and Diners Club enRoute, 14 to 19 for Diners Club International and UnionPay. The generator picks a valid length for the network you chose.
- Luhn check digit – the last digit is computed so the whole number passes the Luhn algorithm, the same checksum every checkout form runs before it talks to a processor. That's what stops "1234 5678…" from being accepted, and it's why these numbers get past client-side validation.
What the generator can't do is put the number on file at a bank. A real transaction is authorized by the issuing bank looking up the account behind the number; there's no account behind these, so the response is always a decline.
Debit versus credit numbers
Nothing in a card number says whether it's debit or credit. Both are issued in the same Visa, Mastercard and other ranges; the distinction lives in the issuing bank's BIN database. So this tool and the Random Credit Card Generator produce structurally identical numbers, and the only difference is the label on the page. If you specifically need a debit-branded network, choose Maestro, Visa Electron, Solo, Switch, Laser or Dankort, which were or are debit-only schemes. For India's domestic scheme, the RuPay Card Generator is the same engine limited to RuPay prefixes.
Where test cards are actually useful
- Checkout form development – testing that your card-number field formats, masks and validates correctly, detects the brand from the prefix, and rejects a bad Luhn digit.
- Seeding demo and staging databases – a customer table with realistic card fields for screenshots, training environments and load tests.
- UI mockups – a wallet screen or receipt design that needs a plausible card without borrowing a real one.
- QA of masking and PCI handling – confirming that logs, emails and screens show only the last four digits.
For end-to-end testing against a payment gateway, use the gateway's own sandbox cards instead (Stripe, Adyen, Braintree and PayPal each publish lists such as 4242 4242 4242 4242), because their sandboxes only recognize those specific numbers. Other test-data generators on the site cover the rest of a fake customer record: the Bank Account Number Generator, the Bank Routing Number Generator and the Random Email Generator. All of them are listed under all developer and test data tools.
What not to do with these numbers
Entering a generated number into a real store, subscription trial or app is at best pointless, since it will be declined, and at worst a crime if it happens to collide with a real customer's number, because using someone else's card details is fraud regardless of how you got them. Don't do it. The numbers here are for software you control.
Frequently asked questions
- Do the generated debit cards have money on them?
No. The cards are random numbers that pass the checksum; they aren't issued by any bank, have no account behind them and no balance. Any site promising a debit card number with money on it is trying to scam you.
- Will a generated card work for a free trial or a purchase?
No. Merchants send the number to the issuing bank for authorization, and there's no bank or account behind these numbers, so the answer is always a decline. Using a random number that turns out to belong to a real person is fraud.
- Why does the number pass validation on my checkout form?
Because it has the correct prefix and length for the network and its last digit satisfies the Luhn checksum. Client-side validation only checks those three things; actual approval happens at the bank.
- Which card networks can I generate?
32: Visa, Visa Electron, Mastercard, Maestro, Maestro (UK), American Express, Discover, Diners Club (three variants), JCB, China UnionPay, China T-Union, RuPay, Mir, UATP, Verve, Troy, Dankort, Bankcard, Laser, Solo, Switch, InterPayment, InstaPayment, UkrCard, BORICA, NPS Pridnestrovie, LankaPay, UzCard, Humo and GPN.
- Is the CVV real?
It's a random three-digit number. Real CVVs are computed by the issuer from the card number and expiry with a secret key, so there's no way to generate a 'correct' one, and no need to for testing form behavior.



