The first payment in a subscription and a later recurring charge may look similar in an account statement, but they can present different authentication circumstances. During the first purchase, the cardholder may be available to verify the transaction. On a subsequent merchant-initiated charge, the cardholder may not be present at all.
This is why authentication strategy for recurring payments is about recognising the transaction context, not applying a checkout challenge to every event.
Understand the role of 3RI
EMV 3D Secure includes a 3DS Requestor-Initiated (3RI) device channel for supported cases where authentication is initiated without the cardholder actively participating in the merchant’s checkout. Scenarios can include recurring payments, split shipments and certain other merchant-initiated arrangements.
The precise flow depends on the protocol, prior transaction information, capabilities of the issuer environment and applicable requirements. A 3RI message is not simply a normal browser challenge performed in the background.
Issuers need to understand what the request represents and how it relates to the original customer interaction.
The decision begins with the payment arrangement
A subscription may involve an initial customer agreement, a first payment and subsequent charges under agreed terms. The facts of that arrangement matter when evaluating later requests.
Questions may include: Is the request consistent with the payment arrangement? What previous authentication information is available? Has the amount or timing changed unexpectedly? Which issuer and scheme controls apply? Is additional cardholder authentication required and feasible?
These questions should not be reduced to a universal statement that recurring transactions are low risk or that they always need another challenge.
Where prior authentication information helps
Previous authentication information can provide context for a later 3RI request. It may help the issuer understand the relationship between an earlier customer-present interaction and the subsequent transaction.
However, prior authentication does not guarantee that all future requests should receive the same treatment. The issuer still needs to evaluate available signals, configuration and applicable risk or regulatory requirements.
Where the cardholder is absent and further authentication is needed, decoupled authentication can provide a supported mechanism in relevant circumstances. EMVCo’s 3DS guidance describes how decoupled authentication supports 3RI scenarios.
Example: an ordinary charge and a changed amount
Consider a fictional digital service charging a customer monthly. The first transaction involves the cardholder and establishes the original payment arrangement. Subsequent 3RI requests refer to the relevant prior information.
One month, the service charges the expected amount. Another month, the amount changes materially because of an additional service. The two charges should not be assumed equivalent merely because they come from the same merchant.
The issuer’s decision process can consider available transaction information, the payment arrangement and its authentication policy. If supported and appropriate, an additional authentication method may be requested. The final outcome must be recorded through the defined protocol process.
The Decision AI opportunity
Decision AI raises a useful design question: can a system determine which additional evidence or action is required from the context, rather than treating all merchant-initiated activity alike?
A future assistant might help operational teams analyse exception patterns, explain relevant 3RI data or identify which flow options are supported. But such tools cannot replace protocol requirements or assume responsibility for an issuer’s risk policy.
Organisations should distinguish established 3DS functionality from hypothetical AI-driven enhancements when assessing vendors.
Design for the failure cases
Recurring payment authentication needs tests for missing prior authentication information, unsupported issuer capabilities, unavailable cardholders, delayed responses and inconsistent merchant data. The operational consequences matter as much as the happy path.
Review these cases with fraud, technology, operations and customer-experience teams. Avoid measuring performance only by approval or challenge rates without understanding why a transaction took a particular route.
The aim is a defensible authentication decision
For recurring payments, the challenge is not eliminating cardholder participation at all costs. It is using the available context and permitted flows to select an appropriate action when cardholder presence cannot be assumed.
Frequently asked questions
Does 3RI mean every recurring payment is automatically authenticated?
No. Outcomes depend on transaction details, supported capabilities and issuer requirements.
Can 3RI use a normal browser challenge without the cardholder present?
The 3RI channel is different from a cardholder-present browser flow; decoupled authentication is relevant when a supported 3RI challenge is required.
Take the next step
GPayments ActiveAccess supports issuer-side 3DS capabilities including 3RI and decoupled authentication. Speak with the team about your recurring-payment scenarios and integration requirements.
Discuss 3RI support with GPayments