BIN Generator for Test Data
Generate synthetic card-format samples from a fixed BIN prefix. Keep the prefix stable, vary test records and validate the Luhn checksum.
Card format samples
Synthetic names, numbers, expiry dates and security codes for form testing. These are not verified payment credentials or payment-provider sandbox fixtures.
Enter a BIN prefix and generate a complete test card.
Use via API · Developer
Automate this configuration in a server-side script. Keep your API key in an environment variable.
const response = await fetch("/api/cards", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.GENORY_API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"amount": 1,
"network": "visa",
"country": "US",
"scenario": "valid"
})
});
if (!response.ok) throw new Error(await response.text());
const { records } = await response.json();API access requires Developer. Browser and API generation share your allowance. The API returns the complete record; output field selection only changes the website view and downloads.
Hold the prefix fixed and vary the rest.
A fixed BIN prefix is useful when testing prefix-based routing and card-number presentation. This generator retains the chosen prefix while producing synthetic sample numbers and companion fields. Decide which property the prefix is meant to exercise before building a batch.
- 01
Enter a supported prefix
Use the prefix controls and resolve any format error first. A prefix that your form accepts is not automatically evidence of an issued BIN.
- 02
Check preservation
Compare the start of each result with your input. Test number length and checksum separately from any directory information shown alongside it.
- 03
Keep routing tests isolated
Use the sample in a mocked form or routing component. Assert your own routing decision without attempting a live transaction.
Example: test prefix preservation
Given: a prefix accepted by the generator
Assert: each sample starts with that prefix
Also assert: expected length and format checks
Do not assert: a live account existsIf your application routes by eight digits, a six-digit fixture may not exercise the same decision. Use the prefix length your own routing rule expects.
| Property | What to test | Do not infer |
|---|---|---|
| Prefix | Input is retained | Issuer authorization |
| Remainder | Length and checksum | Account issuance |
| Companion fields | Form display and validation | Payment acceptance |
Before you use the result
Practical answers for your next test.
Is a generated prefix sample a sandbox card?
No. Only the payment provider can define which credentials its sandbox recognizes.
Why can directory information be missing?
Prefix matching and directory coverage are different checks. Missing data should remain unknown rather than being filled with a guess.
Can repeated runs produce the same sample?
Do not assume global uniqueness. Apply your own fixture identifiers and preserve any sample used in a regression test.