A 3D Secure test card is a card number published by a payment processor for sandbox use only. It pushes a payment through the 3DS authentication step without touching a real account or moving real money. The one to start with is 4000 0000 0000 3220 in the Stripe test environment, because it forces the 3DS2 challenge screen and proves your redirect, authentication and webhook handling work from end to end. The criteria used here: does the card trigger a predictable 3DS behavior, does it work with the provider's standard test keys, and does it let you test the failure path as easily as the success path.

What a 3DS test card actually does

During a 3DS flow the issuer, not the merchant, decides whether the buyer sees a challenge. Test cards simulate that decision. A card tied to "authentication required" returns a challenge request, so your integration has to hand the buyer off to the ACS page and then handle the return. A card tied to "frictionless" approves without a challenge, which is the path most real traffic takes and the one most test suites skip. A card tied to "authentication failed" returns a decline after the challenge, which is how you verify that your order does not ship on a failed 3DS result.

Test cards only work with test API keys and test-mode endpoints. Pasted into a live account they behave like any invalid number and will fail. They also carry no real cardholder data, which is the entire point.

Top pick: 4000 0000 0000 3220 (Stripe sandbox)

This number is documented as requiring 3DS2 authentication, so it produces the challenge flow every time. Use any future expiry date and any three-digit CVC.

  • Pros
  • Forces the challenge screen, so you can see the redirect and the return trip
  • Works with the standard Stripe test keys, no special account flags
  • Lets you test the full sequence: create PaymentIntent, authenticate, confirm, receive the event
  • Cons
  • Covers the challenge path only, so it tells you nothing about frictionless approvals
  • Specific to Stripe, so it will not reproduce Adyen or Braintree behavior
  • Requires you to handle the return URL and the asynchronous webhook, which is where most integrations break

Use it when you are wiring up 3DS for the first time, or when a support ticket says "the challenge page never came back."

Second pick: 4000 0025 0000 3155 (authentication succeeds)

This one also requires 3DS but completes the authentication successfully. Pair it with the card above so you have one run that exercises the challenge UI and one that confirms a clean approval lands in your order system.

  • Pros: confirms the happy path after authentication, useful for regression suites
  • Cons: still does not simulate a frictionless-only approval, and it is Stripe-specific

Decline and failure cases

Test the failure path as carefully as the success path. You want a card that fails authentication, so you can confirm the order stays unpaid, the cart is not cleared, and no confirmation email fires. You also want a generic decline card to separate a 3DS failure from an issuer decline in your logs, because the two arrive through different fields and your support team will ask which one happened.

Provider differences you should expect

Every processor publishes its own set. Adyen documents separate cards for 3DS1 and 3DS2 behavior, including a frictionless case and a challenge case. Checkout.com and Braintree do the same with different numbers. Copying a Stripe test number into an Adyen sandbox will simply return a card error. Pull the list from the docs of the processor you are integrating, and keep the numbers in a fixtures file rather than scattered across tests.

Common mistakes

  1. Running a 3DS test card against live keys and assuming 3DS is broken
  2. Testing only the success path and shipping without handling the challenge return
  3. Ignoring the webhook, then wondering why the order never updates
  4. Assuming a challenge means a decline, when the buyer may still authenticate
  5. Hardcoding test numbers into production config instead of a test fixture

Quick checklist

  • One challenge-required card, one authentication-success card, one authentication-failure card
  • Return URL handled for both approve and decline outcomes
  • Webhook verified before the order is marked paid
  • Logs record the 3DS result separately from the authorization result
  • Test numbers stored in fixtures, never in the production bundle

Test card numbers change when processors update their sandboxes. Confirm the current list in your provider's documentation before you build a fixture around it.