Stripe's 3D Secure test card set is the top pick for most teams, because one sandbox covers frictionless approval, challenge approval, and authentication failure with no real issuer in the loop. The criteria that separate the options are outcome control, scheme coverage, documentation, and whether you can reproduce a failed authentication on demand instead of waiting for a random result.

3d secure test card v7

What the v9 in a test card search points to

There is no EMVCo specification called 3D Secure v9. EMVCo owns the standard and numbers it 3DS 2.1, 2.2, and 2.3.x. When a test card table shows a version tag such as v9, that tag belongs to a merchant plugin, an SDK release, or the internal test matrix the table was copied from. It does not belong to the card.

3D Secure Test Card v8: What It Is and How to Use It Safely

That distinction matters. A card number alone does not produce a 3DS result. The outcome depends on the sandbox, the merchant profile, the amount, and the authentication value the issuer simulator returns. Anyone selling you a "v9 card" as a standalone product is describing a label, not a technology.

3d secure test card v10

Option 1: Stripe test cards

Stripe publishes a set of test card numbers for 3D Secure inside its test mode documentation. The numbers sit in Visa test ranges, and each one is tied to a documented authentication outcome: frictionless pass, challenge required with a pass, challenge required with a failure, and 3DS not supported.

related article

Pros

• A separate number for each outcome, so a challenge pass and a challenge fail are one field change apart
• Works with PaymentIntents and SetupIntents, which lets you test off-session charges and subscription renewals
• Documentation covers both 3DS1 and 3DS2 response fields
• Free test mode, no merchant account approval required

Cons

• Only Visa outcomes are simulated, so Mastercard or Amex challenge behavior stays untested
• Issuer timeout, ACS downtime, and malformed authentication responses need your own mocks
• Live keys ignore the test numbers, which is a common source of confusing results

Use case: a team already on Stripe, or any team that needs to see the challenge page render inside a JavaScript integration before writing a full test matrix.

Option 2: Adyen test cards

Adyen ships a test card list with dedicated 3DS numbers and states the expected result for each one. Its test environment also lets you influence the authentication result through request fields, which is useful when the card number alone is not enough.

Pros

• Coverage across Visa, Mastercard, and Amex, so scheme differences show up in testing
• Separate instructions for API-only, Components, and Checkout SDK integrations
• Native app challenge testing, not just browser redirects

Cons

• You need a test merchant account and API key before the cards do anything
• Some results require specific request fields, so a copied card number often fails
• Documentation is split across product lines and versions

Use case: teams that need multi-scheme coverage, or mobile teams testing the app-based challenge on iOS and Android.

Option 3: Braintree and PayPal sandbox

Braintree's sandbox includes test values that authenticate or fail authentication, and it pairs with the PayPal wallet flow. The tradeoff is fewer distinct outcome cards than the gateways above.

Pros

• Sandbox ties 3DS testing to vault and PayPal wallet flows in one place
• Straightforward setup for teams already using Braintree for card and wallet payments

Cons

• Smaller set of authentication outcomes to choose from
• Sandbox rules can force 3DS behavior regardless of the card you submit, which hides real card behavior

Use case: a checkout where PayPal is a primary payment method and 3DS needs to be tested alongside wallet authentication.

Criterion: can you force the outcome you need?

Before you build a test suite around any sandbox, confirm four paths are reachable:

1. Frictionless approval, where no challenge appears and the charge completes
2. Challenge approval, where the shopper completes authentication and the charge completes
3. Challenge failure, where authentication fails and the charge is declined or left unauthenticated
4. Error paths, including issuer timeout and an unsupported authentication version

If a provider covers only the first two, you will end up mocking the rest in your own code, and mocked paths tend to drift from production behavior.

How to run a 3DS test without live cards

1. Create a sandbox or test mode account with the provider you picked.
2. Load the provider's 3DS test card numbers into your test fixtures instead of typing them into the UI by hand.
3. Submit a payment and capture the full response, including the ECI, the authentication value, and the directory server transaction ID.
4. Assert on those fields in your test, not just on the final charge status. A charge can succeed with a skipped authentication step.
5. Repeat for each failure card and log the raw response so a documentation change does not leave you guessing.

Mistakes that waste a test cycle

• Running tests with live credentials and expecting test card behavior
• Assuming a card number triggers 3DS on its own, when the merchant profile and amount decide that
• Copying a test card table from a blog post instead of the provider's current documentation
• Testing the happy path only, then discovering the decline path in production
• Ignoring the authentication value in the response, which is what your fraud rules and liability shift actually read

The short version: pick a sandbox that lets you choose the authentication outcome, treat the v9 label as a plugin version rather than a card feature, and assert on the 3DS response fields instead of the charge status alone.