3-D Secure Authentication – Browser Channel

3D Secure 2.2 is an EMVCo payment authentication protocol designed to reduce card not present fraud by making a risk assessment based on transaction and device data while also supporting further risk minimization measures such as a challenge to the cardholder.

In some cases, use of 3D Secure provides your transactions with liability shift for certain card-not-present fraud-related chargebacks; this enables your merchant account to provide goods and services with confidence.

1. Activating 3-D Secure Functionality

Moneris Sales Support

Phone: 1-855-465-4980

To activate Visa Secure, MasterCard Identity Check and/or American Express SafeKey transaction functionality, call Moneris Sales Support to have Moneris enroll you in the program(s) and enable the functionality on your account.

2. Browser Channel: Frictionless and Challenge Flow

The standard browser-based authentication flow can proceed in one of two ways referred to as “frictionless” and “challenge” (aka “friction”) . 

The “frictionless” flow is transparent to a cardholder. If the issuing financial institution has enough information to make a risk assessment and assume liability, this will manifest itself as with an authentication attempt or success with an accompanying CAVV value. No cardholder challenge is presented and steps 5 through 10 of the flow diagram below are omitted.

In the “challenge” flow the issuing financial institution may wish to take a further step and issue a challenge to the cardholder.  In this case the cardholder’s browser gets re-directed to the issuer’s 3DS platform for authentication. Once this challenge is complete, the cardholder browser is again re-directed back to the merchant’s site. The merchant’s server then issues a server-to-server request to Moneris to obtain the CAVV value for that cardholder’s successful challenge.

3. Card Lookup (Optional)

The Card Lookup request initiates cardholder browser fingerprinting with Moneris. Your merchant website collects the card data and sends a call to the Moneris API endpoint POST /three-d-secure/card-lookups. Our server will respond with the “threeDSecureMethodData” and “threeDSecureMethodURL” fields needed for connecting to the issuing bank’s ACS in the next step.

4. 3DS Authentication

Moneris communicates with the 3DS Directory and the ACS system for that issuer to provide an initial risk assessment. Moneris returns a response to the merchant with a “threeDSecureTansactionStatus” indicating the action for your website to perform:

  • It is required to include “threeDSecureDeviceChannel” = “BROWSER” and “threeDSecureRequestType” = “CARDHOLDER”. This indicates you are authenticating a cardholder-initiated transaction via a web browser.

    • For merchant-initiated authentication, see 3RI

  • If you processed a card lookup prior, you must include the field “threeDSecureCompletionIndicator” = “SUCCESS”. Otherwise, use “UNAVAILABLE” when not attempted or “FAILURE” if attempted without success.

  • The following fields are required for browser channel authentications: "threeDSecureRequestType", "threeDSecureNotificationUrl", "threeDSecureChallengeRequested", "threeDSecureChallengeWindowSize", "browserUserAgent", "browserJavaEnabled", "browserScreenHeight", "browserScreenWidth", "browserLanguage"

  • “threeDSecureTansactionStatus” = “AUTHENTICATED” means the website can proceed immediately to the financial transaction with the “CAVV” value provided. This is a frictionless transaction flow without presenting a challenge. Our gateway returns an HTTP response of 200.

  • “threeDSecureTansactionStatus” = “AUTHENTICATED_ATTEMPTED” means the website can proceed immediately to the financial transaction with the “CAVV” value provided. This is proof of attempted authentication, even if it was not successful. Our gateway returns an HTTP response of 200.

    “threeDSecureTansactionStatus” = “CHALLENGE_AUTHENTICATION_REQUIRED” indicates that the cardholder must be presented a challenge. To present the challenge, you must POST a <form> with a “creq” field, which contains the ChallengeData, to the URL defined in the ChallengeURL field. Our gateway returns an HTTP response of 202. See Present Challenge for further instructions.

  • For other 3DS transaction status results, see API Reference

Moneris communicates with the 3DS Directory and the ACS system for that issuer to provide an initial risk assessment. Moneris returns a response to the merchant with a “threeDSecureTansactionStatus” indicating the action for your website to perform:

5. Present Challenge To Cardholder

In scenarios where a challenge is required for authentication (“threeDSecureTansactionStatus” = “CHALLENGE_AUTHENTICATION_REQUIRED”), your merchant website must send an HTTP POST to the Challenge URL for the issuing bank’s ACS with the ChallengeData sent as a “creq” value. The ACS system will present a challenge to the cardholder, who will supply whatever credentials their issuer requires.

The form can be dynamically generated and added to the DOM and submitted or created and submitted in a manner that suits your environment.  This can be built as a full page redirect, presented as an inline iframe, or as a lightbox. 

  • If you wish for this to be loaded inside a defined space it must conform to the size specified in the “threeDSecureChallengeWindowSize” from the request.

  • The “action” is retrieved from the ChallengeURL and the “creq” field is retrieved from the ChallengeData.



<form method="POST" action="https://3dsurl.example.com/do3DS">
<input name="creq" value="thisissamplechallengedata1234567890"> </form>  

To the right is a sample of a basic static form to help visualize the data and fields that need to be submitted. 

Use this sample code to present the challenge to the cardholder in their browser.

After the challenge is completed, the issuer ACS responds with a “cres” field via HTTP POST back to your threeDSecureNotificationUrl provided in the POST Create Authentication request. You will need this value to retrieve the ECI and CAVV values for the authentication via POST Authentication Value Lookup.

6. Authentication Value Lookup

3DS Authentication Value

*The Moneris threeDSecureAuthenticationValue is known as the Cardholder Authentication Verification Value (CAVV), Accountholder Authentication Value (AAV) or American Express Verification Value (AEVV) by each card brand. Moneris simplifies these values into a single field within our API.

With the cardholder challenge completed, you need to retrieve the “threeDSecureAuthenticationValue”* and “ecommerceIndicator” (ECI) from our systems. You will need to send a request to the POST /three-d-secure/cavv-lookups endpoint as the final part of the 3DS authentication process.

In the request, include the following:

  • “challengeResponse” field containing the “cres” response from the Challenge response notification

In response, Moneris will return the challenge results and, for successful challenges, retrieve the “threeDSecureAuthenticationValue” and “ecommerceIndicator” for use in the subsequent financial payment.

7. Proceed With Payment

With the results from your 3DS authentication, you can now safely proceed with payment. Follow the instructions in either Payment Flow (one-step, two-step links to other Payment scenarios) but include the following:

  • For the “ecommerceIndicator”, include the value from your 3DS Authentication

  • Include the optional “threeDSSecureData” object with:

    • “threeDSecureAuthenticationValue” from the 3DS Authentication

    • “threeDSecureServerTransactionID” matching your 3DS Authentication

Additional Information

Learn more with the API Definitions

Peruse the endpoints, request/response formats, and authentication methods covered in this scenario.

API References