Stripe test cards and test card numbers

A real card number in a test environment brings that environment into scope for PCI DSS, the payment card security standard, with all the controls that implies. It also tends to end up in logs, screenshots and defect reports, which is how card data leaks from organisations that would never knowingly store it. Gateway test numbers exist so that nobody needs to.

The validator flags any number that passes the Luhn check but is not a published test number. That is not proof it is a real card, but it is reason enough not to paste it anywhere else.

The Luhn algorithm is a checksum: the last digit is calculated from the others so that a mistyped number can be caught before a payment is attempted. It catches every single-digit error and almost every swap of two adjacent digits. It says nothing about whether the account exists, has funds or belongs to the person typing it.

For a checkout form that makes it a fast, local first check, never a substitute for the gateway response. A form that accepts a number because it passes Luhn, and then handles the gateway decline badly, has tested the easy part.

Start from the rightmost digit, which is the check digit, and move left. Leave that digit as it is and double every second digit after it. Where doubling gives a two-digit number, subtract 9, so 8 doubled becomes 16 and then 7. Add every digit together. The number is valid if the total is a multiple of 10.

The textbook example is 79927398713. From the right, the digits contribute 3, 2, 7, 7, 9, 6, 7, 4, 9, 9 and 7, which total 70. Seventy divides by ten, so the number passes. Change any single digit and the total moves off a multiple of ten, which is how the check catches typing errors.

Implementations go wrong in three predictable places: doubling from the left instead of the right, which only works for numbers of even length; treating the input as a number instead of a string, which silently loses precision on most card numbers because they exceed the largest integer JavaScript can hold exactly; and validating before stripping the spaces people type. A unit test with a 15-digit American Express number catches the first.

Most checkout testing stops at a successful payment, but a decline is the moment a customer most needs the interface to help. Each decline needs a different response from the interface. Insufficient funds should invite another payment method. An expired card should point at the expiry field. An incorrect CVC should mark that field without clearing the rest of the form. A processing error should allow a retry without creating a duplicate order.

A card blocked for fraud is the exception: the message to the customer should be generic. Telling someone their payment was blocked as suspected fraud helps a fraudster calibrate the next attempt.

Strong customer authentication is mandatory for most card payments in the UK and the European Economic Area, and the Reserve Bank of India requires an additional factor of authentication for domestic card payments made online. The authentication cards trigger that challenge, so test the full journey: the challenge appearing, the customer completing it, the customer abandoning it, and authentication failing.

The abandoned case is the one most often broken. A customer who closes the challenge window should land somewhere sensible with their basket intact, not on a blank page or a duplicate order.

The dispute card charges successfully and is then disputed. That tests what most teams never look at: whether the dispute notification from the gateway is received, whether the order is flagged, whether stock and fulfilment respond, and whether anyone is told. These are webhook flows, so they need testing on an environment that can actually receive the gateway’s webhooks.

Test numbers only work in the sandbox of the gateway that published them, and the same number can mean different things to different gateways. 5105 1051 0510 5100 completes a payment in Stripe and Razorpay test modes but fails card verification in the Braintree sandbox. The validator above lists every meaning a number has.

Some gateways do not use card numbers to select an outcome at all. In the Braintree sandbox, a transaction amount between 2000.00 and 2999.99 is declined by the processor with a response code equal to the amount, whichever test card is used. Razorpay test mode instead shows a mock bank page where you choose success or failure. Adyen uses the cardholder name: pay with any Adyen test card and enter DECLINED, CARD_EXPIRED or another listed value as the name to receive that refusal.

The Stripe, Razorpay, Braintree and Adyen numbers here are listed in full because each was checked against that gateway’s documentation. Gateways do change their test numbers, so their own documentation remains the authority, and for every other gateway it is the only source to use.