Introduction

3DS Requestor Initiated (3RI) or Merchant-initiated authentications is a new function that was introduced as part of the EMV 3DS 2.1 specification and was further extended in EMV 3DS 2.2. It allows merchants to generate the necessary authentication data for authorization without the cardholder being directly involved, by referencing details from the initial customer-initiated authentication. Using 3RI can provide a liability shift, and may increase authorization rates for merchant-initiated transactions.

This new functionality can be used to enable a variety of payment use cases, for example:

• Use cases where multiple CAVVs associated with one single cardholder authentication may be
  required: e.g., multi-party travel bookings, multiple authorization associated with split
  shipments
• Use cases where it is required to extend liability protection beyond the validity date of an
  initial CAVV such as for shipments delayed by more than 90 days

Use-cases

1. Multi-party commerce / Agent payment with multiple merchants

This use case allows multiple parties to process multiple authorizations from a single customer-initiated authentication. The merchant who performed the initial authentication (ie. the Agent) must submit separate 3RI requests for each additional merchant involved in fulfilling the order.

Example

A cardholder has booked on a travel website (Booking Agent) three items payable to each individual travel suppliers (merchant 1, 2 and 3 in the authorization system). The travel website is not collecting any funds but only authenticating on behalf of the 3 travel suppliers:

• a flight for EUR 170 payable to the airline (supplier/merchant 1) at booking
• a hotel for which no deposit is due at time of booking (card details taken by hotel
  (supplier/merchant 2) in case of a No Show payment being required) and
• a car rental for which a deposit of EUR 50 is due to the rental company (seller/merchant 3) at time
  of booking

In this example, the booking agent performs an authentication about the full amount of 220 EUR. Following the initial authentication the booking agents must do three 3RI requests with the specific amount per supplier to obtain separate authentication data for each supplier.

Implementation guide and sample request/response:

1. Initial customer initiated 3D request

Start with authenticating the full amount while the cardholder is in session. Please refer to one of our existing 3D implementations for the initial 3D request.

2. Merchant-initiated 3DS (3RI)

To request new authentication values, use the transactionId from the response of the previous customer initiated 3D request and call the multipleAuthentication endpoint. The amount must not exceed the total amount sent in the initial request. The request can be repeated as many times as needed but only until the total amount limit is reached. Please include threeRIInd with value 11 and the multiMerchantName property in your request.
For multiMerchantName, "merchantB" is the merchantName of the third party who you will be sharing the authentication information with in order for them to perform the transaction authorization.

Sample request/response (check the API Reference to get a detailed view of all required and optional fields).

curl -L -X POST 'https://api.sandbox.datatrans.com/v1/transactions/3RI/multipleAuthentication/{{transactionId}}' 
-H 'Authorization: Authorization: Basic {{basicAuth}}' 
-H 'Content-Type: application/json' 
--data-raw '{
    "refno": "3RItest",
    "currency": "EUR",
    "amount": 500,
    "threeRIInd": "11",
    "multiMerchantName": "MerchantB"
}
'

{
    "transactionId": "241682106922344246",
    "3D": {
        "eci": "05",
        "dsTransId": "213f3d94-7328-4f84-88de-ba1c761d4135",
        "threeDSTransactionId": "edeba639-2e2a-4d21-99b6-bc605a7d20e8",
        "cavv": "AJklkhCBHgkslKKKAH0l4MXdQAAAAA=",
        "threeDSVersion": "2.2.0",
        "directoryResponse": "Y",
        "authenticationResponse": "Y"
    }
}

3. Authorisation

Finally, forward the new authentication data returned in the response for any subsequent authorisation to your payment provider. Alternatively call the transaction status endpoint to access the new authentication values.

2. Split Payment / Deposit & Balance payment

This use case allows a merchant to collect an initial payment during a cardholder-initiated transaction (CIT) and subsequently collect one or more additional payments using 3DS Requestor-Initiated (3RI) authentications. This is particularly useful where the full amount is not due at the time of booking, or where a deposit is taken upfront and the remaining balance is charged closer to delivery of the product or service.

Example
A cardholder books a holiday package costing EUR 1'000 with a travel merchant. The merchant's terms require a deposit at the time of booking and the outstanding balance closer to the departure date:

• A deposit of EUR 200 is authorized immediately following a standard cardholder authentication with the total amount of EUR 1'000
• The remaining balance of EUR 800 is due 30 days before travel and is collected without requiring the cardholder to re-enter their card details or complete a new challenge.

In this example, the merchant performs an initial authentication of EUR 1'000 during checkout and captures the EUR 200 deposit. When the remaining balance becomes due, the merchant submits a 3RI authentication request for EUR 800 and obtains authentication data for the subsequent authorisation. This enables the balance payment to be processed without cardholder involvement while maintaining the benefits of EMV 3-D Secure authentication.

Implementation guide and sample request/response:

1. Initial customer initiated 3D request

Start with authenticating the full amount of the initial deposit while the cardholder is in session. Please refer to one of our existing 3D implementations for the initial 3D request.

2. Merchant-initiated 3DS (3RI)

When the remaining balance becomes due, submit a merchant-initiated 3RI authentication request to the multipleAuthentication endpoint. Use the transactionId from the original customer-initiated 3D-Secure authentication and specify the outstanding amount to be charged. The amount must not exceed the total amount sent in the initial authentication request.

Please include the threeRIInd field with the value 06 in the request. The response will return a new set of authentication data that can be used for the subsequent payment authorisation.

Sample request/response (check the API Reference to get a detailed view of all required and optional fields).

curl -L -X POST 'https://api.sandbox.datatrans.com/v1/transactions/3RI/multipleAuthentication/{{transactionId}}' 
-H 'Authorization: Authorization: Basic {{basicAuth}}'
-H 'Content-Type: application/json' 
--data-raw '{
      "refno": "3RItest",
      "currency": "EUR",
      "amount": 800,
      "threeRIInd": "06"
  }
'

{
    "transactionId": "241682106922344246",
    "3D": {
        "eci": "05",
        "dsTransId": "213f3d94-7328-4f84-88de-ba1c761d4135",
        "threeDSTransactionId": "edeba639-2e2a-4d21-99b6-bc605a7d20e8",
        "cavv": "AJklkhCBHgkslKKKAH0l4MXdQAAAAA=",
        "threeDSVersion": "2.2.0",
        "directoryResponse": "Y",
        "authenticationResponse": "Y"
    }
}

3. Authorisation

Finally, forward the new authentication data returned in the response for any subsequent authorisation to your payment provider. Alternatively call the transaction status endpoint to access the new authentication values.

Testing

We are adding 3RI test scenarios to the 3D Simulator in the Sandbox environment. Until these scenarios are available, the 3RI request will return the same CAVV value that was generated for the initial CIT 3-D Secure authentication.

For comprehensive end-to-end validation, we recommend testing 3RI flows in the Production environment, as this ensures that all involved third-party systems, including the 3DS Server, ACS, and card issuer, are part of the authentication process.