3D Secure test cards — why Luhn validity isn't enough.
3D Secure doesn't trigger off checksum validity — it triggers off specific numbers each processor reserves for that exact purpose. Here's what 3DS actually is, and the verified official test cards by processor.
What 3D Secure Actually Is
3D Secure — shown to shoppers as Visa Secure, Mastercard Identity Check, or similar branding — adds an authentication step to a card payment: a one-time code, a banking app approval, or a biometric check. It exists mainly to satisfy Strong Customer Authentication (SCA) rules under the EU's PSD2 regulation, and more broadly to shift fraud liability away from merchants who use it correctly.
Testing it is fundamentally different from testing basic card acceptance. A successful/decline test card just needs the right checksum and a number your processor recognizes. A 3DS test needs the processor to recognize the number and route it into a specific authentication scenario — frictionless success, a challenge screen, a failure, or an error.
Why a Bulk Generator Can't Do This
This is worth being direct about, since it's a natural thing to assume: no Luhn-valid number generator — including Luhnly — can produce a working 3DS test card. The reason isn't a technical limitation that could be fixed later; it's structural. 3DS-triggering numbers are arbitrary reserved values each processor's sandbox specifically recognizes, not something derivable from the Luhn formula.
Stripe
Stripe documents dedicated 3D Secure test numbers, separately from its regular success/decline cards. Per Stripe's own testing documentation, other test cards may still show what looks like a 3DS prompt, but Stripe returns an automatic attempt_acknowledged response to skip the real challenge — since exercising 3DS isn't the point of those cards. Only the numbers below fully route through the challenge flow.
| Number | Scenario |
|---|---|
| 4000 0025 0000 3155 | Requires authentication (standard challenge) |
| 4000 0027 6000 3184 | 3D Secure 2 authentication flow |
Use any future expiry, any 3-digit CVC, and any ZIP. Full details, including additional scenario variants, live in Stripe's official testing documentation. See our Stripe test cards guide for the rest of Stripe's success/decline numbers.
PayPal
PayPal publishes an extensive, country-specific set of 3D Secure test cards — separate tables for purchase flows versus saving a payment method, each with numbered test cases covering frictionless success, failed authentication, step-up challenges, and lookup errors. The full set (verified against PayPal's documentation, last updated August 27, 2026) runs to dozens of numbers across ten countries — too long to reproduce in full here, but a representative sample:
| Number | Scenario (US, purchase flow) |
|---|---|
| 4868 7191 9682 9038 | Successful frictionless authentication |
| 4868 7191 5813 0060 | Failed frictionless authentication |
| 4868 7191 6610 1368 | Successful step-up (challenge) authentication |
| 4868 7191 8189 5556 | Failed step-up authentication |
For the complete country-by-country tables and the separate save-payment-method scenarios, see PayPal's official 3D Secure test scenarios. See our PayPal test cards guide for PayPal's broader (and unusually permissive) sandbox model.
Braintree
Braintree's 3D Secure test numbers come from CardinalCommerce, Braintree's third-party 3DS authentication provider, distributed as a separate reference document rather than listed directly in Braintree's main docs. We won't reproduce specific numbers here without being able to verify them against that source directly — rather than risk publishing stale or incorrect values on a page whose whole purpose is accuracy, we're pointing you to the source instead.
One detail worth knowing regardless of the specific numbers: Braintree's 3DS test cards use an unusual expiry convention — the expiration month is always 01, and the year is the current year plus three. See Braintree's official 3D Secure testing guide for the current CardinalCommerce reference. Our Braintree test cards guide covers Braintree's regular success/decline numbers.
Square and Authorize.net
Square's SCA/3DS test values are documented, but differ depending on which SDK you're integrating against (Web Payments SDK versus In-App Payments SDK use different numbers for the same scenarios) — check Square's sandbox documentation for the set matching your integration.
Authorize.net does not publish a dedicated 3D Secure test-card system in the same structured way as the processors above as of this writing. If you're integrating 3DS with Authorize.net, confirm current guidance directly in Authorize.net's developer documentation before relying on any third-party summary, including this one.
Related Guides
Frequently Asked Questions
Can a Luhn-valid generator like Luhnly test 3D Secure?
No. 3D Secure triggers off specific numbers each processor has reserved for that purpose, not general Luhn validity. Some documented 3DS test cards aren't even Luhn-valid themselves, which underscores that 3DS testing is a completely separate mechanism from checksum validation.
What is 3D Secure and why does it exist?
3D Secure (branded as Visa Secure, Mastercard Identity Check, etc.) is an extra authentication step — a one-time code, banking app approval, or biometric check — layered onto card payments. It exists mainly to satisfy Strong Customer Authentication (SCA) rules under Europe's PSD2 regulation, and more broadly to reduce card-not-present fraud.
Do all Stripe test cards trigger a real 3D Secure test?
No. Stripe's own documentation notes that other test cards may still trigger a 3DS-looking prompt, but Stripe returns an automatic acknowledgement to skip the actual challenge, since 3DS testing isn't their purpose. Only the numbers in Stripe's dedicated 3D Secure section fully exercise the challenge flow.