Credit Card Test Data Generator
Create synthetic card-format samples with Luhn-valid numbers for QA. Review network and coverage notes; use provider sandbox cards for payment tests.
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.
Choose a network 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.
Build card-form fixtures with a clear expected result.
Card format samples help test number grouping, network labels, expiry fields and checksum handling. They are synthetic format data. Use your payment provider’s documented sandbox credentials when testing authorization, declines or a payment confirmation flow.
- 01
Choose the network or scenario
Match the format to the form behavior you want to test. Include different supported lengths instead of assuming every number has sixteen digits.
- 02
Separate number and companion fields
Check the number, expiry and security-code fields independently. A number checksum does not validate a date or the other fields.
- 03
Save positive and negative fixtures
Keep a passing format example, then change one condition at a time. Record whether a failure concerns length, checksum, expiry or your own business rule.
Example: a card-input test matrix
Case A: generated sample → expected format pass
Case B: remove one digit → expected length failure
Case C: change the final digit → expected checksum failureThese are format assertions. Neither a passing checksum nor a plausible expiry implies an issued card or an approved transaction.
| Layer | Useful assertion | Separate concern |
|---|---|---|
| Number | Supported length and checksum | Issuance |
| Expiry | Your application date rules | Account status |
| Payment | Provider sandbox scenario | Real authorization |
Before you use the result
Practical answers for your next test.
Does Luhn prove a card is real?
No. It is a mathematical consistency check and can be satisfied by synthetic values.
Why should I keep identifiers as strings?
Card numbers are identifiers. Numeric conversion or spreadsheet inference can change their representation.
How do I test an actual decline workflow?
Use the fixtures and test environment documented by your payment provider. A format generator does not simulate issuer decisions.