3-D Secure Authentication – Requestor Initiated

Overview

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

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.

📘
Moneris Sales Support
Phone: 1-855-465-4980

2. Requestor Initiated Flow (3RI)

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.

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.

📘

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

3. Decoupled Authentication

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 object ”threeDSecureDecoupledRequestInformation” with…

📘

”threeDSecureDecoupledRequestIndicator” set to “true”.

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

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

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

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.

📘

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"

3DS authentication examples

{
"idempotencyKey": "6q5w4e7r8t9y",
"orderId": "1q2w3e4r5t6t78",
"amount": {
"amount": 16000,
"currency": "CAD"
},
"cardholderName": "John Smith",
"email": "[email protected]",
"shippingAddress": {
"unitNumber": "123A",
"streetNumber": "3300",
"streetName": "Bloor Street West",
"city": "Toronto",
"province": "Ontario",
"postalCode": "M8X 2X2",
"country": "CA"
},
"billingAddress": {
"unitNumber": "123A",
"streetNumber": "3300",
"streetName": "Bloor Street West",
"city": "Toronto",
"province": "Ontario",
"postalCode": "M8X 2X2",
"country": "CA"
},
"paymentMethod": {
"cardholderInformation": {
  "cardholderName": "John Smith",
  "companyName": "SP Ltd"
},
"contactDetails": {
  "phoneNumber": "1-866-319-7450",
  "email": "[email protected]"
},
"billingAddress": {
  "unitNumber": "123A",
  "streetNumber": "3300",
  "streetName": "Bloor Street West",
  "city": "Toronto",
  "province": "Ontario",
  "postalCode": "M8X 2X2",
  "country": "CA"
},
"paymentMethodData": {
  "paymentMethodType": "CARD",
  "card": {
    "cardNumber": "4444111122223333",
    "expiryMonth": 1,
    "expiryYear": 2023,
    "cardSecurityCode": 123
  }
}
},
"threeDSecureMessageCategory": "PAYMENT",
"threeDSecureDeviceChannel": "THREE_D_SECURE_REQUESTOR_INITIATED",
"threeDSecureRequestorInitiatedIndicator": "MAIL_ORDER",
"threeDSecurePriorAuthenticationInformation": {
"threeDSecurePriorAuthenticationData": "12345678",
"threeDSecurePriorAuthenticationMethod": "AVS_VERIFIED",
"threeDSecurePriorAuthenticationTimestamp": "2019-07-30T06:43:40.252Z",
"threeDSecurePriorAuthenticationReference": "12345678"
},
"threeDSecureCompletionIndicator": "SUCCESS",
}

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
Purchase Pre-Authorization & Completion Purchase with Payment Token

Additional Information

📘
Learn more with the API Definitions
Peruse the endpoints, request/response formats, and authentication methods covered in this scenario.
API References