3D Secure 2 Concepts

This page has conceptual information on the following 3D Secure 2-specific terminologies:

3D Secure 2 Message categories

Message category (messageCategory) helps the merchant and the issuer to identify data elements that should be included in a message based on the type of transaction. You send the messageCategory field value to the issuer in the /authenticate request. This field value is one of the key factors that decide the flow of the messages and the response returned by the issuer.

Payment Authentication (PA)Non-Payment Authentication (NPA)
Used for transactions that involve a payment.Used for transactions that involve verification of account based on data provided by a cardholder at the time of account creation or account information changes.
Cardholder authentication during an e-commerce transaction.Identity verification and account confirmation. An example use case could be to add a card to a merchant’s website or modify stored cardholder information.
Code used in the requests to specify a PA is messageCategory = 01Code used in the requests to specify an NPA is messageCategory = 02
If a transaction is deemed authenticated (Transaction Status = Y or A), the ACS generates the ECI value (eci) and Authentication Value (authenticationValue) and includes them in the ARes message.If a transaction is deemed authenticated (Transaction Status = Y or A), the ACS may:
  • Generate the ECI value (eci) and Authentication Value (autheticationValue) and include them in the ARes message.
  • Assign an appropriate Transaction Status Reason code (transStatusReason) and include them in the ARes message. This is conditional as defined by the DS.

Device channel types

Device channel (deviceChannel) indicates the channel from which the transaction originated. In the /authenticate request, you can be set to either:

  • App-based (01-APP)
  • Browser-based (02-BRW)
  • 3DS Requestor Initiated (03-3RI)

The required fields for each device channel might be different. Therefore, to avoid an error, you must send the appropriate deviceChannel in the request.

Browser-basedApp-based3DS Requestor Initiated (3RI)
deviceChannel = 02deviceChannel = 01deviceChannel = 03
Use this when you send the /authenticate request either directly through your server or through the 3DS Web SDKUse this when you send the /authenticate request through the mobile SDK integrated in your appUse this when you send the /authenticate request for a merchant-initiated transaction (3RI)
Includes cardholder account information and transaction details about the payment.Includes cardholder account information and transaction details about the payment.Includes cardholder account information. The transaction amount could vary for each recurring transaction.
The consumer device used for the transaction must support a browser.The merchant app must be embedded with the 3DS SDK.The merchant’s server must have the cardholder details already on file.
Transaction initiated by the cardholder through the merchant’s website.Transaction initiated by the cardholder through the merchant’s app.A transaction is initiated by the merchant’s server for either deviceless payment authentication or verification of account.
Supports all transStatusSupports all transStatusDoes not support transStatus = C i.e., a challenge because the cardholder is not present. Challenge can happen only in the form of decoupled authentication (transStatus = D).
In case of a challenge (transStatus = C), the CReq message is sent by the 3DS Server. There is only one CReq message per challenge.In case of a challenge (transStatus = C), the CReq message is sent by the 3DS SDK. There are two or more CReq messages per challenge as multiple back-and-forth attempts between the ACS and the Cardholder may be required to complete the authentication.CReq and CRes messages are not part of a 3RI authentication.
Uses the 3DS Method to gather browser information/device details and the issuer’s ACS provides an HTML to the browser to display the UI to the cardholder in case of a challenge.Challenge flows are message-based, not HTML. Challenge UI shown to the cardholder by the SDK.Challenge happens only in the form of decoupled authentication (transStatus = D).
The CRes indicates the result of the cardholder authentication.The CRes may indicate the result of the Cardholder authentication or signal that further Cardholder interaction is required to complete the authentication.CReq and CRes messages are not part of a 3RI authentication.

Challenge flow and Decoupled authentication

Based on the information sent in the /authenticate request, the issuer can decide to challenge the cardholder’s identity. In this case, the /authenticate response will return one of these challenge mechanism the issuer will use.

Challenge FlowDecoupled Authentication
transStatus = CtransStatus = D
Supported only for deviceChannel = 01 (App) or 02 (Browser)Elavon’s 3D Secure solution supports decoupled authentication only for deviceChannel = 02 (only the direct integration option) or deviceChannel = 03 (3RI).
Supported for both messageVersion = 2.1.0 or 2.2.0Supported only for messageVersion = 2.2.0
Cannot be used in Mail Order/Telephone Order (MOTO) transactions, the cardholder is off session, or 3RI transactions.Supports almost all transaction types unless the issuer does not support decoupled authentication.
The challenge happens as part of the payment process while the transaction authentication is in progress. Transaction is authenticated or declined as soon as the merchant website/app receives the final authentication result.Challenge happens outside the payment/verification process. Merchant (website/app) notifies the cardholder as soon as it gets a notification that the issuer will use a decoupled authentication to challenge the cardholder. It waits for the final authentication result from the issuer via the 3DS Server.
Cardholder completes the challenge within a maximum time of 10 minutes. The time to complete a challenge and the number of tries is defined by the issuer.Cardholder completes the challenge within a maximum time of 7 days depending on the maximum time (threeDSRequestorDecMaxTime) specified by the merchant in the authentication request.
No special setup required on your environmentBefore you indicate the support for decoupled authentication, you must set up an endpoint that will receive all webhook event notifications from the 3DS Server and call Elavon support to add the endpoint to the list of allowed URLs.
Merchant can specify the challenge preference through this field in the AReq. This is an optional field. If this field is missing in the AReq, the issuer interprets the value as no preference.
  • 3DS Requestor Challenge Indicator (threeDSRequestorChallengeInd)
Merchant must send these two fields in the AReq to let the issuer know that the merchant supports decoupled authentication:
  • threeDSRequestorDecReqInd = Y
  • threeDSRequestorDecMaxTime (maximum time within which the cardholder must complete the challenge)

threeDSRequestorDecReqInd is an optional field. If this field is missing in the AReq, the issuer interprets the value as do not use decoupled authentication.
From the data received in the AReq, the issuer checks whether the Consumer Device is supported for a challenge scenario. If the device is not supported, the ACS returns an ARes message with a Transaction Status = U and Transaction Status Reason code = 03.The consumer device that initiated the transaction does not need to be supported when the ACS has alternative approaches to authenticating the cardholder.
If the issuer decides to challenge the cardholder, it must return the following fields in the ARes:
  • acsURL, a fully qualified URL of the ACS to be used for the challenge (only for deviceChannel = 02)
  • creq, a base64 encoded challenge request message (only for deviceChannel = 02)
  • acsChallengeMandated = Y
  • acsRenderingType (only for deviceChannel = 01)
  • acsSignedContent (only for deviceChannel = 01)
  • authenticationType
If the issuer uses decoupled authentication, it must return the following fields in the ARes:
  • acsDecConInd = Y
  • acsChallengeMandated = Y
  • authenticationType
  • cardholderInfo
The Challenge flow includes CReq and CRes messages.Challenge request (CReq) and response (CRes) messages are not used and the issuer notifies the final result to the 3DS Server through the RReq.

note

This release does not support the decoupled authentication feature that is supported in the EMVco 3DS 2.2 specification.

Related topics