3-D Secure Authentication – Requestor Initiated

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. Requestor Initiated Flow (3RI)

In a 3DS Requestor Initiated flow, the merchant triggers the transaction instead of the cardholder. In some circumstances the cardholder is involved non-electronically, such as mailing or phoning the merchant (known as Mail-Telephone Order, aka MOTO), or it is possible the merchant is processing a recurring or installment plan on behalf of the cardholder’s subscription. It is also possible the merchant requires a non-payment authentication as part of tokenizing the card for later use.

In a 3DS Requestor Initiated flow, the cardholder is not directly triggering the transaction flow via a browser experience as above. It is possible they are initiating the transaction outside the 3DS protocol, such as mailing or phoning the merchant (Mail-Telephone Order, aka MOTO), or it is possible the merchant is processing a recurring or installment plan on behalf of the cardholder’s subscription. It is also possible the merchant requires a non-payment authentication as part of tokenizing the card for later use.

  • If this is a Mail or Telephone (MOTO) payment authentication, the ACS may trigger a Decoupled Authentication between the issuer and cardholder (see Decoupled Authentication)

  • If this is a follow-on payment from a previous 3DS authenticated transaction, you can include prior_authentication_info to link to the previous authentication and improve the likelihood of a successful result

3RI flows do not have direct cardholder interaction. The merchant sends their <threeDSAuthentication> request per steps 3-4 above but include additional fields to describe their 3RI usage scenario.

Your server can utilize the fields device_channel, ri_indicator and message_category to inform Moneris if your merchant server is attempting to use the 3DS Requestor Initiated process.

3. Decoupled Authentication

  • ”threeDSecureDecoupledRequestIndicator” set to “true”.

  • ”threeDSecureDecoupledRequestAsyncUrl” is required and informs Moneris systems on where to POST the decoupled authentication results asynchronously.

For scenarios where a 3RI authentication requires challenge, instead of utilizing the standard challenge request and response the ACS authenticates the cardholder outside of the 3-D Secure protocol such as a banking app or mobile phone text to the cardholder. The Moneris 3DS Server waits for the ACS to authenticate the cardholder; this authentication can take up to 7 days. As this process relies on a cardholder action outside the 3DS flow, it occurs asynchronously to transaction processing.

Your server can indicate in the request that you wish to allow Decoupled Authentication by utilizing the obect ”threeDSecureDecoupledRequestInformation”  with…

4. 3DS Authentication

3DS Authentication with 3RI validates cardholder identity without direct cardholder involvement at the initiation of the transaction.

You can initiate the 3DS authentication request via a POST to the Moneris API /three-d-secure/card-authentications endpoint. A number of fields for this endpoint are conditional to in a 3RI scenario

  • It is required to include “threeDSecureDeviceChannel” = “THREE_D_SECURE_REQUESTOR_INITIATED”. This indicates you are authenticating a merchant-initiated transaction. You must populate the “threeDSecureRequestorInitiatedIndicator” field with the use case of this authentication

  • For cardholder-initiated authentication, see 3DS Browser Channel instead

  • If you choose to allow for Decoupled Authentication, include the ”threeDSecureDecoupledRequestIndicator” object

  • If there was a prior authentication with 3D Secure for this cardholder, as part of a series of transactions include a ”threeDSecurePriorAuthenticationInformation” object

  • If this is a recurring series of transactions, include ”threeDSecureRecurringFrequency” and ”threeDSecureRecurringExpiry”. The ”threeDSecurePriorAuthenticationInformation” object is required in this scenario

  • If this is a Mail or Telephone (MOTO) payment authentication, the ACS may trigger a Decoupled Authentication between the issuer and cardholder (see Decoupled Authentication). You can opt-in to allowing a Decoupled Authentication to improve the likelihood of successful results via including the “threeDSecureDecoupledInformation”

  • If this is a follow-on payment from a previous 3DS authenticated transaction, you can include "threeDSecurePriorAuthenticationInformation" to link to the previous authentication and improve the likelihood of a successful result.

    • When using 3RI for a series of recurring transactions with “threeDSecureRequestType” = RECURRING this Prior Authentication object is mandatory and you must also include ”threeDSecureRecurringFrequency” and ”threeDSecureRecurringExpiry”

  • Omit the following fields as they are reserved for browser channel authentications: "threeDSecureRequestType", "threeDSecureNotificationUrl", "threeDSecureCompletionIndicator", "threeDSecureChallengeRequested", "threeDSecureChallengeWindowSize", "browserUserAgent", "browserJavaEnabled", "browserScreenHeight", "browserScreenWidth", "browserLanguage"

3RI flows do not begin with direct cardholder interaction. The merchant sends their POST Create Authentication including additional fields to describe their 3RI usage scenario and omitting fields exclusive to the browser channel.

3DS authentication examples

  • 3RI channel, with prior authentication, decoupled authentication
  • 3RI channel, with prior authentication, decoupled authentication and recurring
  • 3RI channel, for new MOTO, decoupled authentication
  • 3RI channel, with prior authentication (installment flow)

5. 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

Payment Flows
Basic Purchase Two-Step payment Payment with Hosted Tokenization

Additional Information

Learn more with the API Definitions

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

API References