Short answer: there is no universal "3DS v1.0 test card" anymore. In a sandbox you use the card numbers your payment provider publishes, and those numbers only trigger authentication inside that provider's test environment. If your integration still runs the old 1.0 redirect flow, the cards for it live in your acquirer's documentation, not in a public list.

3D Secure Test Card V9

Why v1.0 Is a Legacy Question

EMVCo owns the 3D Secure spec, and version 1.0 was wound down at the card network level starting in 2022. Visa and Mastercard pushed merchants toward 2.x, and most gateways stopped simulating the 1.0 redirect on new accounts. Plenty of businesses still run a 1.0 endpoint for one legacy acquirer, but the test data for that path comes from the acquirer, and it changes without much warning.

3d secure test card v2

So when someone asks for a "3DS v10 test card," they are often asking the wrong question. They want a number that forces an authentication step in a sandbox, and that behavior is defined by the gateway, not by the card brand.

more on this topic

What a Test Card Controls

A sandbox card number is a switch. It tells the simulator which outcome to return at three points:

3D Secure Test Card V6

• Enrollment: whether the card sits in the ACS directory, which is the Y, N, or U value you see in the response.
• Challenge: whether the issuer asks for a password or one-time code, or lets the payment pass without friction.
• Result: authenticated, attempted, or failed, plus the ECI value your code has to read and store.

Good test suites cover all of those, not just the happy path where the customer types a password and everything approves.

Numbers You Will See Quoted

Stripe's documented list gets copied everywhere. 4000 0000 0000 3063 forces 3D Secure authentication, and 4000 0000 0000 3220 forces a 3DS2 challenge. Braintree, Adyen, and Checkout.com each keep their own set with their own trigger rules, so a card that challenges on one gateway may approve with no prompt on another. Say this out loud before you paste numbers into a test file: pull them from the provider you are integrating, and re-check the page when the test fails.

Test the Flow, Not Just the Number

3D Secure is a browser dance, and the card is the small part. You need a real browser session with cookies and the same origin, a return URL that matches what you registered, and a page that handles the POST from the ACS. On 2.x you also deal with the threeDSMethodURL step, the challenge iframe, and the difference between the web flow and the native SDK flow.

While you are in there, test the ugly outcomes. Let the challenge time out. Return a failed authentication and confirm your order does not ship. Retry the same card and make sure you do not double-charge. Those cases are where most integrations break in production.

Mistakes That Cost Time

• Running a sandbox card against a live account. It will decline, and it may flag the account.
• Assuming a 3DS2 test card works on a 1.0 endpoint. They are different flows with different data.
• Testing with a headless HTTP client. No browser, no authentication.
• Copying a card list from a blog post written three years ago.

One more note: test cards are sandbox tools and nothing else. They do not authenticate a live card, and they are not a shortcut around an issuer check. Keep real card data out of your test environment and leave the production keys in the vault.