A card test sample is a fake card record used to check payment forms and checkout logic in a test environment. It is not a real card, and it must never be used for live transactions. A sample usually pairs a published test card number with a future expiry date and a test security code so developers can confirm that validation, declines, and success states behave as expected.

What a card test sample includes

Payment processors publish test card numbers for sandbox use. A typical card test sample has four parts:

  • Card number: a number reserved for test mode, not a live account.
  • Expiry date: any valid future date in the sandbox.
  • Security code: a test value accepted only by the sandbox.
  • Cardholder name and postal code: dummy values that match the test scenario.

Some processors also provide special test numbers that trigger specific responses, such as a decline or a required 3D Secure step. Use the processor's current test data because test behavior can change.

Where to use a card test sample

Use test card samples only in sandbox, staging, or local development. Good uses include:

  • Checking that the payment form accepts valid formats and rejects bad input.
  • Testing success, decline, and error messages.
  • Confirming that orders are created only after a successful test payment.
  • Running automated tests in CI without touching real card data.

Do not use a card test sample in production. If a live payment page accepts a test number, treat that as a configuration defect and fix it before release.

Safety rules for card test samples

Test data is still data. Keep the same discipline you use for production payments:

  • Never enter a real card number into a test form.
  • Keep sandbox credentials out of public repositories.
  • Label test orders so support teams do not confuse them with live sales.
  • Review logs so test card data does not leak into analytics.

PCI DSS applies to real cardholder data. Test systems should not store live card data, and access should be limited to people who need it.

Common mistakes

A common mistake is copying a card test sample from an old blog post without checking the processor's current docs. Another is using a test sample to verify a real card, which is not a valid test and can create legal and compliance risk. Keep test data in test mode, document the expected result for each sample, and rotate test scenarios when your payment provider updates its sandbox.