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.
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:
- 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. 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/lookuprequest 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:
- /3ds2/lookup sample request and response
- Description of /3ds2/lookup request and response parameters
- Test scenarios - Sample /3ds2/lookup scenarios
(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
| 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. |
Scenario 3: If the /3ds2/lookup response contains the version fields (dsStartProtocolVersion, dsEndProtocolVersion, acsStartProtocolVersion, acsEndProtocolVersion) and their values are 2.2.0 | It 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
| messageVersion | clientStartProtocolVersion | clientEndProtocolVersion | 3DS Server Fallback Strategy |
|---|---|---|---|
| 1.0.2 | 1.0.2 | 1.0.2 | Error. Not a supported scenario. |
| 1.0.2 | 1.0.2 | 2.1.0 or 2.2.0 | Error. Not a supported scenario. |
| 2.1.0 or 2.2.0 | 1.0.2 | 1.0.2 | Error. Not a supported scenario. |
| 2.1.0 | 1.0.2 | 2.1.0 or 2.2.0 | Check support for 3DS 2.1. If not supported, return an error. |
| 2.1.0 | 2.1.0 | 2.1.0 | Check support for 3DS 2.1. If not supported, return an error. |
| 2.1.0 | 2.1.0 | 2.2.0 | Check support for 3DS 2.1. If not supported, return an error. |
| 2.2.0 | 1.0.2 | 2.2.0 | Check 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.0 | 2.1.0 | 2.1.0 | Error response |
| 2.2.0 | 2.2.0 | 2.2.0 | Check support for 3DS 2.2. If not supported, return an error. |
| 2.2.0 | 2.1.0 | 2.2.0 | Check 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
messageVersionis an optional field and if you do not manually specify a value in the authenticate request, the 3DS Server sets its default value to2.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 Secure2.2.0.The request will not fallback from
2.2.0to2.1.0under following conditions:if you send a value specific to the
2.2.0spec only in an existing field (a field that was present in the2.1.0spec as well). For example, if you set the field value of thethreeDSRequestorAuthenticationIndfield (present in both the2.1.0and the2.2.0spec) to07(billing agreement). Here the field value07is specific to2.2.0only.if you send a combination of fields values that are not applicable to the
2.1.0spec. For example, if you setdeviceChannel=03(3RI) andmessageCategory=01(PA).
Use the following links to refer to the /authenticatesample request, response, and parameters description.
- Sample request and response
- Description of request and response parameters
- Test scenarios - Sample /3ds2/authenticate scenarios
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
| 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. |
I | Issuer acknowledges that the request was sent for informational purposes only and did not need a challenge. | Not applicable | Merchant 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. |
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:
| 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:
| 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:
| 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.