3DS challenge card testing is the practice of running PSP-issued sandbox test cards through a 3D Secure 2 flow to confirm the issuer ACS actually interrupts the payment, presents a challenge, and returns an authentication value your authorization request can consume. It is done exclusively in a test environment with test PANs, never with real cardholder numbers. The objective is to prove the challenge branch of your integration works before live traffic depends on it.
What triggers a 3DS challenge instead of frictionless?
The ACS decides between frictionless and challenge based on risk scores, device fingerprint data, transaction amount, merchant category, and any exemptions your gateway requests.
In a sandbox, that decision is simulated. Most processors expose test cards whose behavior is hard-coded, so a specific PAN always produces a challenge and another always returns frictionless.
Which test cards force a 3DS challenge?
Card networks and processors publish dedicated 3DS test PANs in their developer documentation. Stripe, for example, lists separate numbers for 3DS-required, 3DS2 challenge, and frictionless scenarios.
- Stripe
4000002500003155: triggers 3D Secure authentication. - Stripe
4000008400001629: runs the 3DS2 challenge flow. - Adyen and Checkout.com publish equivalent test PANs in their own test card tables.
Always pull the current list from your processor's docs. Test card behavior changes when the ACS simulator is updated.
How do you run a 3DS challenge test step by step?
- Switch your integration to the processor's sandbox base URL and test API keys.
- Create a payment intent or session using a test PAN that is documented to force a challenge.
- Complete the challenge in the ACS simulator iframe or via the native 3DS2 SDK.
- Capture the authentication result, ECI value, and CAVV from the response.
- Submit the authorization and confirm liability shift is recorded.
What results should you assert after the challenge?
A passing test verifies the full parameter set, not just a success screen. Confirm the threeDS version, the transStatus value, the ECI, and the CAVV or AAV are all present and correctly propagated.
- transStatus Y: authenticated, liability shifted to the issuer.
- transStatus N: not authenticated, expect a decline or a non-shifted authorization.
- transStatus U: unavailable because of a technical error or timeout.
- transStatus A: attempted, typically from a 3DS1 fallback or an issuer that is not enrolled.
Also test the abandonment path. Close the challenge window mid-flow and confirm your system handles the resulting timeout without leaving an orphaned order.
Why does a test card skip the challenge?
The most common causes are a cached device fingerprint, a sandbox amount below the challenge threshold, or a stored credential flag on a returning customer profile.
Clear cookies and local storage between runs, use a fresh customer ID, and confirm your gateway is not silently requesting a frictionless exemption.
What are common 3DS testing mistakes?
- Testing only the happy path and never the N, U, or timeout branches.
- Ignoring 3DS Method URL failures that force an unexpected fallback.
- Hard-coding the challenge window size and breaking the mobile SDK layout.
- Assuming a frictionless result means 3DS is fully configured.
Can you test 3DS with real card numbers?
No. Using real cardholder data outside a compliant production flow violates PCI DSS and card network rules. Test PANs exist precisely so this is never necessary.
If you need production validation, use a real card that you personally own and issue it through your own live account, or rely on your acquirer's certification script.