3RI, also known as Merchant Initiated Authentication, is a type of Merchant Initiated transaction that involves a cardholder authentication step without active interaction from the cardholder. But before we understand more about 3RI, understanding some fine points of the CIT/ MIT framework becomes essential.
A brief about CIT and MIT framework
CIT, or a customer initiated transaction, is a transaction initiated by the customer by entering their card details on the merchant website/ app. This is the time when the merchant can trigger a strong customer authentication (SCA) for the cardholder for PSD2 compliance in Europe.
Since a CIT card transaction is authenticated by the issuer ACS using, the merchant receives chargeback liability protection, i.e. the liability lies with the issuer.
MIT, or merchant initiated transaction, is a transaction initiated by the merchant system when the customer is not present to interact on their app. This is out of scope of SCA and typically does not require any customer action. An example use case for MIT is recurring payment for subscription products.
For setting up future MITs (for recurring or installment use cases), it is required that -
The customer is strongly authenticated during the first transaction of the series (CIT)
The customer is explicitly informed of the merchant and recurring payments amount, frequency and end date
For an MIT, the merchant cannot authenticate the cardholder (since the cardholder is not present on their app). The merchant directly sends the request to the Issuer for authorization with prior CIT data. However, the MIT payment is not authenticated explicitly by the Issuer ACS. Hence, the liability of MIT payment lies with the merchant. Additionally, there are chances that the Issuer can decline the MIT authorization on the basis of risk associated with the transaction.
This is where 3RI helps!
Some Terminologies
Authentication - This is that part of the transaction where the identity of the cardholder is validated by asking them to perform specific actions like entering an OTP, entering their fingerprint or other biometrics, etc. The issuer ACS sends the result of authentication in the form of a token/ cryptogram called as Accountholder Authentication Value (AAV), ECI, etc.
Authorization - This is that part of the transaction where the merchant requests the Issuer to release the funds from the cardholder’s account. If applicable, the merchant has to send the AAV during the authorization request.
AAV - The Accountholder Authentication Value is a cryptogram sent by the Issuer ACS to indicate the status of customer authentication. The re-use of AAV for multiple authorizations is strongly discouraged (although used for 3DS v2.1 in certain cases) and the AAV is valid for upto 90 days.
What is 3RI?
3RI (Merchant initiated authentication or requestor initiated authentication) is a method by which the merchant can generate an AAV without any customer action, that can be used for subsequent authorization. The merchant needs to send the card details and reference to the prior CIT transaction when they request a new AAV. This process helps all the parties involved to take better decisions about every transaction as the authentication data is shared with all the parties before an authorization.
Since the 3RI payments are authenticated by an Issuer ACS, the chargeback liability for 3RI MITs lie with the issuer. In case the issuer declines the 3RI authentication request, the merchant has to re-initiate the transaction with an SCA CIT or retry an MIT without 3RI and deal with the liability.
MIT payments encompass a broader category of merchant-initiated transactions, including recurring payments; while 3RI payments specifically refer to recurring transactions authenticated using the 3D Secure protocol for enhanced security and liability shift.
Who can use 3RI?
There are multiple use cases for 3RI payments. Some of the important ones are -
Recurring Payments
Instead of directly sending the authorization request as MIT, the merchant can initiate a 3RI authentication for recurring payments and then do the authorization with the received AAV. This helps the merchant to get chargeback liability protection on MIT payments and also reduces the probability of transaction declines in authorizations.
Delayed Delivery/ Pre-order
This is a scenario in which the merchant offers a trial period before purchase of the product/ subscription or pre-ordered products that take months for the delivery. If the period between authentication and authorization exceeds 90 days, the merchant can generate a new AAV from the older one and complete the authorization post order fulfillment.
Partial Split Shipment
The typical use case is when an E-commerce merchant fulfills the order in multiple batches and charges the customer after the delivery. The customer is initially authenticated for the total amount, but for every batch fulfilled, the merchant requests a 3RI authentication with the batch order amount and the reference of the first authentication. Each time, the merchant receives a different AAV that can be used for authorization.
Agent Payments
An example of this use case is the travel aggregators. The aggregator platform (Agent) authenticates the customer for both flight tickets (Merchant A) and hotel reservations (Merchant B). Merchant A can do a usual authorization. Merchant B has to do a 3RI authentication with reference to the original authentication and get an AAV that can be used for authorization.
Unknown Final Purchase Amount
This requirement arises when the merchant does not know the final amount of the purchase at the time of customer authentication. Typical examples are fines on car rentals, hotel services availed other than accommodation, tips after a taxi ride, etc. The merchant can authenticate the customer for accommodation or car rental, but for extra charges, can do a 3RI authentication followed by authorization.
Installment Payments
Some merchants decide to enable Buy Now Pay Later (BNPL) options for their customers. In that case, the merchant can authenticate a customer in the payment flow, and for the subsequent installments, use 3RI.
Re-authorization of a refunded purchase
The merchants allow customers to return their order and issue a refund. In case the amount is refunded before the return order is received and if there are issues (like used/ torn/ missing) goods, the Merchant can initiate a 3RI authentication to authorize the customer again.
AAV Refresh
There can be use cases when the merchant wants to authenticate the cardholder now, but authorize after a few days. If the time lapse between authentication and authorization is greater than 90 days (AAV retention period), the AAV cannot be used as it is. In that case, the merchant has to request a fresh AAV with the reference of the older AAV and then do the authorization.
Way Forward
A lot of the above use-cases can be fulfilled without 3RI.
For example, in case of Partial split shipment, the merchant can do partial captures after delivery of each batch of the order. But in cases where the delivery is extended beyond 7 days, the remaining amount blocked on the cardholder’s account will be voided automatically.
Another example can be - in the Agent model, two or more merchants can use the same AAV for authorization of different amounts that they want to collect. The Flight merchant collects $700 and the hotel merchant collects $300 on an authentication done by the agent platform for $1000. However, there will be a mis-match in the merchant details sent in the authentication vs authorization. The networks still allow such mismatch for 3DS version 2.1, but from version 2.2 onwards, they expect the merchants to use 3RI so that accurate data can be sent in all the requests.
With the sunset of 3DS version 2.1 planned in Sept/ Oct 2024 by major networks like Visa, Mastercard and American Express (EMVCo already does not support EMV 3DS 2.1, and new providers cannot certify for that version), adoption of 3RI becomes critical. All the parties involved in the cards payment system intend to extend the use of 3RI for more use cases.
