Adyen Test Card Numbers: How to Use Them in the Sandbox

Adyen test cards are the fake card numbers you run through the Adyen test environment. They act like real cards inside the sandbox, approve or decline based on the number you pick, and never touch a bank. The old standby 4111 1111 1111 1111 gives you a straightforward approved Visa payment. For everything else, including numbers that trigger specific decline codes and 3D Secure outcomes, use the current list in Adyen's own documentation rather than a list you found on a forum.

Where the numbers come from

Adyen maintains a test card page in its docs and keeps it updated. Each entry lists the brand, the number, and often the outcome it produces. The reason to go to the source is drift: test numbers get added and retired, and a number that worked two years ago may no longer hit the scenario you want. A pasted list from a blog post is a guess. The docs page is not.

You will also see the same handful of numbers floating around everywhere, and some of them are genuinely universal. The Amex 3700 0000 0000 002 and the Discover 6011 1111 1111 1117 are the ones I still see most in integration tests.

What to type for expiry and CVC

With test cards, the expiry date just has to be in the future. Any future month and year works. The CVC is any three digits, or four for American Express. Nothing validates those fields against a real issuer, because there is no issuer.

For 3D Secure, Adyen documents a test password in its 3DS testing guidance. The card number decides whether you get a frictionless flow, a challenge, or a failure, and the password decides the challenge outcome. Read the table before you start debugging your challenge handler, because a failing 3DS test is frequently the card choice and not your code.

Test cards only work with test credentials

Test card numbers are rejected when you point them at live credentials, and real card numbers are the wrong tool in every test scenario. Keep the two environments separate in your config. If a test card suddenly fails across the board, check the API key, the client key, and the merchant account before you touch anything else. Nine times out of ten it is a live key in a test slot.

Choosing a card by scenario

• Happy path: a plain Visa or Mastercard test number with a future expiry.
• Specific decline: the number Adyen lists for that refusal reason, so you can exercise your error copy.
• 3DS challenge: a 3DS test card plus the documented test password.
• Refunds and partial captures: any approved test card, since the payment is what you are reversing.
• Brand rules: an Amex test number when you need to prove four digit CVC handling.

Mistakes I see often

• Using a real card number in the sandbox to "make it realistic." Never do this. Real cardholder data does not belong in a test environment under any PCI program.
• Hardcoding the test card in committed code. Put it in a fixture or env var.
• Testing only the approved path. Declines and 3DS failures are where integrations break in production.
• Assuming every test number supports every payment method. Some are card only, and some are tied to specific flows.

Bottom line: grab the numbers from Adyen's docs, use any future expiry and any CVC, keep your test and live credentials far apart, and test the failures as carefully as the successes.