A 3D Secure test card is a sandbox card number that triggers 3DS authentication flows without moving real money. Payment processors publish these numbers for developers who need to test challenge screens, frictionless checks, and failure paths. Use them only in a test environment, never with real cardholder data.
What does a 3D Secure test card do?
It lets you simulate the extra verification step that banks add to online card payments. The test card number tells the processor to return a chosen 3DS result, such as “authentication required” or “authentication failed.” Your code then handles the redirect or in-app challenge the same way it would in production.
Test cards do not carry real credit limits or bank accounts. They exist to exercise your payment integration, not to buy goods or services.
How does a 3DS test card work in a sandbox?
The processor maps each sandbox card number to a scenario. When you submit the card in test mode, the processor responds with the scenario’s result. Some cards skip the challenge and return a frictionless pass. Others force a challenge screen where you enter a test code or choose pass or fail.
- Frictionless flow: the issuer approves the payment without an extra challenge.
- Challenge flow: the issuer asks for a one-time code or app approval.
- Failure flow: the issuer declines the authentication or returns an error.
- Timeout flow: the challenge expires before the customer finishes.
Where do you find 3D Secure test cards?
Use the sandbox documentation from your payment processor. Stripe, Adyen, Checkout.com, and other gateways each publish their own test card lists. The numbers are not universal. A card that forces a 3DS challenge on one gateway may decline as an unknown card on another.
For example, Stripe’s test docs list 4000 0000 0000 3220 as a card that requires 3D Secure authentication. Treat that number as a Stripe sandbox example, not a number for live payments.
How do you plan 3DS test cases?
Build a short matrix before you write test scripts. Map each business case to a card scenario from your processor. Include one happy path, one challenge fail, one timeout, and one frictionless pass.
- Success: challenge passes and the payment captures.
- Soft decline: authentication fails but the order can be retried.
- Hard decline: the payment stops and the customer sees a clear next step.
- Abandoned challenge: the customer closes the window and your system marks the order as pending.
Keep the matrix in your repo. Update it when your processor changes test cards or 3DS rules.
How do you test a 3D Secure flow step by step?
- Open your payment integration in test mode and confirm the sandbox API keys are active.
- Pick a test card from your processor’s docs that matches the scenario you need.
- Submit the card with a test expiration date and any test CVC the docs provide.
- Complete or fail the challenge screen when it appears.
- Check the payment intent, charge, or order record for the expected status.
- Repeat the test for frictionless, challenge, declined, and timeout cases.
Run each case after code changes. A small UI change can break the challenge redirect or the return URL.
What should you verify in a 3DS test?
Check more than the final “paid” or “failed” message. Your logs should show the authentication result, the threeDSecure status, and the liability shift flag when your processor returns one. Confirm that your app sends the customer back to the right page after the challenge.
- The order status matches the 3DS result.
- The customer sees a clear message for a failed challenge.
- Your system does not mark a failed authentication as paid.
- Retries do not create duplicate charges in test mode.
- Webhooks and API responses agree on the final state.
What is the difference between a 3DS test card and a real card?
A real card connects to a bank and can move real money. A 3DS test card connects to a sandbox and returns scripted results. Test cards also skip real issuer risk checks, so your test pass rate will not match production.
Do not buy card data or use real cards for testing. That practice creates a data breach risk and violates card network rules.
What mistakes should you avoid when testing 3D Secure?
Many failed tests come from mixing live keys with test cards or using a test card from a different gateway. Another common issue is a return URL that points to a live domain instead of the sandbox flow.
- Using a test card in live mode.
- Testing only the success case.
- Ignoring the authentication result in your database.
- Forgetting to test the back button and timeout path.
Frequently asked questions about 3D Secure test cards
Can I use any test card number for 3DS testing?
No. Use a card from your own processor’s sandbox list. 3DS behavior is tied to the gateway and the card scenario it defines.
Do 3D Secure test cards work in production?
No. Production systems reject sandbox card numbers. Use them only in test mode.
What test card forces a 3DS challenge?
It depends on the processor. Stripe’s sandbox uses 4000 0000 0000 3220 for a 3DS challenge. Check your gateway’s docs for the matching number.
Is it legal to use test card numbers?
Yes, when you use them in a sandbox you control for payment integration testing. Using real card numbers without permission is not legal.
Why does my 3DS test card get declined?
The card may belong to another gateway, your account may be in live mode, or your test scenario may expect a different challenge result. Check the processor’s docs and your API logs.