A 3D Secure test card v8 is a sandbox-only card number, drawn from a payment processor's version 8 test data set, that forces a 3DS authentication step during checkout testing. It has no real account behind it, moves no money, and is rejected the moment it is sent to a live production endpoint. The "v8" label is the processor's own dataset version, not an industry standard, so the exact number depends on which gateway you integrate.

read more

What does a 3D Secure test card actually do?

Test cards are mapped to scripted outcomes inside a sandbox. Some approve silently, some trigger a frictionless 3DS2 flow, and some force a full challenge where you enter a one-time code. That lets developers exercise every branch of the authentication logic without touching a real cardholder.

related article

A 3DS test card typically drives three things at once: the issuer response, the authentication result (successful, attempted, or failed), and the liability shift flag returned to your system.

3D Secure Test Card V7: The Ultimate Guide to Purchase

How do 3DS test cards behave in a sandbox?

Most processors publish a table that pairs each test number with a specific authentication outcome. You pick the number that matches the scenario you need to reproduce, then confirm your code handles the result correctly. The table changes between dataset versions, which is why a v8 card may not exist in a v7 list.

3d secure test card v2

• Frictionless success: authentication passes with no customer interaction.
• Challenge required: the sandbox shows a code entry screen, usually with a fixed passcode such as 1234 or a password like password.
• Authentication failed: the issuer declines the authentication step, and the payment should not proceed.
• Not enrolled: the card skips 3DS entirely and falls back to a standard authorization.
• Attempted: authentication could not complete, but the transaction can still be submitted with liability held by the merchant.

Which test card numbers are commonly used for 3DS testing?

Public documentation from major processors lists sandbox numbers such as 4000 0000 0000 3220 and 4000 0025 0000 3155 for 3DS2 challenge flows, and 4000 0000 0000 3063 for authentication failures. Always copy numbers from your own provider's current test page instead of a third-party list, because a stale number can silently fall back to a plain approval.

Why should you never test with real card numbers?

Real card data in a test environment breaches PCI DSS requirements and, in most jurisdictions, data protection law as well. Test mode exists precisely so that no live primary account number ever leaves the production vault. Storing real card numbers on a developer laptop or in a shared spreadsheet turns a routine integration into a reportable incident.

Use synthetic identities for the cardholder name and address fields too. Sandbox data is safe to share in tickets and screenshots, and that is the main practical reason to keep test and live environments strictly separated.

How do you pick the right test card for your integration?

Start from the outcome you need to verify, then work backwards to the number. If you are validating an exemption flow, you need a card that returns a frictionless result; if you are testing error handling, you need a failure card.

1. Open your processor's test card page and confirm the dataset version.
2. Match the card to the authentication outcome you want to reproduce.
3. Run the transaction in sandbox mode with test API keys only.
4. Log the full 3DS result object, including the authentication status and liability shift field.
5. Re-run the same scenario after any SDK or API version upgrade.

Does a v8 test card work across processors?

No. Test card numbers are scoped to a single processor and often to a single API version, so a number that works in one sandbox will fail in another. Treat every dataset version as a separate reference and re-verify after each release.