What a 3D Secure test card is
A 3D Secure test card is a card number that exists only inside a payment processor's sandbox. It never reaches a real bank and never moves real money. When you submit it, the processor routes the transaction through a simulated Access Control Server (ACS), which returns either a frictionless approval or a challenge page. That lets you watch how your checkout, your order logic, and your webhook handler behave when authentication is required, skipped, or failed.
Test card numbers are sandbox-only. They return an error in live mode. They are also not portable. A number published by one gateway will not authenticate on another, because each processor runs its own simulated ACS with its own decision rules. If a number fails, confirm you are in test mode and that you pulled the number from the documentation of the processor you are actually calling.
Prerequisites
- A sandbox or test-mode account with your payment processor
- Test API keys, not live keys
- A browser that allows third-party cookies and frames, so the challenge window can render
- Optional but useful: a webhook endpoint that receives authentication result events
How to test 3DS with a test card
- Open your processor's test card reference page in its developer documentation.
- Find the row that describes the 3DS behavior you want to reproduce, such as challenge required, frictionless approval, or authentication failure.
- Copy the card number from that row.
- Enter the number into your checkout form in test mode.
- Use any future expiry date, any three-digit CVC, and any valid-format postal code unless the docs say otherwise.
- Submit the payment and wait for the redirect or the embedded challenge frame to appear.
- Complete or abandon the challenge on the simulated ACS page, depending on the case you are testing.
- Check the dashboard transaction record for the authentication status and the liability shift flag.
- Inspect the webhook payload your server received and confirm the fields match the outcome you expected.
Choosing the right test card
Most processors publish several 3DS test numbers, each mapped to a different outcome. Common behaviors include a full challenge that you must pass, a challenge that you can fail, a frictionless approval with no user interaction, and an authentication error meant to simulate an ACS timeout.
Representative examples, all sandbox-only: Stripe test mode uses 4000002500003155 for a card that always requires authentication, and 4000000000003220 for a 3DS2 flow that raises a challenge. Adyen's test set includes 4212345678901237 for 3DS. Braintree's sandbox lists 4000000000003220 for a 3DS2 challenge. Gateways rotate and add numbers over time, so treat these as starting points and verify against current documentation before you build test fixtures around them.
What you should see
A successful challenge produces an authentication result of authenticated, plus a liability shift indicator on the transaction. A failed or abandoned challenge produces an authentication failed or not authenticated result, and your integration typically receives a decline or an authentication error code. A frictionless approval produces neither a challenge page nor a decline.
The outcome you care about most is the one your server stores. Read the authentication fields from the API response or webhook, not from the browser. Redirects can be spoofed or interrupted, and a client-side success message is not proof that authentication happened.
Common failures
- The challenge frame does not load. Third-party cookie or frame blocking is the usual cause.
- The card declines before any challenge. You are likely in live mode or using a live key.
- No authentication event arrives. Check that your webhook endpoint is reachable and that the event type is subscribed.
- The same card behaves differently after a processor update. Confirm the current expected outcome in the docs.
Why sandbox testing matters
3DS adds a step between authorization and capture, and that step introduces failure modes that do not exist in a plain card payment. Testing with sandbox cards lets you confirm that your idempotency keys hold, that retries do not double-charge, that your order state machine handles an abandoned challenge, and that liability shift is recorded correctly. None of that is safe to discover in production, and none of it requires a real card to verify.