What a test credit card is

A test credit card is a card number published by a payment processor for use in its sandbox. It passes the same format checks as a real card, so your checkout form, client-side validation, and server-side API call behave the way they will in production. No account is charged and no cardholder is involved. Processors publish these numbers so developers can test charges, refunds, declines, and webhook handling without touching live card data.

The short answer to the usual question: you do not buy, generate, or derive a test number. You copy it from the documentation of the gateway you integrate with, and it works only on that gateway's test endpoint.

What every test number shares

  • It passes the Luhn checksum, so it survives the same validation as a real number.
  • It carries a valid issuer prefix for its brand: 4 for Visa, 51 to 55 or 2221 to 2720 for Mastercard, 34 or 37 for American Express, 6011 for Discover.
  • The expiry date can be any date in the future, unless the docs state otherwise.
  • The CVV can be any three digits, or four for American Express.
  • Its outcome is fixed. The processor decides whether a given number approves, declines, or returns a specific error. Editing digits does not change that.

Prerequisites

  • A sandbox or test-mode account with your payment processor.
  • Test API keys, kept separate from live keys.
  • A checkout page pointed at the test endpoint, not the live one.
  • The processor's test card documentation open in a second window.

How to run a test charge

  1. Sign in to your processor dashboard and switch the account to test mode.
  2. Open the test card page in the developer docs and copy one number for the brand you want to exercise.
  3. Load your checkout page and confirm in the network tab that requests go to the sandbox endpoint.
  4. Enter the copied number, an expiry date at least a year ahead, and any three-digit CVV.
  5. Submit the form and capture the response your server receives.
  6. Compare the returned status and decline code with the outcome the documentation predicts for that number.

Reference numbers in wide use

The numbers below appear in Stripe's public test documentation. Other processors publish their own sets. A number that works on one gateway does not work on another.

  • 4242 4242 4242 4242, Visa, approves with any future expiry and any three-digit CVV.
  • 5555 5555 5555 4444, Mastercard, approves.
  • 3782 822463 10005, American Express, approves and requires a four-digit CID.
  • 6011 1111 1111 1117, Discover, approves.
  • 4000 0000 0000 0002, Visa, triggers a generic decline.
  • 4000 0000 0000 9995, Visa, triggers an insufficient funds decline.

Testing failures on purpose

Approval paths are the easy half. Map each failure your application must handle to a number that produces it, then assert on the result. Cover at minimum:

  • Generic decline, so your error copy renders.
  • Insufficient funds, so the customer sees a specific message.
  • Expired card, so your form rejects a past date before it reaches the API.
  • Incorrect CVV, so your retry flow works.
  • Processing error, so your 500 handler and retry logic fire.

Reading the response

Assert on the machine-readable fields: status, decline code, and error type. Do not assert on human-readable message text, since processors reword those strings without notice. Log the request id from each test run so you can hand it to support if a result does not match the docs.

Rules that keep testing clean

  • Never enter a real card number in a sandbox. It breaks the processor's terms and can pull you into cardholder data rules.
  • Never use a test number on a live endpoint. It will fail, and repeated attempts look like card testing to fraud systems.
  • Keep test keys out of production builds and out of public repositories.
  • Do not probe live checkout pages with published numbers to see what happens. That pattern trips fraud monitoring on the merchant side.
  • Recheck the docs after a processor migration. Test number lists do change.