Short answer
3DS challenge card testing v2 means running the EMV 3-D Secure challenge flow in a provider sandbox using the test card numbers that your acquirer or gateway publishes. You select a test card that is documented to force a challenge, submit a payment, complete the authentication page with the sandbox code, then check that the authorization result in your logs matches the outcome the test case expects. Live card data has no place in this step.
Prerequisites
- A sandbox merchant account with 3DS 2.x enabled and the challenge flow switched on in the profile.
- The provider's published test card table, which lists cards that force frictionless, challenged, and failed authentication outcomes.
- An integration that sends browser and device data with the payment request.
- Logging on the threeDS fields, the ECI value, and the final authorization status.
Procedure
- Open your provider's test card reference and copy a card flagged to force a challenge into your sandbox configuration only.
- Create an order in your test store with the amount and currency your scenario requires.
- Send the 3DS block with browser info, device channel, and the requestor ID that your sandbox profile expects.
- Submit the payment and read the response for a challenge indicator or redirect field.
- Load the challenge page from the response and enter the sandbox one-time code that the test card documentation gives.
- Capture the authorization response, the ECI value, and the 3DS transaction ID from the callback.
- Compare those values against the expected result for that test card.
- Rerun the same card while abandoning the challenge page, then once more with a forced timeout, to cover the failure paths.
- Record each run in a test matrix that maps card number, scenario, and returned status.
Reading the result
A successful challenge returns an authenticated status with a transaction ID you can reconcile later. A failed or abandoned challenge returns a distinct status code, and the authorization should decline rather than fall through to a plain charge. If a challenged test card returns frictionless, your request block is missing fields or the profile has the challenge flow disabled.
Common sandbox failures
Most failed runs come from three causes: browser data that does not match the device channel, a test card used outside the sandbox environment, or a timeout window shorter than the challenge step needs. Each of these shows up as an authentication error, not a payment error, so check the 3DS response fields before you touch the payment code.
Keeping the test valid
Use only numbers from the provider's published test list. Test cards are synthetic and tied to sandbox behavior, so results from any other number tell you nothing about your integration. Store the card list next to your test suite and update it when the provider revises its reference.