3D Secure Test Card Guide: Simulate 3DS Challenges in Sandbox

A 3D Secure test card is a sandbox-only card number issued by your payment processor that forces a specific authentication result: frictionless pass, challenge presented, challenge failed, or an outright error. You use it to test your 3DS integration without touching a real card. There is no universal test card. Each processor publishes its own list, and those numbers work only inside that processor's test environment.

One thing worth stating up front, because it trips people up: sandbox test PANs are not payment credentials. They validate against a simulator, not an issuer. Run one through a live gateway and it declines.

Why no single number covers 3DS

3DS is a handshake between your gateway, the card network, and the issuer's access control server. In test mode, the processor plays the role of the ACS and decides what happens next. That decision gets keyed to the PAN you send. Every processor built its own simulator, so the numbers differ from one to the next.

This is why a card that reliably triggers a challenge on one gateway may return frictionless on another. Port your test suite between processors and you will need their test data.

What a good test set covers

Authentication outcomes are the whole point. I want at least these paths exercised before I trust an integration:

• Frictionless authentication, where the issuer approves with no cardholder interaction
• Challenge flow, where the cardholder sees the OTP or app prompt and approves
• Challenge flow where the cardholder fails or abandons
• Authentication unavailable, so the transaction falls back to a non-3DS authorization
• An ACS timeout or error, to confirm your retry and fallback logic holds

Some processors also expose cards that simulate an unsupported card type or a version downgrade from 3DS2 to 3DS1.

Reading the result

Do not stop at the redirect. The data returned from the authentication step is where the real signal lives. Look at the transaction status value, the ECI indicator, and the CAVV alongside the XID. Those fields determine whether liability shifts to the issuer and whether you should proceed to capture. A test card that returns a successful challenge but no CAVV tells you something is broken in your parsing, not your flow.

Common mistakes

• Using live API keys in test mode, which turns a harmless sandbox run into a real authorization attempt
• Assuming one processor's test PANs work on another's sandbox
• Testing only the happy path and shipping without a fallback for failed authentication
• Skipping the device fingerprint step, which many risk engines use to decide frictionless versus challenge

Where to find them

Your processor's developer documentation is the only correct source. Stripe, Adyen, Checkout.com, Braintree, and Worldpay all publish sandbox card lists mapped to specific authentication results, usually with a table showing which number triggers which outcome. Pull the list from the docs for the version of the 3DS spec you integrated. When the processor updates its simulator, that table changes, so check it again before a major release.