3-D Secure testing explained

Ask a QA team whether their checkout “supports 3-D Secure” and the answer is usually yes — because one test card once opened a challenge window and the payment went through. That covers one path out of many. Real issuers approve silently, challenge, reject, time out or are simply unavailable, and each result needs different handling in your code. Testing all of them takes an hour once you know which cards to use.

What 3-D Secure is

EMV 3-D Secure (3DS) is a protocol whose specifications are published by EMVCo, the payments industry standards body. EMVCo describes it as a way to help card issuers and merchants prevent card-not-present fraud: the merchant shares information about the transaction, the payment method and the device with the issuer, and the issuer uses it to decide whether the buyer must authenticate further. The specifications cover both browser-based and app-based purchases.

Three parties matter for testing:

• The merchant side — your checkout plus your gateway’s 3DS server, which starts the authentication and collects device data.
• The issuer side — the issuer’s access control server (ACS), which decides on frictionless or challenge and runs the challenge screen.
• The networks — which route the messages between the two and define the rules, including liability shift.

In a sandbox, your gateway simulates the issuer side. That is why only specific test cards produce specific results: the card number tells the simulator which issuer behavior to play back.

3DS1 and 3DS2

Version 2 of the protocol was designed around data sharing, so that issuers can approve most transactions without interrupting the buyer, and it supports in-app purchases as well as browsers. Stripe notes that major card brands no longer support 3D Secure 1, and EMVCo recommends version 2.2 or higher. If an integration still has 3DS1 code paths, treat them as dead code to remove, not as a scenario to test.

Frictionless vs challenge flows

For many transactions the buyer simply clicks “Pay” and the issuer approves the authentication in the background — the frictionless flow. For higher-risk transactions the issuer asks for more, such as a one-time passcode, a security question or biometric approval in a banking app — the challenge flow. The merchant can express a preference, but the issuer makes the final call. Stripe, for example, lets you request any (prefer frictionless) or challenge, and states it can’t guarantee your preference because the issuer determines the flow.

Challenge screens come in several interface types. Stripe documents test cards for four of them in mobile SDKs: out-of-band (approve in another app), one-time passcode, single select and multi select. If you ship a native app, test each type at least once, because each renders differently and has its own cancel path.

The result codes behind the flows

Under the hood, the issuer answers with a transaction status. Adyen’s test documentation maps its test cards to these values, which most gateways expose in some form:

SCA, PSD2 and why 3-D Secure became mandatory

In the European Economic Area, Strong Customer Authentication (SCA) under the PSD2 regulation took effect on September 14, 2019, and the UK has an equivalent requirement. For card payments, 3-D Secure is how merchants meet it: Stripe states that card payments require 3D Secure to meet SCA requirements, and that banks may decline transactions that don’t follow the authentication rules. Some low-risk transactions are exempt, but the issuer can still request authentication, so an integration must always be ready to show a challenge.

SCA also explains a decline you should test explicitly: the soft decline. If you send a payment without authentication and the issuer insists on it, the authorization fails with a code such as Braintree’s 2099 “Cardholder Authentication Required”. A well-built checkout reacts by running 3D Secure and retrying, not by showing a generic error. Saved cards add one more case — off-session (merchant-initiated) payments, which Stripe tests with 4000 0025 0000 3155: authentication is required unless the card was set up for future use.

Liability shift: what authentication does and doesn’t buy you

When a payment is successfully authenticated with 3-D Secure and the cardholder later disputes it as fraud, liability for that chargeback typically moves from the merchant to the issuer. That is the commercial reason merchants accept the extra friction. Stripe’s documentation is careful to add that liability shift can be expected but is never guaranteed for a specific payment or dispute: network rules, merchant category and fraud-monitoring programs can all change the outcome. An authenticated result confirms only that authentication succeeded.

For testing, this means two things. Record the authentication result and electronic commerce indicator (ECI) your gateway returns with each payment, because you will need them as dispute evidence. And don’t write business logic that assumes “authenticated = can’t be charged back”.

The outcomes your integration must handle

Before picking cards, list the behaviors you want to observe. A complete 3DS test plan covers at least these:

3-D Secure test cards by gateway

Every number below comes from the gateway’s own documentation; our test card numbers hub has the complete lists with copy buttons. Generated numbers from a card generator won’t trigger any of these flows — sandboxes only simulate issuer behavior for their documented cards.

Stripe

Use any future expiry and any CVC. In test mode Stripe shows a mock authentication page with buttons to complete or fail the challenge. More in our Stripe test cards list.

Braintree

Expiry month 01, year current year + 3 — for every Braintree 3DS card. See the Braintree test cards page for Mastercard equivalents.

PayPal (Expanded Checkout)

These are US-issued cards for purchase flows; PayPal lists separate cards for other countries and for saving payment methods. Details on our PayPal test cards page.

Adyen

Use expiry 03/2030 and CVC 737. The challenge password is password in browsers and 1234 in native apps; any other value fails the challenge. If your Dynamic 3D Secure rule is set to “Prefer Not”, set it to Always or request authentication explicitly, or the test may skip 3DS. See our Adyen test cards.

Checkout.com

Use any future expiry and any valid CVV. When a test redirects to the 3DS simulator page, enter the password Checkout1!. More on our Checkout.com test cards page.

Square

Use CVV 111 (1111 for American Express). Square notes that in its sandbox, verifyBuyer creates a buyer challenge across all regions, mandated or otherwise — so a challenge appearing for a US test is expected.

Gateway quirks that cause false failures

Most “3DS doesn’t work in test” reports come down to a handful of setup issues rather than integration bugs:

• Testing from the dashboard. Stripe doesn’t perform 3D Secure redirects for payments created in the Dashboard. Always test through your own front end or API calls.
• Using a generic test card. Stripe says other test cards may still trigger 3DS but return attempt_acknowledged to skip the steps. Only the dedicated 3DS cards exercise the real flow.
• Wrong expiry date. Braintree requires 01 / current year + 3; Adyen’s cards expect 03/2030.
• Ad blockers and privacy extensions. Braintree recommends disabling them, because they can block device data collection.
• A sandboxed iframe. Stripe warns that you can’t use the sandbox attribute on the 3DS iframe: in live mode the issuer controls content inside it, and some issuer implementations fail when sandboxed.
• Content Security Policy. If your site sends a CSP header, it must allow the gateway’s 3DS frames and your return URL, or the challenge renders blank.
• Short timeouts in mobile SDKs. Stripe’s mobile SDKs require an authentication timeout of at least five minutes, which includes the time the buyer spends reading the passcode message.

Turning the cards into automated tests

Challenge screens are hard to automate end to end, so split the work. Cover frictionless outcomes, errors and declines in API-level tests with your gateway’s test cards or test payment method IDs — Stripe’s pm_card_threeDSecure2Required and pm_card_threeDSecureRequiredChargeDeclined are built for this. Then keep a short manual or browser-automation checklist for challenge success, challenge failure and a closed challenge window on each platform you ship (desktop browser, mobile browser, native app).

Whatever the outcome, assert on your own system’s state, not just the gateway response: the order status, whether a fulfillment job was queued, what the buyer was shown and what was logged. A 3DS failure that leaves a paid-looking order in your database is worse than a failed payment. For gateway-by-gateway walkthroughs, see our guides to testing a Stripe checkout and PayPal and Braintree sandboxes.