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
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 (suggestion to link out to the 3DS Create Authentication API reference here… alternatively, we could list all the enums here with their usage scenarios?)
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
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
Additional Information
Learn more with the API Definitions
Peruse the endpoints, request/response formats, and authentication methods covered in this scenario.
.svg)