3RI (Merchant-initiated) transactions

On this page

error_outline

note

If you have identified any errors or gaps in the content, please contact: email #SEDevPortalSupport@elavon.com

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. Another example could be a split shipment, the order is delivered in multiple shipments, or the final amount is not known at the time of order.

error_outline

note

3D Secure 2.1 supports only scenarios related to a non-payment transaction i.e. the messageCategory must always be 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). In case of account confirmation (diagram 1), 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

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 this table to help you decide the next step.

Scenario Next 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.0 It 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.

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. 

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 this table to understand the next steps for each transStatus value.

transStatus Description Liability shift Next step Example scenario
Y Issuer 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 issuer Merchant 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.
A Issuer 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 issuer Merchant 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.
N Issuer has not authenticated the transaction, or could not verify the account, or denied the transaction. No liability shift If 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.
U Issuer has not authenticated the transaction or verified the account due to a technical or another problem. No liability shift If 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.
R Issuer is rejecting the authentication or account verification and requesting that authorization not be attempted. No liability shift If 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.
error_outline

note

The liability shift is only for disputed transactions or chargebacks. Use the 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