3RI (Merchant-initiated) transactions

On this page

note

If you have identified any errors or gaps in the content, please contact: #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.

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:

Direct API
Web SDK
Mobile SDKs (releasing soon)

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.

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.