Test Credit Card Numbers for Developers (and When to Use Them)

Two Kinds of Test Numbers

Provider Sandbox Cards

Each payment provider publishes test numbers for its sandbox. They're documented, stable and designed to produce particular responses. For example, Stripe's documentation lists 4242 4242 4242 4242 as a basic successful Visa card in test mode, with any future expiry date and any security code, plus other numbers that simulate declines, insufficient funds or authentication challenges.

Good practice:

• Use the provider's own list, since only those numbers trigger the documented behaviour in their sandbox.
• Test failure paths, not just success: declines, expired cards, incorrect CVC and authentication failures.
• Keep test and live keys separate, and make sure test cards can't reach production.

Synthetic Luhn-Valid Numbers

Before you integrate a provider, or when testing parts of your system that never talk to one, you still need card-like input:

• Front-end form fields: formatting as the user types, card type detection, length limits
• Unit tests for validation functions
• Database fixtures and UI screenshots
• Load tests that stop before payment submission
• Demo environments

Synthetic numbers use correct network prefixes, lengths and a valid Luhn check digit, so they pass format validation, but they aren't linked to any account. Credit card number structure explains what makes them format-valid, and the Luhn algorithm explained covers the check digit.

Which One for Which Test?

Rules That Keep Testing Safe

• No real cards in test environments, ever. Staging databases and logs are often less protected than production.
• No card numbers in logs, even test ones, so the habit carries into production.
• Label fixtures clearly as test data.
• Don't try generated numbers on real websites. They won't work, and attempting payments with numbers that aren't yours is fraud. Why generated card numbers don't work explains this.

Generating Synthetic Test Data

The test card generator creates synthetic, Luhn-valid numbers for Visa, Mastercard, American Express, Discover, JCB, Diners Club and UnionPay, with optional future expiry dates, security codes of the right length and fictional names. You can copy a single value or download up to 50 records as CSV or JSON for fixtures. It runs in your browser and is intended for development and QA only. For a full test plan around a checkout form, see how to test payment forms.

Organising Test Card Data

For teams, a shared, documented set of test data saves time and avoids mistakes:

• Keep a fixtures file with synthetic numbers for each network you support, clearly labelled as test data.
• Link to the provider's sandbox list rather than copying it, so it stays current.
• Name test cases by outcome: "visa-success", "amex-invalid-luhn", "mastercard-expired".
• Version it with your code, so tests and data change together.

Automated Tests

In end-to-end tests that run against a sandbox, keep card numbers in configuration rather than scattered through test code, and make sure the test environment can only ever use sandbox API keys. Unit tests for validation functions can use synthetic numbers directly, including deliberately broken ones (a changed digit, a wrong length) to check rejection paths.

Summary

Use provider sandbox cards for anything that touches a payment processor, and synthetic Luhn-valid numbers for formatting, validation and fixtures. Keep real cards out of test systems entirely.