A 3D Secure test card is a published sandbox card number that triggers a specific 3DS authentication outcome, such as a challenge prompt, a frictionless approval, or a failed authentication. Test cards work only against a payment provider's test environment, never against live card networks, and they carry no real account data.
What does a 3DS test card actually do?
It tells the sandbox which authentication scenario to simulate when a payment is created. The provider's test gateway reads the number and returns the matching 3DS result to your integration.
Because the outcome is scripted, you can reproduce edge cases on demand: an ACS challenge that times out, an issuer that does not support 3DS, or a successful authentication that later fails authorization.
Which details do I enter with a test card?
Test cards accept any future expiry date, any three or four digit security code, and any plausible billing postal code unless the provider's documentation says otherwise. The card number alone usually decides the scenario.
- Use a future expiry such as 12/34 so validation does not reject the request.
- Keep the CVC numeric and three digits for Visa and Mastercard test numbers.
- Use test API keys, never live keys, so no real authorization is attempted.
How do I trigger a 3DS challenge in test mode?
Create a payment with a card number that the provider maps to an authentication-required result, then complete the challenge in the simulated ACS window. Stripe, for example, documents dedicated numbers for 3DS1 and 3DS2 challenge flows in its test mode documentation.
Watch the payment intent or transaction status change from requires_action to succeeded or failed. That transition is the part of your code most likely to break in production.
How do I test frictionless and unsupported flows?
Frictionless means the issuer authenticates the cardholder without any interaction, so your redirect or challenge iframe should never appear. Providers publish separate numbers for this outcome, and some also publish numbers for issuers that do not participate in 3DS at all.
- Frictionless success: confirm the payment returns without showing a challenge UI.
- 3DS not supported: confirm your fallback path and any liability shift logic behave as expected.
- Authentication attempted but not completed: confirm the order is not marked paid.
How do I test failed authentication and liability shift?
Use a number tied to a failed or rejected authentication and check that your system cancels the order, releases any hold, and logs the reason code. Liability shift only applies when authentication succeeds, so a failed authentication must leave the risk with the merchant.
Record the three DS version, the electronic commerce indicator, and the authentication result in your database. Those fields decide who absorbs a chargeback later.
Which mistakes break 3DS test runs?
- Mixing live publishable keys with test card numbers, which returns an unhelpful generic decline.
- Hardcoding a single card number and never exercising the failure branches.
- Testing the challenge window only on desktop and skipping mobile redirect handling.
- Assuming a test approval means your production risk rules are correct.
Provider test tables change, so re-check the current documentation before each release cycle. Adyen and Checkout.com both publish per-country test numbers with configurable authentication results, which helps when you need region-specific behavior.
Frequently asked questions
Are 3DS test cards real credit cards?
No. They are reserved sandbox numbers that resolve only inside a provider's test environment and cannot be charged.
Can a test card be used on a live site?
No. Live gateways reject them, and using sandbox credentials against production is a configuration error that should fail loudly.
Do I need a real bank to test 3DS?
No. The payment provider simulates the access control server, so the entire challenge and frictionless flow runs inside the sandbox.