Short answer
An Adyen test card is a fake card number that only works against Adyen's test environment. You pair it with any future expiry date and any three or four digit CVC, send it through the /payments endpoint with a test API key, and Adyen responds with a simulated result instead of moving real money. The authoritative list of numbers lives in the Adyen documentation under test card numbers, and it is organized by payment method and by the result you want to see.
Where the numbers actually come from
I keep the Adyen docs tab pinned when I'm integrating, because the table changes. Adyen publishes test cards per scheme and per scenario: a plain authorised Visa, a Mastercard that comes back refused, an Amex for a different card length, and so on. Widely used generic numbers include 4111 1111 1111 1111 for Visa and 3700 0000 0000 002 for American Express, but treat those as starting points and confirm against the current docs page before you hardcode anything.
The important thing is the mapping. Each test number is tied to a specific outcome, so the card you pick decides whether you get Authorised, Refused, Error, or a redirect into a 3D Secure challenge. If your integration only ever sees Authorised, you haven't tested much.
Test mode versus live mode
- Test and live are separate environments with separate API keys and separate Customer Area accounts. A live key with a test card number fails, and a test key with a real card number is a compliance problem, not a feature.
- Expiry date can be any date in the future. CVC can be any digits of the right length for the scheme.
- Cardholder name matters on some test cards, because Adyen uses it to select a behavior. Read the notes column before you assume the name field is ignored.
Getting specific result codes
Most teams need three paths working: success, soft refusal, and a hard error that your UI has to survive. Adyen gives you test cards for each. Refusal reasons such as insufficient funds, expired card, or blocked card are simulated by specific numbers, and the response includes a refusalReason you can branch on. Build your error handling against those, not against a hand-written mock, because the real payload shape is what trips people up.
3D Secure and redirect flows
3DS testing is where I see integrations break. Some test cards trigger a challenge, some complete frictionless, and some deliberately fail authentication. You need all three to know your redirect handling, return URL, and webhook processing are correct. Webhooks are the part people forget: a test payment can be Authorised in the API response and still send an AUTHORISATION notification a moment later. Make sure your test setup receives those.
Mistakes worth avoiding
- Hardcoding one test number everywhere and calling the integration done.
- Skipping webhook verification in test, then discovering the gap in production.
- Using a real card number in the sandbox. Never do this. Test data is test data, and cardholder data handling falls under PCI DSS regardless of intent.
- Leaving live credentials in a repo alongside test credentials.
Once the happy path, the refusal path, and the 3DS path all pass in test mode, you have a reasonable claim that the integration works. Not a guarantee, but closer than most.