Testing 3D Secure 2 authentication

Test your integration to make sure that you can handle 3D Secure 2 authentication scenarios.

If you configured Dynamic 3D Secure and your default rule is set to Prefer Not do either of the following to trigger 3D Secure 2 scenarios while testing:

• Set your default Dynamic 3D Secure rule to Always.
• Include authenticationData.attemptAuthentication in your API request.
• Use an amount that triggers authentication.

When prompted for 3D Secure 2 text challenges:

• For web and mobile browser integrations, use password: password.
• For native mobile (app-based) integrations, use password: 1234.

If you want to test failed scenarios, use the wrong password (any value other than password provided) to fail the authentication challenge.

To view the details and results of your test payments, do either of the following:

• In your test Customer Area, go to Transactions > Payments.
• Check the AUTHORISATION webhook you received. The success field informs you of the outcome of a payment request.

Test cards

These cards are enrolled in 3D Secure.

Make test payments with the following cards to make sure your integration can handle 3D Secure 2 authentication scenarios.

When you make a payment request with these cards, you'll receive the following result codes depending on your integration:

RedirectShopper: You'll receive this result code if you are using Redirect authentication.
IdentifyShopper: You'll receive this result code if you are using Native authentication.
ChallengeShopper: You will get this result code after you submit the 3D Secure 2 device fingerprinting result in a Native authentication, unless you specify a frictionless flow.

3D Secure 2 challenge action

If your integration uses the Advanced flow, test this scenario. This does not apply to integrations using the Sessions flow.

Test a payment that requires handling the action object included in a payment response that includes the ChallengeShopper result code. Use the following payment details:

If the payment was not successful, check that your client-side and server-side integration handles the required action from the /payments response.

Frictionless flow

If your integration uses the Advanced flow, test this scenario. This does not apply to integrations using the Sessions flow.

Test a payment that goes through frictionless flow, where your integration must provide a device fingerprint. No further authentication interaction with the client-side UI is required. Use the following payment details:

If the payment was not successful, check that your client-side and server-side integration handles the required action from the /payments response.

Mobile app integration

On mobile, shoppers can get different types of 3D Secure 2 authentication challenges. Use the following payment details to make test payments and test specific scenarios.

When prompted for 3D Secure 2 text challenge for native mobile (app-based) integrations, use password: 1234. If you want to test failed scenarios, use the wrong password (any value other than 1234) to fail the authentication challenge.

To test advanced 3D Secure 2 authentication scenarios for native mobile (app-based) integrations, use the following test cards:

Authentication-only flow

If your integration uses the Authentication-only flow, test that your integration can handle the possible outcomes using our test cards.

In this flow, you receive an AUTHENTICATION webhook, instead of the AUTHORISATION webhook to inform you of the payment request outcome.

Authentication without liability shift

Test a payment that goes through 3D Secure 2 authentication without liability shift, use the following payment details.

When prompted for a 3D Secure 2 text challenge, use password: NoLiabilityShift.

Advanced scenarios

Test the following scenarios to make sure your integration can handle advanced 3D Secure 2 flows.

Use the following test cards to test scenarios returning ARes (Authentication Response) with different transStatus values:

• Y: Authentication / account verification successful.
• N: Not Authenticated / account not verified. Transaction denied.
• A: Authentication / verification was attempted but could not be verified.
• U: Authentication / account verification could not be performed.
• R: Authentication / account verification rejected by the Issuer.

Use the following test cards to test other advanced 3D Secure 2 scenarios.