A 3D Secure test card is a fake card number that a payment provider's sandbox accepts to run the 3DS authentication step. It behaves like a live card inside the test environment, triggers the challenge or frictionless flow you select, and never touches a real bank account. Developers use these numbers to confirm that a checkout handles 3DS approval, failure, and timeout cases before launch.

3d secure test card v2

How 3D Secure test cards work

A 3DS test card carries the same 16 digits as any other number, but it routes to a mock issuer instead of a bank. The mock issuer returns a scripted answer: approve, challenge, decline, or error.

3D Secure Test Card V9

Each provider maps outcomes to separate numbers. One card may pass with no cardholder input, another may force an OTP screen, and a third may return an authentication failure. You pick the number that matches the branch you want to test.

3d secure test card v4

The mock issuer also returns the authentication result codes that your code reads in production, such as authenticated, attempted, and not authenticated. Those codes decide whether an order ships or waits for review.

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

What can you test with a 3DS test card?

• Frictionless approval, where the issuer authenticates the cardholder with no visible challenge.
• Challenge flow, where the cardholder enters a one-time code or approves in an app.
• Failed authentication, where the code is wrong or the cardholder cancels.
• Attempted authentication, where the issuer cannot finish the check.
• Timeout and abandoned challenge, where no result comes back.
• Declines raised after authentication, such as insufficient funds.

Cover the failure branches as well as the happy path. A checkout that breaks on an abandoned challenge loses the order and the customer.

How to run a 3DS test

1. Switch your integration to sandbox keys. Live keys reject test numbers.
2. Open the provider's test card page and copy the number for the outcome you need.
3. Use any future expiry date and any three digit CVC. Sandboxes ignore both fields.
4. Send the payment through the same endpoint your production code calls.
5. Complete the challenge page with the test code listed in the docs.
6. Read the authentication fields in the response, such as the 3DS result, the ECI value, and the transaction status.
7. Repeat the run for every failure path you plan to support.

Log the raw 3DS payload during these runs. The payload shows whether the challenge was authenticated, attempted, or rejected, and it is the fastest way to debug a mismatch between your order status and the gateway result.

3DS1 and 3DS2 test flows

3DS1 sends the cardholder to a browser redirect hosted by the issuer. The test card list for 3DS1 is short, and most processors have retired the flow.

3DS2 adds an in-app or in-page challenge, device fingerprinting, and a frictionless path. Test cards for 3DS2 cover the frictionless branch, the challenge branch, and the attempted result that 3DS1 could not return.

If your provider supports both, test 3DS2 first. New integrations are built on it.

Common 3DS test card numbers

Most processors publish a short list. Stripe documents 4000 0025 0000 3155 for a 3DS challenge and 4000 0000 0000 3220 for a 3DS2 challenge. Adyen, Checkout.com, Braintree, and Worldpay list their own numbers in their developer docs.

Numbers are not portable. A Stripe test card fails on Adyen because each sandbox keeps its own mock issuer list. Pull the number from the docs of the provider you use.

Some numbers work with certain card brands or regions. If a card declines in a way you did not script, check the docs for the brand and country pair.

Where to find 3DS test cards

Provider documentation is the source. Look for pages titled "test cards", "test payment methods", or "3D Secure testing" in the developer section.

• Stripe: test cards page, with sections for 3DS and 3DS2.
• Adyen: test card numbers with 3DS2 profiles.
• Checkout.com: test cards for frictionless and challenged flows.
• Braintree: test cards for 3DS verification.

Each page lists the number, the brand, and the flow the number triggers. Save the list in your repo so new team members run the same tests.

What a 3DS test card cannot do

Test cards stay inside sandbox. They return an error on a live endpoint, and no bank will authorize them.

They also cannot prove that production works end to end. Real 3DS depends on the issuer's ACS, the card brand's directory server, and your merchant configuration. A sandbox run skips all three.

Use a low value live transaction with your own card when you need to confirm production routing.

Are 3DS test cards the same as a real card number?

No. Test numbers come from public documentation, hold no funds, and work only inside a sandbox. A real card number belongs to a live account, and using one that is not yours is card fraud.

That gap matters for compliance reviews. Test cards carry no cardholder data, so they sit outside PCI scope for storage. Live numbers do not.

FAQ

Do 3DS test cards work in live mode?

No. Live gateways reject published test numbers, and the mock issuer behind them does not exist outside the sandbox.

Which test card triggers a 3DS challenge?

It depends on the provider. Stripe documents 4000 0025 0000 3155, and other processors list their own numbers for the same job. Check your provider's test card page.

Are 3DS test cards free?

Yes. Sandbox access and test cards come with a free developer account at most processors.

Can I test 3DS without a test card?

You can simulate the authentication result in a mock, but a mock will not catch redirect or browser issues. A sandbox test card exercises the real challenge page.

How many test cases should a 3DS integration cover?

At a minimum, cover frictionless approval, a completed challenge, a failed challenge, an abandoned challenge, and a post authentication decline. Five runs catch most bugs before a customer finds them.