3RI
What is 3RI?
3D Secure Requestor Initiated (3RI) is a merchant-initiated authentication method within the framework that allows businesses to authenticate recurring and scheduled payments on behalf of the cardholder, without requiring manual approval for each transaction. Unlike flows, the merchant starts the authentication in the background by referencing a transaction the cardholder already approved.
3RI exists because the standard 3D Secure flow assumes someone is sitting at a checkout page. Subscription renewals, installment schedules, and delayed shipments happen days or months after that session ended, so there's no browser to redirect and no one to respond to a prompt. The 3RI message flow, introduced with EMV 3DS 2.2, gives the merchant a way to ask the for an authentication decision anyway, based on the card data, the merchant record, and the earlier authenticated transaction it points back to.
Key facts
- Also known as: 3DS Requestor Initiated, merchant-initiated 3DS authentication
- Introduced in: EMV 3DS 2.2. Older 3D Secure versions have no 3RI message flow
- Cardholder present: no. The authentication runs outside any checkout session
- Common use cases: subscription renewals, installments, split and delayed shipments, adding a card on file, and checks
- Transaction type it supports: , the authorization that follows a 3RI authentication
- Request reason: carried in a 3RI indicator, which tells the issuer why the merchant is asking
How it works
- The cardholder authenticates once. A first purchase completes with standard 3D Secure while the is present. This transaction becomes the reference the merchant cites in every later 3RI request.
- The merchant sends the 3RI request. For the next scheduled charge, the merchant or its sends an authentication request through the 3DS server with a 3RI indicator identifying the scenario, along with the reference to the original authenticated transaction.
- The issuer scores the request. The issuer's access control server (ACS), which makes the authentication decision, weighs transaction history, card details, and merchant data. A can't run here, since no one is available to respond to it.
- The result comes back. A successful authentication returns an authentication value the merchant attaches to the request. A failed one returns no value, and the charge proceeds unauthenticated or not at all.
- The payment is authorized. The authorization is submitted with the authentication result attached, and the issuer approves or declines on the usual grounds.
Why it matters
- Regulatory positioning under SCA. are commonly classified as merchant-initiated and treated as out of scope for in the EEA, but classification depends on how the mandate was set up and on issuer interpretation. 3RI gives merchants an authentication route when the issuer expects one. Scheme and acquirer guidance decides which route applies.
- Better data at authorization. An authentication result attached to the authorization gives the issuer signal it otherwise wouldn't have on a renewal, which would be judged on transaction and card data alone.
- Liability position on the follow-up charge. Whether a successful 3RI authentication carries a depends on the scheme and the reason code in the request. Scheme rules differ here, so check the acquirer agreement.
- No return trip for the cardholder. Renewals, installments, and shipment-triggered charges settle without pulling the cardholder back into a checkout session weeks after the original purchase.
Common issues
- Nothing to fall back to. When the issuer wants cardholder interaction, the 3RI request simply fails. Recovery means re-authenticating at the next session where the cardholder is present, or working the charge through .
- Mismatched 3RI indicator. A request whose stated reason doesn't match the actual scenario gets declined, or authenticates without the protection the merchant expected.
- Broken reference to the original transaction. Without a valid pointer back to the initial authenticated payment, usually carried as the , the issuer has nothing to evaluate the request against.
- Version gaps in the chain. Every participant has to support EMV 3DS 2.2 or later. An issuer or still on an earlier version can't process a 3RI request at all.
