Merchant Initiated Authentication 3RI

Version 2.2 of 3D Secure (3DS) introduced Requestor-Initiated (3RI) authentications, also known as merchant-initiated authentications. With 3RI authentications, merchants can generate the necessary authentication data for authorization without the customer being directly involved with the transaction. They also allow merchants to reference a previous authentication where the customer was involved.

Some of the use cases for 3RI authentications include:

• Partial split shipment — Where ordered products are not all available at the same time, and the merchant decides to ship and charge for them separately.
• Agent payment with multiple merchants — This involves one authentication with the customer present and multiple authorizations for each merchant involved in the transaction. For example, a travel agent managing an order of both hotel and airline for different merchants.
• Unknown final amount before purchase — Where the final amount is not known, for example, potential extra costs for a car rental like damages, missed return date, and so forth.
• Replacement (re-authorization) of a refunded purchase — Where a merchant offers free refunds on items the customer does not want. If the returned items do not include everything purchased, the merchant has to charge the customer again.

In this guide, we focus on a partial split shipment use case. We start with an authentication involving the customer for the full amount of the order. The first authorization is then submitted as fully authenticated for the amount of the first shipment. At this point, we are storing the card number to use for future authentications and authorizations. For more information on how to store a card, see our Card Storage article.

When the next item is to be shipped and charged for, the customer is not present, so we execute a 3DS 3RI authentication. The request must include the ACS Transaction Reference of the initial authentication regardless of whether it was a frictionless or challenge flow. The value must be submitted in the Prior 3DS Authentication Data object.

Providing the data from the previous authentication will increase the chances that the Issuer will approve the transaction without requiring additional authentication. If this is required, Decoupled Authentication is used as a method to authenticate the customer. For more information, see our Decoupled Authentication article.

In our example, the full order amount is £100 for two items, one of which is in stock while the other is not. We start by processing a standard 3D Secure 2 authentication for the full amount. For more information on the Initiate Authentication request, see Authentications in the API Explorer.

Sample response

In the response, we note whether the authentication was frictionless or required a challenge since we will be passing this information in the Authentication Method field of the 3RI authentication.

When authentication is complete, we then process an authorization for the amount of the first shipment, which in this example is £50. Since we used the full card number for authentication and authorization, we can store the card for future use. (If you use a single-use token, you can convert it to a multi-use one.)

Sample response

In this step, we process an authentication for the remaining £50 of the order using the card we stored in the previous step. In this request, we specify that we're performing a 3DS Requestor (3RI) / Merchant-Initiated Authentication. As part of the message body, we must also include the authentication data from Step 1: Prior 3D Secure Authentication Data.

In the response, the Issuer might determine that additional authentication is required. If this is required, decoupled authentication will be used. For more information, see our Decoupled Authentication article.

Sample response

Now that the 3RI authentication is complete, we submit the authorization for the remaining £50. We pass the authentication ID from Step 3 in the request.