3-D Secure 2.x Test Cases

Use the card number specified in the test with the card expiration date set to the month of January and the current year plus three. For example, for 2026, use 2029. You also need the minimum required fields for an order.

Be sure to remove spaces in card numbers when testing.

The test card numbers provided are formatted with Xs for zeroes in the card number. When testing with the card numbers, replace the Xs with a 0 (zero).

While the usage of transaction ID (XID) values have declined in importance, they are still included in 3-D Secure 2.x test cases. Only Mastercard transactions do not return XIDs.

While the 3-D Secure version and directory server transaction ID fields are returned for the Check Enrollment and Validate Authentication services, this data is not included in the 3-D Secure 2.x test cases. Mastercard requires that the 3-D Secure version and directory server transaction ID be included along with all pertinent data in your authorization request.

Card-Specific Setup

The cards in this section require a specific merchant attribute or configuration during testing.

• eftpos: The merchant should request that customer support enable the preferred secondary brand attribute to enable the preferred routing for eftpos.
• mada: The merchant descriptor country should be set as SA and the card type should be set as mada.
• Meeza: The merchant descriptor country should be set as EG and the card type should be set as Meeza.

2.1: Frictionless Authentication Is Successful

This test verifies that successful frictionless authentication of the cardholder by the card issuer works correctly.

2.2: Frictionless Authentication Is Unsuccessful

This test verifies that cardholder authentication without a challenge by the card issuer will fail.

2.3: Stand-In Frictionless Authentication Is Attempted

This test verifies how your system reacts when the cardholder is enrolled in 3-D Secure but the card issuer does not support 3-D Secure, requiring a stand-in authentication experience.

2.4: Frictionless Authentication Is Unavailable

This test verifies how your system behaves when authentication is unavailable at the time of the transaction.

2.5: Frictionless Authentication Is Rejected

This test verifies how your system reacts when authentication rejects the cardholder without a challenge by the issuer.

2.6: Authentication Is Not Available

This test verifies how your system reacts when a system error when checking enrollment prevents authentication.

2.7: Check Enrollment Error

This test verifies how your system reacts when an error occurs while verifying that the cardholder is part of an authentication program.

2.8: Time Out

This test verifies how your system reacts when an error occurs while verifying that the cardholder is part of an authentication program.

2.9: Step-Up Authentication Is Successful

This test verifies how your system reacts to a successful step-up (or challenge) authentication transaction.

2.10: Step-Up Authentication Is Unsuccessful

This test verifies that the step-up (challenge) authentication transaction fails whenever the cardholder challenge fails.

2.11: Step-Up Authentication Is Unavailable

This test verifies that the correct response is returned when step-up authentication is unavailable.

2.12: Error During Authentication

This test checks how your system reacts when authentication request errors occur during processing.

2.13: Authentication Is Bypassed

This test verifies how your system reacts when the challenge requested by the issuer is bypassed for the transaction.

2.14: Require Method URL

This test ensures that the merchant is allowing sufficient time (10 seconds) for the issuer to complete device data collection.

The Method URL process runs before the authentication request to ensure device data is collected properly. The enrollment check of the card account should not start until after the device data collection (DDC) response is received. This test verifies that there is enough time to collect the BIN of the issuer and to transmit it. This test attempts to collect the nine-digit BIN of the card number and verifies that the delay between the DDC request and the response is at least 7 seconds long. The test fails when fewer than nine digits of the BIN are collected or when the delay between the DDC request and response is too short in duration.

Results for the Check Enrollment Service:

• VERes enrolled = Y
• PARes status = Y
• CAVV = <CAVV value>
• ECI value = 05

ECI Values by Network:

Action: If your device data collection method implements correctly and EMV 3-D Secure processing occurs, the test transaction produces a Frictionless Success result. A failure is indicated when PARes status = C. With the failure, a warning message opens to explain the cause of the test failure.