The best Adyen test card is the number Adyen publishes for the exact outcome you need to reproduce, taken from the test card page in Adyen's own documentation. Every Adyen test card is tied to a result: an authorised payment, a refusal with a named reason, a pending status, or a 3D Secure challenge. I ranked the options below on four criteria: outcome coverage, 3D Secure behaviour, payment method and currency support, and how easy the card is to confirm in the test Customer Area.

What an Adyen test card is

An Adyen test card is a card number that exists only in the test environment. It moves no real money, settles nothing, and is rejected by the live environment. To use one you need a test company account and a test API key; the live key will not authenticate the same request. The standard test cards are value agnostic, so a plausible expiry date, CVC, and cardholder name will pass. The card number itself carries the meaning.

Option 1: The published test card list

Adyen maintains its own list of test card numbers grouped by card scheme and by expected result. This is the source of truth for the sandbox, because Adyen updates it when acquirer behaviour or scheme rules change.

  • Pros: covers every result Adyen supports, kept current, mapped to scheme and payment method.
  • Pros: no guesswork about which card triggers which response.
  • Cons: requires reading the table carefully, since two similar numbers can produce different results.
  • Cons: the list is long, and copying a number from a blog instead of the source is a common cause of failed tests.

Use this option for baseline checkout testing, scheme coverage, and any test where you need a documented expectation.

Option 2: Result code cards for error handling

Adyen publishes test cards that force a specific refusal, error, or pending outcome. These are the cards you want when you are building retry logic, decline messaging, or webhook handling.

  • Pros: lets you reproduce a refusal on demand instead of waiting for a real one.
  • Pros: exercises your authorisation response handling, including refusal reason codes.
  • Cons: only meaningful if your integration reads and stores the refusal reason.
  • Cons: a card that refuses in the sandbox tells you nothing about how a real issuer will behave.

Choose this option when the payment fails in production and you need to prove your code handles the same failure correctly.

Option 3: 3D Secure test cards

Adyen provides separate test cards for 3D Secure flows, including cards that complete without a challenge and cards that trigger one. The challenge step uses documented credentials supplied alongside the card.

  • Pros: the only reliable way to test the challenge and frictionless paths before go live.
  • Pros: exposes redirect and return handling bugs early.
  • Cons: behaviour depends on the 3D Secure version and on the rules you configure in the test account.
  • Cons: a passing sandbox challenge does not guarantee a smooth live challenge, since issuers run their own risk checks.

Use these cards for authentication work, especially before enabling a new payment method.

Option 4: Saved and tokenised test cards

Once a test card is stored against a shopper, later charges reference the token rather than the number. This lets you test recurring, subscription, and one click flows.

  • Pros: mirrors the real lifecycle of a returning customer.
  • Pros: good for testing stored payment method logic and shopper references.
  • Cons: token records live in the test environment only and cannot be promoted to live.
  • Cons: clearing stale test shoppers is manual housekeeping.

How to choose

Start with one standard test card to get a payment through end to end. Add result code cards when you write failure handling. Add 3D Secure cards when authentication is in scope. Add tokens when you build repeat payments. Keep a short note of which card produced which outcome in your test environment, because sandbox behaviour changes when Adyen updates its list.

Pitfalls to avoid

  • Never place real cardholder data in a test environment. PCI DSS requires that test and development systems use substituted data.
  • Do not expect test cards to work against live endpoints. They will be refused.
  • Do not hardcode test numbers in code that ships to production.
  • Do not treat a sandbox approval as proof that a live approval will follow.