The top pick for most teams is the Stripe test card set used in test mode, because it covers frictionless and challenge outcomes across Visa, Mastercard, and American Express without a contract or a sandbox approval step. I ranked each option on five criteria: card brand coverage, the ability to force a challenge or a frictionless result, coverage of authentication results such as Y, N, U, and A, access without a commercial agreement, and how clearly each provider documents what every number does.

related article

What "v4" actually refers to

The version number in a 3DS test card list labels the list, not the protocol. EMV 3-D Secure runs on 2.x versions in production, and providers renumber their test tables as they add cases for new brands, new message flows, and new authentication outcomes. A v4 list typically adds 3DS2 challenge cases, 3RI (requestor initiated) transactions, and decoupled authentication on top of the older frictionless cases. Treat any version label as a snapshot. Check the publication date on the provider page before you build a regression suite around it, because card ranges get retired when acquirer simulators change.

related article

Top pick: Stripe test cards

Stripe publishes test card numbers that map to specific authentication outcomes in test mode, including a successful frictionless flow, a challenge flow that you can approve or decline, and an authentication failure that lands as a declined payment. The same set works across the Payment Intents and Setup Intents APIs, which makes it useful when you test saved cards or off-session charges.

3d secure test card v5

• Pros: no application or contract needed, consistent behavior across brands, clear mapping between card number and outcome, works with 3DS2 challenge and frictionless paths, easy to script in CI.
• Cons: behavior is tied to Stripe's simulator, so results do not transfer to your live acquirer, the set does not cover every network-specific edge case, and you still need a second source if you support several processors.

Use it when Stripe is your processor or your primary sandbox, and when you need a fast pass over the common authentication outcomes before you move into acquirer certification.

3d secure test card v4

Alternative: Adyen test cards

Adyen documents test cards for its test environment, including cards that trigger 3DS2 challenges and cards that complete without one. The set is aimed at merchants running through Adyen's own risk and authentication stack, so it reflects how Adyen routes authentication decisions rather than how a generic simulator does.

• Pros: matches a live Adyen integration, includes cases for challenge and frictionless results, supports testing of issuer declines and authentication errors.
• Cons: useful mainly inside the Adyen test environment, requires an Adyen account, and the table changes when Adyen updates its test platform.

Choose Adyen's cards when Adyen is the processor you will go live with, or when you are certifying against a specific acquirer that runs on Adyen rails.

Alternative: network and EMVCo-level test material

Visa, Mastercard, and EMVCo each publish test documentation and test card ranges tied to the 3-D Secure specification. These are the closest thing to a neutral reference, and they matter when your integration has to satisfy a scheme mandate rather than one processor's sandbox.

• Pros: brand-accurate, covers authentication values and ECI handling, useful for certification evidence and for cross-checking a processor's own table.
• Cons: often gated behind program membership or acquirer access, less convenient for day-to-day development, and not always kept in sync with what a given gateway accepts.

Reach for these when you are preparing for certification, or when two processors disagree about the same authentication result.

How to choose a set

1. List the outcomes you must prove: frictionless success, challenge success, challenge abandonment, authentication failure, and issuer decline.
2. Confirm each candidate set has a card for every outcome, not just the happy path.
3. Check brand coverage against the cards your customers actually use.
4. Check whether the set covers 3RI, decoupled authentication, and out-of-band flows if your product needs them.
5. Confirm the numbers are documented as test-only and will never reach a production endpoint.

Common mistakes

• Mixing test card numbers with live API keys, which produces confusing errors instead of a clean sandbox response.
• Assuming a card that challenges on one processor will challenge on another.
• Testing only the success path, then discovering the abandonment and timeout states are unhandled.
• Hard-coding a card number in application code instead of test fixtures, which makes the list stale.
• Treating a version label as a guarantee that a card range is current.

Recommendation by use case

If you are building on Stripe, start with the Stripe test card set and script it into your test suite. If Adyen is your processor, use Adyen's cards and mirror their outcomes in your mocks. If you are heading into scheme certification or you support several processors, pull the network and EMVCo test material as the reference and treat each processor table as an implementation detail. Whatever you pick, keep the numbers in test fixtures, verify the publication date, and re-run the suite whenever your processor refreshes its list.