You do not buy 3D Secure test cards. Every major gateway publishes sandbox card numbers that trigger 3DS flows, and those numbers cost nothing. The real decision is which sandbox to standardize on, then pulling the whole test card table from that provider's documentation. Start with the gateway you already run in production, copy its 3DS test PANs together with the fixed expiry and CVC values from the same page, and build your regression suite around the outcome each card produces: frictionless approval, challenge, authentication failure, or issuer unavailable.
What to look for in a 3DS test card set
- Outcome coverage: at least one card per authentication result (Y, N, U, A, and where the simulator supports it, R and C).
- Version coverage: cards or simulator toggles for 3DS2 frictionless and 3DS2 challenge. 3DS1 is retired across the card networks, so treating it as a target is wasted effort.
- Directory server behavior: a way to force timeouts, malformed CRes, and ACS errors, not just clean approvals.
- Brand and region variety: Visa, Mastercard, Amex, and at least one non-US issuer profile, since exemption rules and challenge triggers differ.
- Documented fixed values: expiry, CVC, and postal code the sandbox accepts, so tests stay deterministic.
- No live PANs anywhere in the test suite, including screenshots and sample payloads committed to the repo.
Parameter bands worth knowing
Most US-facing sandboxes allocate test PANs from the 4000 00xx block, with a few 5200 00xx and 3400 00xx entries for other brands. The bands themselves mean little. What matters is the mapping the provider documents between a PAN and an authentication result. Expect the card's test metadata (supported 3DS version, enrolled status, challenge indicator) to be fixed rather than configurable from your side. When a provider exposes an ACS simulator, you choose the result per transaction, which is the arrangement that lets you cover the full matrix without hunting for more numbers.
Pitfalls that break 3DS test suites
- Assuming one gateway's test card works on another. Each 3DS server maps PANs to its own simulator, so a card documented by one provider returns a different result on a competitor's sandbox, or none at all.
- Hardcoding a single approval card and calling the integration tested. The challenge and failure paths are where the bugs live.
- Skipping the return URL and callback handling. Challenge flows break on navigation far more often than on the authentication step itself.
- Ignoring the 3RI and MIT flags. Recurring and merchant-initiated transactions take different exemption paths and need their own cards.
- Mixing sandbox and live keys. The resulting errors look like card problems and send teams chasing the wrong defect.
- Forgetting the authentication unavailable branch. Issuer downtime is common and needs a defined fallback, often a soft decline or a scheduled retry.
FAQ
Do I need to pay for a 3DS test card?
No. Test PANs come with your sandbox account and are published in the provider's docs. Anyone selling 3DS test cards is selling documentation you can read for free, or something worse.
Can I reuse a test card across environments?
Keep test numbers out of production config. Sandbox and live credentials should never share a card table.
What if my gateway has no ACS simulator?
Then coverage stops at whatever fixed results the test PANs produce. Ask the provider for more outcomes, or move to a 3DS server vendor that ships a simulator.
How many cards should a suite need?
One per outcome across the versions and brands you support. A workable baseline is six to twelve cards plus a simulator for the edge cases.