Short answer
Processors publish test card numbers for sandbox accounts. A test number passes the Luhn checksum and returns a result code from a simulated issuer. It moves no money. It fails against a live API key.
Credit Card Test Cases: Buying Guide for Payment QA
Published test numbers
Stripe documents 4242 4242 4242 4242 as an approval card. Any future expiry date and any 3 digit CVC work with it. The same docs list cards for failure paths:
- 4000 0000 0000 0002: generic decline
- 4000 0000 0000 9995: insufficient funds
- 4000 0000 0000 0069: expired card
- 4000 0000 0000 0127: incorrect CVC
PayPal and Braintree publish a separate set for their sandbox. Adyen and Checkout.com do the same. Test numbers stay inside one processor. A Stripe test PAN returns nothing from Adyen.
Luhn check
The Luhn algorithm doubles every second digit from the right, sums the digits, and tests the total against mod 10. A 16 digit string that fails this check is rejected at the form. Test numbers pass. Numbers you invent do not.
Credit Card Test for Beginners Guide
Decline codes
Gateways return short strings. Common values: do_not_honor, insufficient_funds, expired_card, incorrect_cvc, card_not_supported, processing_error. A test plan covers one card per code so the checkout UI shows the correct message.
Sandbox against live
A live key sends the PAN to the card network. Networks decline unknown numbers. A test card has no issuer account behind it. A card number that belongs to another person is an access device under 18 U.S.C. 1029 in the US. Use one and the offense is federal.
Test checklist
- Create a sandbox account. Copy the test publishable key and the test secret key.
- Run one approval and one decline per payment method.
- Run the 3D Secure test card for the authentication step.
- Run refund, partial refund, and dispute simulation.
- Log the response code and the last four digits. PCI DSS limits storage of the full PAN.