An Adyen test card is a fake card number that Adyen publishes for use only in its sandbox environment. It lets you simulate approvals, refusals, pending states, and 3D Secure challenges without moving real money. Test cards only work against test API keys and a test merchant account, so they can never charge a real customer.
What an Adyen test card actually is
Adyen maintains a set of dummy card numbers that behave like real cards inside the sandbox. Each number is tied to a specific card brand, a fixed expiry date, and a fixed security code. You must enter those values exactly as published, because the sandbox validates the full set rather than just the number.
Because these are sandbox credentials, they exist to exercise your integration: creating a payment request, receiving a result code, and handling webhooks. They carry no balance and no issuing bank.
Why the sandbox rejects real card numbers
Adyen separates test and live traffic at the account level. A payment sent with a live card number to a test endpoint will not be processed, and a test card sent to a live endpoint will be declined. This separation is deliberate and protects both merchants and cardholders.
Where to find Adyen test card numbers
- The official Adyen documentation publishes a test card page grouped by region and card brand.
- Each entry lists the card number, expiry, and CVC you need to submit.
- A separate set of test cards is published for 3D Secure authentication flows.
- Local payment method test credentials are listed alongside the card tables.
Always pull these values from the current documentation rather than from a blog post or a screenshot. Test card sets change when Adyen updates its sandbox.
Simulating different payment outcomes
The main reason to use a specific test card is to force a particular result. Adyen maps certain numbers to certain outcomes so you can verify your handling of each case.
- Authorised numbers return a successful result code and appear in your test Customer Area.
- Refused numbers return a refusal reason so you can test your error messaging.
- Pending or error numbers let you check asynchronous webhook handling.
Read the resultCode and refusalReason fields in the response, then confirm that your backend stores and acts on them correctly.
Testing 3D Secure with test cards
Adyen publishes dedicated test cards for authentication scenarios. Depending on which number you submit, the sandbox can return a frictionless flow, a challenge flow, or an authentication failure. This is useful for confirming that your redirect, return URL, and order confirmation logic all work before you enable live 3D Secure rules.
Common mistakes when testing
- Mixing a live API key with sandbox endpoints, or the reverse.
- Changing the published expiry or CVC and then wondering why the payment fails.
- Testing only the happy path and never the refusal or error branches.
- Ignoring webhooks and trusting the redirect response alone.
- Copying test credentials into a production configuration file.
Keep test data and real card data apart
Sandbox testing is a development activity, and real cardholder data has no place in it. Never paste a live card number into a test environment, a staging database, or a support ticket. If your integration stores card data at all, follow the PCI DSS requirements for encryption, access control, and retention, and prefer tokenisation so the raw number never touches your servers.
Used correctly, an Adyen test card gives you a fast, safe way to cover every payment branch your customers might hit, long before your first live transaction.