Dummy card number: quick answer

A dummy card number is a test primary account number (PAN) that payment processors publish for sandbox testing. It passes basic format checks, including the Luhn algorithm, and it returns simulated approvals or declines in a test environment. It cannot charge a real card or move real money.

Developers use dummy numbers to test checkout forms, subscription billing, refunds, and error handling before a live launch. The numbers are not secrets. Processors document them in public developer guides.

How dummy card numbers work

Processors reserve specific card ranges for testing. A test PAN carries a real brand prefix (Visa, Mastercard, American Express) so your code can route it like a live card. The processor's sandbox then simulates the response.

  • Test BIN ranges map to card brands and card types.
  • Response codes simulate approvals, declines, and fraud rules.
  • Some test numbers trigger 3D Secure challenges or insufficient funds errors.

Because the sandbox handles the response, a dummy number never reaches a card network for authorization. A live terminal, a production payment gateway, or a real merchant account will reject it.

Where to get official test card numbers

  1. Open the developer documentation for your payment processor.
  2. Find the test card table in the testing or sandbox section.
  3. Copy the PAN, expiry date, and CVC as listed.
  4. Match the card brand to the scenario you need to test.
  5. Save the list in your test fixtures, not in production code.

Stripe, Adyen, PayPal, and Authorize.net each publish their own test numbers and behavior notes. Use the numbers from your own processor. A dummy number from one gateway may not trigger the same response on another.

How to run a test transaction with a dummy card number

  1. Switch your API keys to the sandbox or test key set.
  2. Enable test mode in the processor dashboard.
  3. Enter the dummy PAN, a future expiry date, and the listed CVC.
  4. Submit a payment amount that matches your test case.
  5. Check the response code, the webhook payload, and the dashboard log.
  6. Repeat for decline, refund, and 3D Secure scenarios.

Keep each test case isolated. If you test a subscription, cancel it in the sandbox before you start the next case. If you test a refund, confirm that the sandbox balance and ledger reflect the change.

Common mistakes

  • Assuming a dummy number will authorize in production. It will not.
  • Using a real card in a sandbox. That exposes live card data to test systems.
  • Storing test PANs in the same database as live customer records.
  • Skipping decline and 3D Secure cases, then discovering the gaps after launch.
  • Hardcoding a test number in application source instead of test fixtures.

Security and compliance notes

Test card numbers are not cardholder data, but they still belong in a controlled test environment. PCI DSS requires separation between test and production systems, and it requires protection for any real card data that touches your infrastructure. Do not collect live card numbers on your own servers to test a form. Use the processor's hosted fields or test tokens.