3D Secure Requestor Initiated (3RI) Transactions

3RI is a message type defined in the EMV 3D Secure version 2 specification, and it allows a merchant to request authentication for a transaction that the merchant initiates rather than the cardholder. The full name is 3D Secure Requestor Initiated, and the requestor is the merchant or the merchant's payment service provider. Unlike a normal browser based or app based 3D Secure flow, there is no cardholder interaction, no challenge screen, and no one-time password. The issuer returns an authentication result based on the data the merchant sends, including the stored credential reference, the transaction history, and risk signals. This makes 3RI the right tool for recurring and instalment payments. The difference between 3RI and a normal 3DS authentication is mainly about who is present and what the authentication proves. A normal 3DS flow authenticates the cardholder in real time and gives the merchant a liability shift, meaning the issuer takes responsibility for fraud on that transaction. A 3RI flow does not authenticate the cardholder, because the cardholder is absent, so it cannot provide the same liability shift in the same way. What it does provide is an authentication value that the merchant can include in the authorisation request, which tells the issuer that the transaction was checked against the stored mandate. Issuers generally treat a 3RI authenticated transaction more favourably than a plain merchant initiated transaction. A merchant uses 3RI in several specific situations. The most common is a recurring subscription payment, where the merchant wants the best possible authorisation rate on a charge the customer is not present for. Another is a delayed shipment, where the merchant takes a pre-authorisation at order time and captures the money later when the goods ship. A third is a split shipment, where one order is delivered in parts and each part is charged separately. A fourth is an instalment payment, where a large purchase is paid in fixed monthly parts. In each case the merchant initiates the transaction, and 3RI gives the issuer a structured way to validate it. The 3RI flow follows a clear sequence of steps. First, the merchant's system decides that a payment is due, for example a monthly subscription renewal. Second, the merchant sends a 3RI authentication request to the 3D Secure server, including the stored credential details, the scheme reference identifier from the original transaction, the amount, and the merchant information. Third, the 3D Secure server forwards the request to the issuer's access control server. Fourth, the issuer checks the mandate, the transaction history, and the risk data, and returns an authentication result, usually a frictionless approval. Fifth, the merchant includes the authentication value in the authorisation request to the acquirer. For a business analyst, the important details of 3RI are the data elements and the error handling. The BA must specify which fields the merchant system sends in the 3RI request, such as the 3RI indicator, the recurring frequency, the expiry date of the mandate, and the previous transaction identifier. The BA must also document what happens when the issuer returns a negative result or no result at all, because the merchant still has to decide whether to attempt the authorisation without authentication or to contact the customer. Finally, the BA must confirm with the acquirer and the gateway whether 3RI is supported for each card scheme, since Visa and Mastercard implement the details differently, and not every issuer supports 3RI yet. For example, a merchant sells a software licence for 1,000 rupees a month, paid by card. On the renewal date, the merchant sends a 3RI authentication request with the stored credential reference and the amount of 1,000 rupees. The issuer checks the mandate and the transaction history, and returns a frictionless approval. The merchant then includes the authentication value in the authorisation request, which gives the issuer confidence that the charge follows the original customer consent.