The short answer
On Adyen test cards, the CVC is 737. American Express test cards use 7373, since Amex prints a four digit CID instead of a three digit CVC. The expiry that ships with most of those cards is 03/2030. Type any other code in the sandbox and the payment is usually refused with a CVC error, which is a feature rather than a bug: it lets you exercise the failure branch of your checkout without going near a real card.
Why the sandbox wants one fixed value
Test payments never reach an issuer. Adyen's test environment decides the result itself, so the card data has to be predictable. One published CVC value for every card keeps the test data set short and keeps outcomes stable across runs. The same logic explains why numbers like 4111 1111 1111 1111 exist at all. They are markers, not accounts.
Test CVC vs live CVC
In production the CVC is generated by the issuer when the card is printed and checked during authorization. It is never stored anywhere in your stack after that. In the sandbox there is no issuer, so 737 stands in for the real thing. Nothing about the validation path changes; you are still sending the same field in the same API call. Only the answer comes from a different place.
Mistakes I see most often
- Mixing environments. Test cards only work with test API keys and the test endpoint prefix.
- Typing a random CVC and assuming the card is broken. Swap in 737 and the charge clears.
- Forgetting the four digit rule for Amex. Three digits get rejected by client side validation before Adyen ever sees them.
- Hardcoding the sandbox expiry into shared config and shipping it later. Keep test credentials in a separate environment file.
- Testing only the happy path. The refusal case is the one most checkouts handle badly.
Testing a CVC decline on purpose
Send a code that is not 737, for example 999, and watch what your code does with the refusal. Check that the message shown to the shopper stays neutral, that you do not retry the same card in a loop, and that the order is either not created or rolled back cleanly. Adyen also publishes cards for other scenarios such as 3D Secure challenges, fraud results, and refunds, and those sit alongside the CVC values in the same reference.
What the CVC does in production
The CVC is a check against card not present fraud. It can shift liability in some cases, and it gives you one more signal for scoring a transaction. It is also the one piece of card data you are forbidden from keeping after authorization. Any system that stores it falls outside PCI scope compliance and will fail an audit. None of that applies to the sandbox, but building as if it does saves rework when you go live.
Where to get the full test data set
Adyen publishes test card numbers, CVC values, expiry dates, and matching address verification data in its documentation. Copy the table once into a fixture file for your test suite so nobody has to look it up mid sprint. If a test card suddenly stops working, check the docs before you file a ticket. Expiry dates get rotated and new scenario cards get added from time to time.