Answer

A 3D Secure test card v2 is a sandbox card number that forces an EMV 3DS (3DS2) authentication result you can reproduce on demand. You use it in a processor test environment to trigger a frictionless approval, a challenge prompt, an authentication failure, or a not-enrolled response. The number carries no real account and declines in live mode. Stripe, Adyen, Checkout.com, and Braintree each publish their own table of test numbers and the outcome tied to each one. Stripe, for example, documents 4000 0000 0000 3220 as a card that requires 3DS2 authentication before the payment can succeed. Copy the current numbers from your provider's own test card page, because processors retire and reassign test ranges.

Buy the Best 3D Secure Test Card V10

Prerequisites

• Sandbox or test-mode API keys for your payment processor
• Dashboard access to authentication and payment logs
• Your processor's 3DS2 test card table open in a second tab
• A test customer and a payment flow you can recreate from scratch

How to test a 3DS2 flow with a test card

1. Switch the integration to test mode and confirm the API key in use carries the test prefix.
2. Copy the test card number that maps to the outcome you need, not the first number in the table.
3. Submit the card with any future expiry date, any three-digit CVC, and any cardholder name.
4. Wait for the 3DS2 challenge to render. If the frame stays blank, check that your return URL and challenge window size are configured.
5. Enter the provider's test verification code on the challenge screen. Common values are 1234 and 123456, and the exact code is listed next to the card in the provider's table.
6. Read the authentication result on the payment object: the status field, the 3DS version field, the ECI value, and the directory server transaction ID.
7. Log whether the flow was frictionless or challenge-based, then confirm the liability shift flag matches the result you expected.
8. Clear the test data and repeat the run for every outcome in the next section.

Outcomes to cover before you ship

• Frictionless approval, where no challenge is shown and authentication completes in the background
• Challenge completed, where the customer passes the verification step
• Challenge abandoned, where the customer closes the window before finishing
• Authentication failed, where the issuer rejects the attempt
• Not enrolled or not supported, where the flow falls back and liability shift does not apply
• Exemption requested, including low-value and transaction risk analysis paths

Common mistakes

• Using a live card number. PCI DSS Requirement 6.4.3 prohibits production account numbers in test environments.
• Assuming one test card covers every outcome. Most providers ship a separate number per result.
• Hardcoding the test verification code into production logic.
• Treating a 3DS1 result as a 3DS2 result. The version field on the authentication object tells you which protocol ran.
• Testing only the approved path and shipping without a failure branch.