Your Test Credit Card Number Was Declined: Every Gateway's Sandbox List

4111 1111 1111 1111 is probably the most copied test card number ever written down, and Stripe does not list it.

Stripe wants 4242 4242 4242 4242. Adyen accepts 4111 1111 1111 1111, but only with the expiry 03/2030 and the CVC 737. Square wants a CVV of 111. Authorize.Net decides whether to decline you from the billing zip code. Braintree mostly ignores the card number and reads the amount instead.

Five gateways, five rules, none written down in the same place. I lost most of an afternoon to this once, convinced our tokenisation had broken, when the real problem was a Stripe number pasted into a Braintree sandbox.

What follows is the published list for each major gateway, the field that actually triggers failures, and the sandbox settings that make a working integration look broken. Every number comes from the gateway's own documentation.

Why your test credit card number works in one sandbox and not the next

A sandbox is not a simulation of the card networks. It is a lookup table.

Braintree says so directly: its sandbox only accepts specific test credit card numbers. Adyen is equally blunt, stating that its numbers work with Adyen's test platform and not on other platforms. There is no shared registry. Each gateway picked some digits, wrote them down, and hardcoded the responses.

So a card number in test mode is really a key into that gateway's response table, and a key with no matching row has no defined behaviour.

That produces the failure everyone hits eventually. Your number is Luhn-valid, the right length, the right prefix. It clears front-end validation and tokenises without complaint. Then it dies at authorisation with a message that tells you nothing, because the gateway has nothing to tell you.

Stripe: 4242, and none of the numbers you remember

Any future expiry works. Stripe's own example is 12/34. Other form fields are not validated at all.

Two of the three are shared with Braintree. The Visa is not, and that one difference causes real confusion, because the Mastercard case works and makes the integration look fine.

One rule that is easy to miss: Stripe's services agreement prohibits testing in live mode with real payment details.

PayPal hides its decline triggers in the cardholder name

PayPal publishes a long list. A useful subset:

Any future expiry, three-digit CVV, four for Amex. Standard so far.

The part that is not standard: to force a failure you leave the card alone and change the cardholder name. CCREJECT-REFUSED gives you a refused card, CCREJECT-EC an expired one, CCREJECT-SF suspected fraud. PayPal notes that these values are case sensitive.

Two things to check before deciding the triggers are broken. If your checkout does not collect a cardholder name, you have no way to send them. And if it title-cases the name before submitting, which plenty of forms quietly do, Ccreject-Refused arrives at PayPal and means nothing.

Braintree decides by amount, not by card

Braintree's cards are the conventional set: 4111 1111 1111 1111, 5555 5555 5555 4444, 3782 822463 10005, and 6011 0009 9130 0009 for Discover.

Then there is the split that catches almost everybody. Transaction success is determined by the amount you use. Verification success is determined by the card number you use. So a zero-dollar card verification ignores the amount table entirely, and to make one fail you need a number chosen for it, such as 4000 1111 1111 1115.

Practical version: a test suite that charges $2,500 to exercise the decline path is testing the amount and nothing else. Swapping the card number there changes nothing.

Adyen wants one expiry date and one CVC

All of them use expiry 03/2030 and CVC 737. The Amex CID is 7373, four digits.

That fixed expiry is the trap. Nearly every other gateway takes any future date, so a fixture that randomises the month and year sails through Stripe, PayPal, Braintree and Square, then fails on Adyen while showing a card number that is unmistakably correct.

Watch the lengths too. Diners at 14 and Amex at 15 both fail a form that validates a hardcoded 16 digits, in your own browser, before Adyen is ever contacted.

Square puts the failures in the CVV and the postal code

Square's success cards include 4111 1111 1111 1111 for Visa, 5105 1051 0510 5100 for Mastercard, 6011 0000 0000 0004 for Discover and 3400 000000 00009 for Amex. The CVV is 111 for all of them, 1111 for Amex, and any future expiry is accepted.

Failures come from the surrounding fields:

Look closely at 01/40. It is a future date, and Square still reads it as the wrong-date signal. Fixtures that randomise expiries across a wide window will eventually land on January 2040 and fail for no visible reason.

Postal codes are required for USD, CAD and GBP payments. Japan does not, which is worth knowing if a Japanese test behaves differently from the rest.

Authorize.Net: leave the sandbox in Live Mode

This one is not about cards at all, and it wastes more time than anything else on this page.

Authorize.Net's guidance is that your sandbox account should always be set to Live Mode. Transactions submitted in test mode are not stored, and they return a transaction ID of zero. So the API call succeeds, your code carries on happily, and then the transaction list is empty and there is no ID to refund against. The integration is fine. The account is in the wrong mode.

Its cards are unusual too:

Two of the Visas are 13 digits, a legacy length that plenty of modern client-side validators refuse outright. Any expiry after today is accepted.

Declines come from the billing zip: 46282 produces response code 2. The CVV field carries its own triggers: 900 returns a match, 901 a mismatch, 902 should-be-on-card, 903 issuer not certified, 904 not processed.

The number that shows up almost everywhere

That is the trap of a widely shared number. It looks like the constant across your integrations, so it never becomes a suspect, while the fields around it do all the work.

Checkout.com and Razorpay, briefly

Checkout.com accepts any future expiry with a three-digit CVV, four for Amex. The detail that bites is retention: its sandbox stores payments for 30 days, and a flow has to be completed inside that window. An old one failing today may have simply aged out.

Razorpay moves the switch somewhere else again. In test mode the outcome comes from the OTP, not the card. An OTP of 4 to 10 digits succeeds, fewer than 4 digits fails. Card tokens in test mode last 3 days, so a stored-card test that passed last week fails this week with a token error that has nothing to do with your code.

Test credit card numbers you generate yourself: when they are the right tool

Everything above concerns gateway sandboxes, where a generated number is worthless. There is a second job that looks identical and is not.

When the thing under test is your own code, the gateway never enters into it. A Luhn check in a form validator. Brand detection from the prefix. A CSV importer. Column widths in a database. A masking function that should print only the last four digits. Logging rules that must never write a full number to disk.

Published test numbers are a poor fit there. There are only a handful, every project uses the same ones, and they fall apart the moment you need a few dozen distinct values or want a uniqueness constraint to fire.

That is the gap the browser page we built to generate Luhn-valid card numbers fills. It computes the check digit rather than reading from a list: Visa gets prefix 4 across 16 digits, Mastercard 51 through 55, American Express 34 or 37 across 15, Discover 6011, 644 to 649 or 65. CVV is three digits, four for Amex, and expiries land one to five years out. You take 1, 5 or 10 at a time, and the CSV export puts network, number, expiry and CVV in separate columns, which is the shape a fixtures file wants. It runs in the page, so nothing is posted anywhere.

The limitation is the one stated above and it is absolute: none of those numbers will authorise in a sandbox. Different job, different tool.

What Luhn actually catches, and the four pairs it misses

Since so much of this rests on the word valid, be precise about what Luhn buys you.

The algorithm came from Hans Peter Luhn at IBM and is specified in ISO/IEC 7812-1. It catches every single-digit error, and nearly every transposition of two adjacent digits.

Nearly. It does not catch 09 swapped to 90, or 90 swapped to 09. And it misses three twin-digit substitutions: 22 mistyped as 55, 33 as 66, 44 as 77. A customer who types 5566 where 5533 belonged gets a number that passes your validator cleanly and fails at the bank.

It was designed to protect against accidental errors, not malicious attacks. It says nothing about whether a card exists, is active, or has money behind it. A Luhn-valid number is a well-formed string, and that is the entire claim.

A checklist before you file a sandbox bug

1. Confirm the number appears on that gateway's list. Not a list you found. Its list.
2. Check whether the expiry is pinned. Adyen wants 03/2030 exactly, most others take any future date, and Square treats 01/40 as a deliberate failure.
3. Check the CVV rule. Square wants 111 and reads 911 as a trigger. Adyen wants 737. Stripe accepts anything.
4. Identify which field carries the failure trigger: the amount in Braintree, the cardholder name in PayPal, the billing zip in Authorize.Net, CVV or postal code in Square, the OTP in Razorpay.
5. Verify the account mode. An Authorize.Net sandbox belongs in Live Mode, and test mode returns a transaction ID of zero.
6. Check your own field length validation. Amex is 15 digits, Diners can be 14, two Authorize.Net Visas are 13. A hardcoded 16 rejects all of them before the request leaves the browser.
7. If you are testing your own validator rather than the gateway, stop using published numbers and generate your own.

Step 4 is the one I would push hardest. Nearly every sandbox debugging session I have watched goes the same way: someone swaps the card number, gets the same result, swaps again, and works through the whole published list before noticing the card number was never the variable. Find the trigger field for your gateway and write it in the same file as your test credentials. The next person saves the afternoon you did not.