Fake Credit Card Number Test: A Developer Guide

A fake credit card number test is a checkout test run against a card number your payment processor hands out for sandbox use. The number follows the same format rules as a live card, so form validation, Luhn checksum, BIN detection, and tokenization all behave normally. It just cannot be charged. Type a Stripe test number into a live storefront and you get a decline, not an order.

What a test card number contains

Every one of these numbers is built from three parts, and knowing them explains why the number passes validation.

• An issuer prefix that maps to a real card network, so BIN detection code has something to match.
• A body of digits that gets the length right, 16 for Visa and Mastercard, 15 for American Express.
• A final check digit that satisfies the Luhn algorithm.

The Luhn check, short version

Luhn doubles every second digit from the right, subtracts 9 from any result above 9, adds everything up, and checks whether the total divides by 10. That single rule separates typos from valid-looking input, which is why a random string of 16 digits usually fails. It also means Luhn alone proves nothing about whether a card exists. Test numbers pass it by design.

Where developers get them

You do not need to invent anything. Stripe publishes a list of test numbers in its documentation, each tied to a specific outcome. Braintree and PayPal sandbox accounts ship with their own set. Adyen, Square, and most other gateways do the same. These lists are stable and free, and the numbers are shared across the industry on purpose, which is exactly why none of them work in production.

What you can actually test

• Hard declines, like a generic card_declined response.
• Soft declines such as insufficient_funds, which should route into a retry flow.
• 3D Secure challenges, including both the pass and the fail branch.
• AVS and CVV mismatch handling.
• Partial captures, refunds, and currency mismatch errors.

What they cannot do

A sandbox number will not authorize on a live endpoint, will not move funds, and will not tell you anything about a real account. If a test number works outside test mode, the gateway configuration is broken, not the number.

Keep real card data out of test

Never copy production PANs into staging just to make a test run look realistic. PCI DSS requires live cardholder data to be protected and kept out of development and test environments, and staging systems rarely carry the same controls. Use test numbers, or use tokens issued by your processor. When you need a realistic dataset, generate one instead of pulling it from the production database.

One habit that saves time later: pin the test number behind each failure case in a comment next to the assertion. Six months on, nobody remembers why that one decline number matters.