3RI Explained: How Merchant-Initiated 3DS Authentication Protects Recurring Revenue

Most recurring transactions are exempt from Strong Customer Authentication under PSD 2, once the original charge was authenticated. But exempt doesn't mean approved: issuers can still decline an unauthenticated renewal, and several everyday triggers, an aged-out authentication record, a shifted risk score, a variable final amount, force the question back open. 3RI, the Request or-Initiated mode in EMV 3DS 2.2, lets merchants authenticate those off-session charges by referencing the original cardholder session, without pulling the subscriber back through checkout.

Under Article 14 of the PSD2 Regulatory Technical Standards, a merchant-initiated transaction that follows an authenticated first payment doesn't need SCA. The renewal, the top-up, the auto-charge on file: all exempt, once the original cardholder-initiated transaction cleared with strong authentication. So why does a subscription business processing thousands of renewals a month still watch a meaningful share of them come back declined?

Because “out of SCA scope” and“guaranteed approval” aren't the same thing. Skip authentication entirely and the fraud liability sits with the merchant, not the issuer. Push a transaction the issuer considers genuinely risky through unauthenticated, and it can decline it anyway, exemption or not. And a handful of situations still force the question back open: an authentication record that's aged out, a risk score that moved since sign-up, an amount the customer never confirmed upfront. When one of those hits, the issuer wants fresh proof before it approves anything.

3RI, the Requestor-Initiated authentication mode in EMV 3DS 2.2, is built for exactly that gap. It lets a merchant authenticate an off-session, cardholder-absent transaction by referencing an earlier authenticated session, without routing the subscriber back through a checkout page they never asked to see again.

What the SCA exemption actually covers, and where it stops

The European Banking Authority's guidance on merchant-initiated transactions sets out three conditions for the exemption to apply: the cardholder gave the merchant a mandate to initiate a transaction or series of transactions, that mandate sits inside an agreement for goods or services, and the merchant can trigger the charge without the cardholder doing anything at the time. Meet all three, and the renewal doesn't need SCA.

What that guidance doesn't say is that issuers have to approve every unauthenticated MIT that shows up. Card schemes still reserve the right to ask for authentication data on transactions they flag as higher risk, and an issuer that sees a recurring charge with no authentication history behind it has every reason to be cautious. Treating“exempt” as “risk-free” is where a lot of recurring billing programs quietly lose approval rate they didn't need to lose.

How 3RI authenticates a transaction with nobody there to authenticate

A 3RI request runs through the same EMV 3DS message set as a normal authentication, with the device channel set to Requestor Initiated instead of browser or app. Rather than starting from zero, it carries forward the DS Transaction ID and prior authentication details from the original cardholder-present session: the one where the subscriber actually entered their card and, in most cases, completed a challenge.

The 3DS Requestor tags the request with an indicator describing why it's being sent, recurring transaction, split shipment, and so on. The issuer's ACS checks the request against the stored record of that original authentication and returns a result:no OTP, no biometric prompt, no redirect. In the rare case the issuer insists on a fresh check, it can trigger a decoupled challenge instead, handled entirely on the issuer's side (a banking app push, an SMS) with up to seven days for the cardholder to respond, per the EMV 3DS specification.

Three recurring-revenue moments where 3RI earns its place

Re-authentication triggers: Authentication records don't stay valid forever, and risk profiles change between billing cycles. When an issuer wants proof before approving month fourteen of a subscription it approved without question in month one, a 3RI request supplies it. The alternative is rebuilding a checkout flow around a customer who thought they were done checking out a year ago.

Variable and usage-based billing: Metered SaaS, infrastructure billing, anything where the final charge isn't known at sign-up, doesn't fit a standard authenticated checkout.The cardholder authenticated a plan, not a number. 3RI lets the merchant authenticate the actual charge once it's known, using the original session as the anchor.

Mid-cycle changes: Plan upgrades, add-ons, pro ration adjustments: all variations on the same original agreement, all candidates for a fresh 3RI request rather than a full re-checkout.

What happens if you skip it

Most recurring billing setups handle a decline the same way: retry, dunning email, maybe a card updater run,then try again. That workflow assumes the problem is a stale card number or a temporary hold. It does nothing for an issuer that specifically wanted authentication data and never got it. Retrying an unauthenticated charge against an issuer that's already said no on those grounds just produces the same decline again.

That's how a fixable decline turns into involuntary churn: a customer who wanted to keep paying, on a transaction that never actually had a shot at clearing. 3RI doesn't fix every decline. But for the subset that come back because the issuer wanted proof of authentication, it's the one channel built to supply it.

FAQ

Does 3RI require Strong Customer Authentication?

No. Most recurring merchant-initiated transactions are already exempt from SCA under PSD2. 3RI is a way to authenticate those transactions anyway, when an issuer wants proof or the merchant wants the fraud liability shift that comes with it.

How is 3RI different from a normal 3DS checkout flow?

A standard 3DS flow happens with the cardholder present in a browser or app. 3RI happens off-session,referencing an earlier authenticated transaction instead of prompting the cardholder again.

Can 3RI be used for something other than subscriptions?

Yes. Split shipments,variable-amount charges like car rental extras, and mid-order adjustments all use the same mechanism, tagged with a different indicator.

What happens if an issuer declines a 3RI request?

The merchant falls back to a standard authorization attempt without the liability shift, or triggers a fresh card holder-present authentication if the relationship allows it.

Does the original card need to be stored somewhere to use 3RI?

Yes. 3RI reuses the original authentication and the underlying card credential, so it depends on the card being held in a compliant vault rather than re-collected each cycle.

‍