Authenticating Recurring and Instalment Payments

A subscription has two authentication problems, not one, and they are solved by different parts of the protocol.

The first is straightforward. The cardholder is present, signing up, and can be authenticated the way any other purchase is authenticated. The second is harder. Every charge after that happens when the cardholder is not there, has no browser session, and cannot be shown a challenge screen.

Teams that treat these as one problem end up with a recurring billing flow that either challenges nobody and carries the risk, or fails at renewal because it tried to challenge somebody who was asleep.

Two flows, deliberately separate

The specification treats recurring and instalment transactions as a distinct area and defines two flows for them.

The cardholder-initiated flow runs over the app-based or browser-based device channels. This is the initial transaction, or any later transaction where the cardholder is genuinely present and interacting. It behaves like any other authentication, because it is one.

The merchant-initiated flow runs over the 3DS Requestor Initiated device channel, commonly shortened to 3RI. This is the mechanism for subsequent charges, where the merchant initiates the transaction and no cardholder is in the session.

The architectural point is that 3RI is a different device channel, not a variation on the browser flow. Your integration has to treat it as such. Data that is collected from a live browser or a live app simply does not exist for a 3RI transaction, and an integration that assumes it does will produce requests that look incomplete to the issuer.

The constraint that determines your design

Here is the fact that ought to shape the whole implementation, and which is missing from most published material on recurring payments.

Decoupled authentication is applicable to all device channels, but it is the only authentication method available to facilitate cardholder challenges for 3RI transactions.

Read that carefully. If an issuer decides a renewal charge needs the cardholder to confirm something, there is exactly one mechanism available. There is no fallback to a challenge screen, because there is no screen. Decoupled authentication is it.

That has a direct consequence for anyone running a subscription business. Your ability to recover a renewal that the issuer wants confirmed depends entirely on whether decoupled authentication is available for that card range and whether the issuer has implemented it. Where it is not, a challenge decision on a 3RI transaction is effectively a dead end.

What decoupled authentication actually is

Worth defining precisely, because the term gets used loosely.

Decoupled authentication is a feature allowing an alternative authentication method where the primary method, the challenge, is not possible, not available, or fails. The authentication happens separately from the payment transaction flow rather than inside it.

The method used is outside the scope of the specification’s guidance. Example approaches include a text message, an email, a phone call, or a push notification to a banking app that completes the authentication and then sends the result to the ACS.

One implementation detail matters for anyone building against it. Although decoupled authentication is a challenge method, the flow can differ from the general challenge flow, because the challenge request and response messages are not always present. An integration that assumes those messages will appear will mishandle decoupled outcomes.

A dedicated data element lets the requestor indicate that it is asking the ACS to use decoupled authentication and that it agrees to its use if the ACS confirms. That is a request and an undertaking, not an instruction, and the ACS decides.

Version differences are real here

The specification’s own use cases for recurring and instalment transactions are documented separately for version 2.2 and version 2.3.1, and the difference is larger than a version number suggests.

On version 2.2, the merchant has a limited set of data available to describe a recurring or instalment transaction to the ACS. Specifically, the merchant cannot indicate that a recurring transaction has a variable amount, nor that an instalment amount differs from the initial purchase amount. EMVCo illustrates the version 2.2 position with two use cases: a recurring payment with a fixed frequency, and an instalment payment.

The practical effect is worth spelling out. Take a purchase paid in four instalments where the first payment differs in size from the three that follow. On version 2.2 the merchant cannot convey that difference. Worse, if the cardholder buys anything else at the same time as setting up the instalment plan, that amount is simply added to the purchase amount alongside the first instalment, and the issuer sees a single figure with no way to decompose it.

On version 2.3.1 the merchant has a much larger data set and can indicate a variable amount, or a recurring amount that differs from the initial purchase amount. EMVCo documents seven use cases at this version, covering fixed amount with fixed frequency, fixed amount with a promotional rate, variable amount with fixed frequency, variable amount with variable frequency, fixed amount with variable frequency, a recurring payment combined with a one-time purchase, and instalment payments.

There is a route to most of this without a full version migration. Those use cases are also possible on version 2.2 where the bridging message extension carries a recurring data object and both the ACS and the 3DS Server support it. For a subscription business stuck on 2.2, that is the single most useful thing to investigate.

A related caution for instalment merchants. The bridging extension carries many useful elements for instalment transactions in the recurring data object, such as recurring amount and recurring frequency, which the ACS can use in its risk assessment. But instalment payment data itself is only present in the authentication request message, so the extension is not a complete substitute and both need to be accounted for.

This is worth establishing early in any implementation conversation. The first question is not how to authenticate a renewal. It is which protocol version applies for the ranges you are billing, which you can determine from your card range data rather than by assumption.

What this means for a subscription implementation

Four design decisions follow from the above.

Authenticate properly at sign-up. The initial cardholder-initiated transaction is your one opportunity to authenticate with the cardholder genuinely present. Treating it as a minor step because the amount is small, or because it is a free trial, wastes the only easy authentication in the whole lifecycle.

Carry the history forward. The protocol provides elements for describing the cardholder’s relationship with the merchant and how they were authenticated previously. For recurring billing, this context is a large part of what allows a renewal to pass without intervention.

Know where decoupled authentication is available. Since it is the only challenge route for 3RI, its availability per card range is a material input to your billing retry strategy, not a technical footnote.

Decide what you do when it is not. A renewal the issuer wants confirmed, on a range where decoupled authentication is unavailable, needs a defined fallback. Usually that means bringing the cardholder back into a genuine cardholder-initiated session rather than retrying the 3RI transaction, which will keep producing the same outcome.

What not to conclude

Two cautions.

Nothing here guarantees a renewal will succeed. The issuer evaluates each transaction, and prior authentication history is an input rather than a commitment. Liability treatment for recurring transactions varies by scheme and by jurisdiction and should be confirmed against the applicable scheme rules rather than inferred from the protocol.

And 3RI is broader than recurring billing. It covers other merchant-initiated scenarios too. This article addresses the recurring and instalment case specifically, which is where the two-flow structure and the decoupled constraint bite hardest.

Frequently Asked Questions

Can a merchant-initiated renewal be challenged in the normal way?

No. Because a 3RI authentication is initiated without the cardholder present, the ACS cannot reply with a challenge status, since the challenge cannot be processed by the requestor. Where a challenge is needed, the only option is decoupled authentication, and only where the ACS supports it. The ACS then reaches the cardholder through an alternative channel outside the 3DS flow.

How do we link a renewal back to the original authentication?

Through the prior transaction reference, which carries the previous transaction’s ACS transaction ID. EMVCo names renewing a recurring transaction as one of the intended use cases, alongside SPC and decoupled authentication fallback flows. The ACS should then be able to retrieve the previous authentications and take their context into account in its risk analysis.

What recurring patterns can we describe to the issuer?

The recurring indicator lets the 3DS Server describe the transaction in terms of amount and frequency, across four combinations: fixed amount with fixed frequency, such as a subscription; fixed amount with variable frequency, such as a travel card with automatic top-up; variable amount with fixed frequency, such as utility bills; and variable amount with variable frequency, such as a pay-per-use card. Where a promotional first payment differs from later ones, the first amount goes in the transaction amount and the later amount in the recurring amount.

Can we use the version 2.3.1 capabilities while still on 2.2?

In most cases yes. The version 2.3.1 use cases are also possible on version 2.2 where the bridging message extension carries a recurring data object and both the ACS and the 3DS Server support it. One gap remains: instalment payment data is only present in the authentication request message, so the extension is not a complete substitute for instalment scenarios.

Building recurring authentication into your payment flow? ActiveServer is the GPayments 3DS Server solution for merchants, acquirers and payment service providers. Speak with a 3DS specialist about 3RI and decoupled authentication.