Generating synthetic card numbers is legal. Using card data to obtain something you have not paid for is not. The line falls between the two, and it falls on intent and use, not on the numbers themselves.
That is why payment processors publish their own test card numbers, why PCI DSS requires synthetic data in test environments rather than merely permitting it, and why this tool exists at all. It is also why using a generated number to start a subscription is fraud even though the attempt will fail.
This page is general information, not legal advice. Laws differ by jurisdiction and change over time; for a specific situation, consult a qualified lawyer.
Why synthetic test data is not just legal but required
The stronger position is not that generating test numbers is permitted. It is that using real card data instead would put you in breach of rules you are already subject to.
PCI DSS prohibits live PANs in pre-production environments. Requirement 6.5.5 in version 4, formerly 6.4.3, states that live account numbers are not used for testing or development. Testing a checkout with real customer card data is not a shortcut, it is a compliance failure — the PCI guide covers the scope rules in full.
Data protection law points the same way. Copying a production database into staging moves personal data into an environment that is typically less protected, while every obligation that attached to it in production follows it there.
The processors themselves publish test numbers. Stripe, Adyen, PayPal, and Braintree all distribute sets of card numbers specifically so that developers do not use real ones. Synthetic card data is the industry norm, not a workaround — the reference collects the published sets.
The format is a public standard. ISO/IEC 7812 defines how a card number is structured, and the Luhn checksum has been in the public domain since its patent expired. There is nothing confidential about the arithmetic.
A card number generator is a test data utility, in the same category as a random name generator or a fake IBAN generator. The format it implements is a published standard, and the output it produces is required by compliance frameworks that would otherwise force developers to use real customer data.
There is a practical corollary that matters more than the abstract argument. In an audit or a due diligence review, someone will eventually ask where your test data came from. “It was generated from a public format specification, in the browser, from a cryptographic random source” is a complete answer that closes the question. “It’s a slice of last year’s production table, anonymised” opens several more: anonymised how, by whom, verified by what, and where are the other copies.
The distinction also holds when something goes wrong. A test fixture leaked from a repository is an embarrassment if it is synthetic and a notifiable data breach if it is not. That difference costs nothing to secure in advance and cannot be retrofitted afterwards, which is the practical reason the requirement exists in the first place rather than a bureaucratic one.
Where it becomes illegal
The offence is never the number. It is what someone does with it:
- Attempting to obtain goods or services you have not paid for
- Using card data to start a free trial, subscription, or discount you are not entitled to
- Bypassing an age, identity, or payment verification control
- Deceiving anyone with fabricated card data
- Presenting or selling generated numbers as genuine cards
- Using anybody else’s card details, synthetic or real, without authorisation
One point deserves emphasis because it is widely misunderstood:
In most jurisdictions the offence is attempting to obtain something by deception, and it is complete at the attempt. It does not require the attempt to succeed. A declined transaction is still an attempted fraud, and the declined attempt is logged.
“It didn’t work anyway” is not a defence. It is a description of the evidence, and the record of the attempt is generally more durable than the transaction would have been.
Jurisdiction reference
Each entry links to the official text or an authoritative reproduction.
| Jurisdiction | Law | Covers |
|---|---|---|
| United States | 18 U.S.C. § 1029 | Producing, using, or trafficking in counterfeit access devices |
| United States | 18 U.S.C. § 1030 | Unauthorised access to protected computer systems |
| United Kingdom | Fraud Act 2006, ss. 1–2 | Fraud by false representation |
| United Kingdom | Computer Misuse Act 1990 | Unauthorised access to computer material |
| European Union | Directive (EU) 2019/713 | Fraud and counterfeiting of non-cash means of payment |
| Türkiye | TCK m. 245 | Misuse of bank or credit cards |
| Türkiye | TCK m. 158 | Aggravated fraud, including use of banking instruments |
| Canada | Criminal Code s. 342 | Credit card theft, forgery, and unauthorised use |
| Australia | Criminal Code Act 1995 | Dishonestly obtaining or dealing in personal financial information |
Most other jurisdictions have equivalent provisions; the absence of a country from this table means only that its statute was not verified for this page, not that the conduct is permitted there.
Note what these laws target: counterfeiting, unauthorised use, and obtaining by deception. None of them prohibits computing a number that satisfies a published checksum — which is what a generator does.
The age and identity verification question
Some sites ask for a card as a proxy for age verification, and a share of the searches that reach this page are about exactly that.
Using a generated number there fails technically, because the check runs an authorisation against an issuer that has no record of the number. It is also an attempt to circumvent an access control, which is a separate matter from the fraud element and is treated as its own offence in several jurisdictions.
If the underlying problem is that you do not want to hand a card to a site you do not trust, that is a reasonable concern with a real answer: a virtual card with a spend limit, covered in the free trial guide. If the underlying problem is that you are below the age the site requires, no tool solves that, and the verification exists for reasons that generally hold up.
Researchers, educators, and security testing
Synthetic data is the right tool for teaching payments, demonstrating validation, and building training material, and none of that raises a legal question at all.
Testing against systems is different, and the distinction is ownership:
- Your own systems — no permission needed beyond your employer’s own policies.
- Someone else’s systems — written authorisation is required, whether through a bug bounty programme’s published scope or a penetration testing agreement. Unauthorised access statutes apply whether or not any damage results.
- Responsible disclosure — if you find something without looking for it, report it through the vendor’s channel and stop testing.
“For educational purposes” is not a defence in any jurisdiction. What determines the outcome is what was done and to whose systems, not how it was labelled.
Attacking a live payment endpoint to see what happens is also, incidentally, the traffic pattern described in the card fraud guide — indistinguishable from the real thing at the receiving end, and treated accordingly.
What this site does to stay on the right side of the line
Transparency about our own position, since this page is partly an argument about it:
- No card checking. There is no function here that tests whether a number is live, and there never will be. Your own code never needs that answer.
- No BIN lists. We publish no mapping between prefixes and institutions, in either direction, because that data’s primary non-commercial use is targeting.
- No issuer-targeted generation. The tool produces network-valid prefixes, not a named bank’s ranges.
- Prohibited uses are enumerated, not implied — the terms list them explicitly.
- There is a route to report misuse — contact us, and we act on reports.
- Nothing here is derived from real cardholder data, and no such data is stored. Numbers come from
crypto.getRandomValues()in your browser, as the generator documents.
If you are unsure
The practical test is short. Are you testing something you own or are authorised to test? Then this is ordinary engineering work. Is anyone else’s system, account, or verification control involved? Then get permission first, in writing.
In a corporate setting, ask your legal or compliance team before running anything against a payment system — they will have an answer, and it takes an email. For a specific situation with real consequences, ask a qualified lawyer in the relevant jurisdiction.
Again: this page is general information, not legal advice. Statutes are cited to help you find the right text, not to tell you how it applies to you.
The statutes cited above were last checked against provider documentation on . Providers do change what they publish — the official link beside each claim is authoritative.