Use the test card set published in the sandbox documentation of the processor you already integrate. For most teams that is the Stripe 3DS test card list, because every number maps to a documented authentication result and no live authorization can occur. The criteria I applied: each card must name its EMV 3DS behavior, the list must cover frictionless and challenge flows, it must cover one-time password success and failure, it must include a legacy 3DS1 fallback card, and it must contain no real account data.

read more

What "v3" usually refers to

The phrase is ambiguous and that ambiguity causes most of the wasted time. It means one of two things. Either it refers to the third revision of a gateway's published test card table, which is an internal version number that only that gateway can define, or it is a mislabeling of EMV 3-D Secure, where the current specification line is 2.x and there is no shipped "3DS version 3." EMVCo maintains the standard and its versions sit in the 2.1 through 2.3 range. If a vendor sells you a "3DS v3 card list," ask which specification version and which gateway sandbox it targets. If the answer is vague, the list is a copy of someone else's public table.

read more

Criteria that separate a useful test set from a toy

• Named outcomes. Each card states what the issuer simulator returns: authenticated, attempted, rejected, or unavailable.
• Flow coverage. At least one frictionless card and one that forces the challenge screen.
• OTP behavior. A path for correct codes, wrong codes, and timeouts.
• Fallback. A card that drops to 3DS1 or to a non-authenticated liability shift.
• Region coverage. Cards tied to different issuer countries, because routing rules differ.

Stripe

Stripe publishes sandbox numbers that force specific 3DS2 results. The number 4000000000003220 is the common starting point for an authentication-required outcome, and the sandbox renders a simulated authentication page where you choose to complete or fail the step.

3d secure test card v9

• Pros: behavior documented per card, works in test mode with no real funds, covers 3DS2 and 3DS1 fallback, easy to pair with webhook testing for payment_intent.requires_action.
• Cons: outcomes are Stripe-specific, so a card that triggers a challenge there may behave differently in another gateway.

Use it if you build on Stripe or you want the shortest path to a repeatable 3DS2 regression test.

3d secure test card v2

Adyen

Adyen documents test cards split across frictionless and challenge outcomes, plus cards that return a failed authentication so you can exercise your decline handling.

• Pros: clear separation of frictionless versus challenge, strong support for testing issuer country routing, paired with a test API that reports the raw 3DS result.
• Cons: the sandbox expects the Adyen checkout flow, so you cannot reuse the numbers in a rival gateway and see the same result.

Use it if you sell across multiple regions and need to prove that your routing and retry logic handles different issuer responses.

Braintree

Braintree offers test cards that force a 3DS challenge and returns values you can assert against in your own test suite, including an authentication identifier you can store and re-check.

• Pros: good for teams that assert on response fields rather than eyeballing a browser screen, stable values across sandbox resets.
• Cons: the list is shorter than the other two and has less coverage of partial authentication outcomes.

Use it if your CI pipeline needs deterministic card values that do not change between runs.

How to run a full 3DS2 test pass

1. Pick one gateway sandbox and freeze its card list in your test fixtures.
2. Run a frictionless card and confirm the charge completes with no user step.
3. Run a challenge card, enter the correct code, and confirm the order moves to captured.
4. Run the same card with a wrong or expired code and confirm the order fails rather than hangs.
5. Run a rejected card and confirm your UI shows a recoverable message, not a generic error.
6. Abandon the challenge screen and confirm your webhook or polling job reconciles the pending state.
7. Repeat all six steps against a second currency and a second issuer country.

Why live card data is the wrong input

Card numbers, CVVs, and expiry data that belong to real accounts fall under the PCI DSS rules for storage and use. Testing against live data pulls your whole environment into scope and can create fraud exposure for the account holder. Test cards exist so that no real credential is needed to reproduce any authentication result. A vendor who offers to sell you live card data is selling stolen payment credentials, and using them is a criminal act in the United States and most other jurisdictions. Buy the integration, not the data.

Bottom line

Grab the published test list for your own processor, verify that it names the outcome for each card, and script the seven-step pass above. That covers frictionless, challenge, OTP failure, fallback, and abandonment, which is everything a 3DS2 integration breaks on.