Sandbox Card Numbers Explained: What They Are and How to Use Them Safely

If you have ever built a checkout form, you have needed a card number to type into it — without using your own real card over and over. That is exactly what a sandbox card number is for. This guide explains what they are, why a made-up number can still "look valid", and how to use them without getting into trouble.

What is a sandbox card number?

A sandbox card number is a randomly generated, fake card number that is built to satisfy two things: the Luhn checksum and a real card-scheme prefix (so it starts like a Visa, Mastercard, Amex and so on). That is all. It is not connected to any bank account, it holds no money, and no one can buy anything with it.

You can create a batch of them instantly with the Card Toolkit — pick a scheme, choose how many, and it generates dummy numbers (with optional expiry and CVV) you can paste straight into a form.

Why a fake number still "passes"

Almost every card number ends in a check digit calculated with the Luhn algorithm. The formula doubles every second digit from the right, adds everything up, and a valid number makes that total a multiple of 10. It is a simple typo-catcher used by nearly every payment form.

Crucially, Luhn says nothing about whether an account exists — it is pure arithmetic on the digits. So any number constructed to satisfy the formula will "pass" a Luhn check. That is a feature, not a bug: it lets you check that your form accepts well-formed input and rejects typos, without touching a real card.

Prefixes identify the brand

The first digits — the IIN/BIN — tell you the scheme. Numbers starting with 4 are Visa; 51–55 and 2221–2720 are Mastercard; 34 and 37 are American Express; and so on. A good sample number uses a real prefix so your brand-detection logic lights up correctly. To inspect the bank and country behind a real card's BIN, use the BIN Lookup.

How developers actually use them

• Front-end validation: check that your input mask groups digits (4-4-4-4, Amex 4-6-5), detects the brand, and flags a bad checksum before submitting.
• UI states: fill a realistic-looking checkout for screenshots, samples and QA without exposing a real card.
• Edge cases: check unusual lengths, Amex 15-digit numbers, and what happens when the Luhn check fails.

To verify a number you already have — real or generated — the Card Validator runs the Luhn check and identifies the scheme, while the Format tab of the Card Toolkit cleans and masks it.

Where sample numbers stop — use the sandbox instead

Generated numbers only exercise your own code. The moment the card data leaves your form for a real payment gateway, a random Luhn-valid number will be declined — it is not a real card. For a true end-to-end check (authorization, 3-D Secure, refunds, webhooks), you must use the official sample numbers your gateway publishes, in its sandbox/check mode:

• Stripe: 4242 4242 4242 4242 (and a long list for specific scenarios)
• PayPal, Adyen, Braintree, Square: each has its own sandbox card set in its docs

Those numbers are wired into the gateway's sample environment so they return predictable results — approved, declined, insufficient funds, and so on.

Staying on the right side of the line

Generating dummy numbers for QA is normal and legitimate — but the intent matters. Using any card number, real or generated, to attempt fraud or to probe live systems is illegal. Keep generated numbers to your own development and QA, and never enter a stranger's real card details anywhere.

Quick summary

• A sandbox card number is fake but Luhn-valid with a real scheme prefix.
• It passes a checksum because Luhn is just arithmetic — it proves nothing about a real account.
• Use the Card Toolkit to generate and format them for front-end QA.
• Use your gateway's official sandbox numbers for real end-to-end payment checks.