What a test payment card is

A test payment card is a card number that a payment processor publishes for use in its own sandbox. The number passes the same format checks as a live card: length, prefix, Luhn check, expiry format, CVC length. No account sits behind it. No money moves. The processor returns a fixed result for each published number.

related article

Test numbers work only against test API keys, test terminals, and test merchant accounts. A test number sent to a live endpoint returns a decline. A live number sent to a sandbox returns an error or a decline, not a charge.

test payment card number

Test numbers published by major processors

  • Stripe, Visa: 4242 4242 4242 4242. Any future expiry date, any 3 digit CVC, any postal code.
  • Stripe, Visa debit: 4000 0566 5556 5556.
  • Stripe, Mastercard: 5555 5555 5555 4444.
  • Stripe, American Express: 3782 822463 10005. Amex uses a 4 digit CVC.
  • Stripe, Discover: 6011 1111 1111 1117.
  • Adyen and Braintree both document 4111 1111 1111 1111 for Visa test runs.

Each processor lists its own ranges. Numbers do not cross over. A Stripe test number sent to Adyen fails validation.

test payment card number

Decline and error numbers

Processors publish separate numbers that force a specific failure. These let a team test error handling without editing code.

Test Payment Card Number: How Sandbox Card Numbers Work

  • 4000 0000 0000 0002: generic decline.
  • 4000 0000 0000 9995: insufficient funds.
  • 4000 0000 0000 0069: expired card.
  • 4000 0000 0000 0127: incorrect CVC.
  • 4000 0000 0000 0119: processing error.

Decline codes map to response fields. Test each code against the error message the customer sees, not only against the API response.

3-D Secure test cards

Stripe publishes 4000 0025 0000 3155 for a challenge that passes and 4000 0027 6000 3184 for a challenge that fails. Both trigger the authentication step in test mode. A test run that skips the challenge does not prove the flow works. Build at least one case where the customer abandons the challenge page.

What changed for 2026

Strong Customer Authentication rules in the UK and EU now cover most card payments, including card-on-file charges. Test plans that skip authentication no longer match production behavior.

Network tokenization is in wider use. Several processors document separate test numbers that return a network token in place of a PAN, plus test numbers for wallet flows. Token behavior differs from PAN behavior on refunds, partial captures, and card updates. Check current processor docs before writing a test suite, because ranges change.

This article cannot confirm which numbers each processor will publish through 2026. Treat the list above as a starting point and verify against live documentation.

Rules for test data

  • Use test keys and test merchant accounts. Confirm the mode in the request log, not in the code.
  • Never place live card data in a sandbox. Sandboxes have weaker access controls and longer log retention.
  • Do not store CVC values, in test or production.
  • Log the last four digits and the card brand only.
  • Reset test data before a release run so results are repeatable.

PCI DSS applies to any environment that stores, processes, or transmits cardholder data. A sandbox that can receive real numbers falls inside that scope.