3DS Requestor Initiated (3RI) authentication is an authentication method where the customer is not present, and the merchant initiates the transaction. A 3RI request refers to an initial purchase authentication while the customer was in session. 3RI provides a method for you to leverage the SCA obtained from the customer. ACS providers keep the context of the purchase to determine whether to provide CAVV/UCAF/AAV. Issuers leverage the 3RI proof of authentication to make better-informed authorisation decisions.

3RI authentications are independent new authentications, not incremental authentications to merge transaction amounts for multiple authentications. CAVVs and transaction amounts are single-use for matching an authentication to an authorisation.

When to use 3RI authentication

• Instalment payments: When a customer chooses an option like buy now, pay later, you can authenticate each subsequent instalments without the presence of the customer.
• Recurring payments: 3RI enables you to authenticate recurring transactions like service subscriptions or utility bills.
• Partial split shipment: If a customer orders multiple items from an online marketplace, but the items are not all available at the same time, you can ship and charge for the items separately using 3RI without the customer having to provide card details for each transaction.
• Multiple merchant authorisations by an agent: When there's one customer but multiple merchants, for example, a travel agent booking hotel and flights, or someone ordering from multiple vendors on a marketplace, 3RI makes it easy to perform one authentication for the customer and multiple authorisations for the merchants.
• Reauthorisation of a refunded purchase: If a customer returns items for a refund but they are not all present or in the expected condition, you can charge the customer again.
• Unknown final amount: When a customer is renting a car or a short-stay rental, 3RI allows you to take payments for further charges like damages, late checkout, or extra services.
• Requesting a new CAVV: To keep liability protection when authorising more than 90 days after a authenticating a transaction.

🚧

You must send prior authentication information and the original ACS transaction ID when submitting a 3RI transaction. Process a CAVV obtained under 3RI with the same rules as a CAVV obtained with the customer present.

How to send a 3RI request

To send a 3RI request, include the following parameters in the request:

• threeDSecure.channel = 01 - Indicates that the merchant initiated the transaction, and the customer is not present.
• customParameters[PriorReference] - ACS transaction ID of the customer-initiated authenticated transaction. This value is present in the response of the customer-authenticated transaction, in the acsTransactionId parameter.
• customParameters[PriorAuthData] - DS transaction ID of the customer-initiated authenticated transaction. This value is present in the response of the customer-authenticated transaction, in the dsTransactionId parameter.
• threeDSecure.threeRIInd - Depending on your use case, it should contain one of the following values: RECURRING, SPLIT_SHIPMENT, DELAYED_SHIPMENT.

Optional parameters

The following optional parameters are available:

• customParameters[PriorAuthTimestamp] - The date and time in UTC of the prior customer authentication. The accepted date format is YYYYMMDDHHMM. This value is present in the response of the customer-authenticated transaction, in the threeDSecure.authenticationTimestamp parameter.
• customParameters[PriorAuthMethod] - Information about the 3-D Secure authentication that occurred when the customer was present. Possible values:
  • 01 - Frictionless authentication
  • 02 - Challenge authentication
  • 03 - ACS verified
  • 04 - Other

Peach Payments recommends sending all the data parameters that you can, even if they are optional. This increases the issuer's confidence in the authenticity of the transaction and leads to better acceptance rates.