Merchant-initiated (3RI) transactions

On this page

Overview

In a 3D requestor-initiated (3RI) or a merchant-initiated transaction, the cardholder is not present during the transaction. The merchant’s server has the cardholder’s information stored from an earlier transaction. Merchant can use this information for either deviceless payment authentication or verification of account.

Sample use cases

  • Recurrent transactions such as TV subscriptions, utility bill payments, etc. In this case, the merchant wants to either perform a payment transaction (messageCategory= 01) to receive authentication data for each bill or a non-payment transaction (messageCategory= 02) to verify that a subscription user still has a valid form of payment.

note

3D Secure 2.1 supports only scenarios related to a non-payment transaction i.e. the messageCategory must always be 02 but 3D Secure 2.2 supports both messageCategory = 01 and 02.

3D Requestor-Initiated Workflows

The 3RI workflow diagrams show that the merchant’s server sends the optional /lookup request to check the supported 3D Secure version. After receiving the /lookup response, they send the /authenticate request to the 3DS Server. The 3DS Server uses this data to create an authenticate request and sends it to the issuer (ACS). The authentication response can result in the following scenario:

  • In case of account confirmation (diagram1), the issuer validates the data sent in the request and sends the authentication response to the 3DS Server, which passes the response to the merchant’s server.
A diagram explaining the request and responses flow among the client and the servers involved in 3DS authentication of a transaction when the authentication request is initiated by a 3D Requestor and the cardholder is not challenged

Diagram 1: High-level communication during a 3RI transaction for account confirmation (no challenge)

Prerequisites

You must have the cardholder data stored in your server. The first transaction that the merchant used to store a cardholder’s information for future use could be sent using one of the following integration option:

But a subsequent merchant-initiated (3RI) transaction can be initiated by only using the direct API method i.e., sending the /authenticate request directly to the 3DS Server. You cannot use the Web SDK or the Mobile SDKs to send a 3RI authentication request (i.e. deviceChannel = 03).

3D Secure 2 Authentication steps for each transaction

(Optional) Step 1: Send cardholder’s account number to verify support for 3D Secure 2 (/3ds2/lookup)

Send the card holder’s card/account number to Elavon’s 3DS Server to:

  • verify if the card used by the cardholder for the transaction supports 3D Secure 2

  • retrieve key characteristics of the card used in the transaction such as the card BIN, scheme, brand, country, and currency where the card has been issued, if the card is a debit or a credit card, etc. The BIN is the first four, six, or more digits of the card number. The /3ds2/lookup request uses the BIN information to scan an internal repository of data to retrieve more details about the card being used.

The BIN lookup parameters along with the fact the card supports 3DS 2 authentication can help you understand which version of the 3D Secure 2 the card supports.

If you do not send the /lookup request and send the (/authenticate (Step 3)) request directly, the /authenticate response will return an error message if the issuer does not support the requested 3D Secure version.

Use the following links for a sample /lookup request, response, and parameters description:

(Optional) Step 2: Verify the /3ds2/lookup response

The 3DS Server uses the ACS Start Protocol Version, ACS End Protocol Version, DS Start Protocol Version, and DS End Protocol Version returned in the /lookup response to verify that the ACS and the DS support the 3DS protocol version used by the 3DS Server. It uses the ACS Information Indicator to identify the features that the account supports.

Verify the /3ds2/lookup response and use the scenarios in table 1 to help you decide the next step.

Table 1: /lookup response scenarios

ScenarioNext Step
Scenario 1: If the /3ds2/lookup response does not have the version fields (dsStartProtocolVersion, dsEndProtocolVersion, acsStartProtocolVersion, acsEndProtocolVersion) or the values of these fields are 1.0.2, it means that the card number (PAN) does not support 3DS 2 authentication.You cannot proceed with 3DS 2 authentication for this transaction. A merchant-initiated transaction is not a supported scenario if an acctNumber does not 3D Secure 2.
Scenario 2: If the /3ds2/lookup response contains the version fields (dsStartProtocolVersion, dsEndProtocolVersion, acsStartProtocolVersion, acsEndProtocolVersion) and their values are 2.1.0It means that the acctNumber and the issuer supports 3D Secure 2.1.0. Send an /authenticate request to the 3DS Server. See Step 3 for more details.
Scenario 3: If the /3ds2/lookup response contains the version fields (dsStartProtocolVersion, dsEndProtocolVersion, acsStartProtocolVersion, acsEndProtocolVersion) and their values are 2.2.0It means that the acctNumber and the issuer supports 3D Secure 2.2.0. Send an /authenticate request to the 3DS Server. See Step 3 for more details.

Step 3: Submit cardholder data to the 3DS Server to initiate the 3DS authentication process (/3ds2/authenticate)

If the card used in the transaction supports 3D Secure 2, submit the required authentication information to Elavon’s 3DS Server. The 3DS Server in turn creates an authentication request and sends it to the ACS. 

Review table 2 to understand how these three fields in the /authenticate request help the 3DS Server to decide whether to follow 3DS 2.2 or 3DS 2.1 authentication flow for deviceChannel = 03: messageVersion, clientStartProtocolVersion, and clientEndProtocolVersion.

Table 2: 3DS Server Fallback Strategy

messageVersionclientStartProtocolVersionclientEndProtocolVersion3DS Server Fallback Strategy
1.0.21.0.21.0.2Error. Not a supported scenario.
1.0.21.0.22.1.0 or 2.2.0Error. Not a supported scenario.
2.1.0 or 2.2.01.0.21.0.2Error. Not a supported scenario.
2.1.01.0.22.1.0 or 2.2.0Check support for 3DS 2.1. If not supported, return an error.
2.1.02.1.02.1.0Check support for 3DS 2.1. If not supported, return an error.
2.1.02.1.02.2.0Check support for 3DS 2.1. If not supported, return an error.
2.2.01.0.22.2.0Check support for 3DS 2.2 first. If not supported, check support for 3DS 2.1. If 3DS 2.1 is not supported, return an error.
2.2.02.1.02.1.0Error response
2.2.02.2.02.2.0Check support for 3DS 2.2. If not supported, return an error.
2.2.02.1.02.2.0Check support for 3DS 2.2 first. If 3DS 2.2 is not supported, fall back to 3DS 2.1. If 3DS 2.1 is not supported, return an error.

note

  • messageVersion is an optional field and if you do not manually specify a value in the authenticate request, the 3DS Server sets its default value to 2.1.0.

  • If the 3DS Server falls back the request to 2.1.0, the issuer ignores all fields that are specific only to the 3D Secure 2.2.0.

  • The request will not fallback from 2.2.0 to 2.1.0 under following conditions:

  • if you send a value specific to the 2.2.0 spec only in an existing field (a field that was present in the 2.1.0 spec as well). For example, if you set the field value of the threeDSRequestorAuthenticationInd field (present in both the 2.1.0 and the 2.2.0 spec) to 07(billing agreement). Here the field value 07 is specific to 2.2.0 only.

  • if you send a combination of fields values that are not applicable to the 2.1.0 spec. For example, if you set deviceChannel=03 (3RI) and messageCategory=01 (PA).

Use the following links to refer to the /authenticatesample request, response, and parameters description.

To increase the chances of successful authentication, include information for all required and optional fields in the authentication request you send to the 3DS Server. However, do not send dummy data if you do not have data for an optional field.

Step 4: Verify the 3DS authentication response from the 3DS Server

Verify the value of the transStatus field in the /3ds2/authenticate response sent by the 3DS Server because it determines your next step. Review the information in table 3 to understand the next steps for each transStatus value.

Table 3: Description of the transStatus field value in /authenticate response

transStatusDescriptionLiability shiftNext stepExample scenario
YIssuer has authenticated the customer’s data. You can use the transStatus, authenticationValue, and eci field values to authorize the transaction. The flow is considered frictionless and the 3DS processing will end at this step.Card issuerMerchant can use the eci and authenticationValue in the authentication response to proceed to card authorization.You get this value in case of a successful authentication or a frictionless flow.
AIssuer has not authenticated the transaction, but a proof of authentication attempt (authenticationValue) was generated. You can use the transStatus, authenticationValue, and eci field values to authorize the transaction. The 3DS processing will end at this step.Card issuerMerchant can use the eci and authenticationValue in the authentication response to proceed to card authorization.You get this value in case of an attempted authentication.
IIssuer acknowledges that the request was sent for informational purposes only and did not need a challenge.Not applicableMerchant should store the authenticationValue and eci field values, if included in the response.You get this value when you send the request only for information and do not request for authentication. To indicate this in the authentication request, you sent a value of 05, 06, or 07 in the threeDSRequestorChallengeInd field.
NIssuer has not authenticated the transaction, or could not verify the account, or denied the transaction.No liability shiftIf you get this value, verify the value in the transStatusReason field. Based on the value received, you can do either of the following:
  • Try to send the authentication request again
  • Request the customer for another form of payment
  • Decline the transaction
  • Move forward with authorization at your own risk
You get this value in case of authentication processing errors such as when the cardholder fails all challenges to prove cardholder identity.
UIssuer has not authenticated the transaction or verified the account due to a technical or another problem.No liability shiftIf you get this value, verify the value in the transStatusReason field. Based on the value received, you can do either of the following:
  • Try to send the authentication request again
  • Request the customer for another form of payment
  • Decline the transaction
  • Move forward with authorization at your own risk
You get this value in case of technical errors such as when the ACS is not reachable.
RIssuer is rejecting the authentication or account verification and requesting that authorization not be attempted.No liability shiftIf you get this value, verify the value in the transStatusReason field. Based on the value received, you can do either of the following:
  • Try to send the authentication request again
  • Request the customer for another form of payment
  • Decline the transaction
  • Move forward with authorization at your own risk
You get this value in case the issuer rejects authentication and requests that authorization should not be attempted.

note

The liability shift is only for disputed transactions or chargebacks. Use the following information related to liability shift and next steps for merchants as a reference. These can differ for each card scheme and each issuer might have different criteria for liability shift.

Related topics