What Happens to 3DS When an Issuer’s ACS Is Unavailable

When an issuer’s Access Control Server (ACS) stops responding, online payments for its cardholders do not necessarily stop. The card scheme’s Directory Server (DS) may answer the authentication request on the issuer’s behalf. That keeps checkouts moving, but it also means transactions are being authenticated, or marked as attempted, without the issuer’s own risk engine, and the fraud liability for many of them normally stays with the issuer.

For issuers, ACS availability is therefore a fraud-cost question as well as a service question.

How schemes answer for an unavailable ACS

Visa’s Visa Secure programme documentation describes attempts responses that can be provided by the ACS or by the Directory Server, returned with an attempted-authentication ECI (06). Mastercard runs Smart Authentication Stand-In, which can perform risk-based authentication on the issuer’s behalf. Acquirer and processor documentation of Mastercard’s outcomes (one example) lists frictionless stand-in authentications and stand-in attempts with the issuer shown as carrying liability.

Stand-in has limits. Processor documentation of Mastercard reason codes (one example) shows the DS indicating when a request was not eligible for stand-in because the merchant set the challenge indicator to ‘challenge requested: mandate’, and when it was not routed to stand-in because it came through the 3DS Requestor Initiated channel. In those cases there is no fallback answer.

What merchants see during an outage

Situation

What the merchant typically receives

Liability position

ACS timing out or failing, no stand-in

Transaction status U with a reason such as 14 (timed out at the ACS) or 22 (ACS technical issue)

Not authenticated; merchant decides whether to proceed

Scheme attempts processing

Attempted authentication (Visa ECI 06; Mastercard ECI 01)

Normally issuer, subject to scheme rules

Scheme stand-in risk-based authentication

Frictionless authentication returned by the scheme

Normally issuer

Request not eligible for stand-in

No authentication result

Not authenticated

The merchant’s side of this is covered in preparing 3D Secure authentication for peak trading.

Partial outages are more common than total ones

An ACS that answers authentication requests can still fail at the part that matters to cardholders. Common dependencies include the SMS gateway that sends one-time passcodes, the push service behind banking-app approvals, the cardholder data the ACS reads, and the hardware security modules that generate authentication values. When one of these fails, challenges fail while frictionless authentications continue, which can look like a sudden rise in abandoned challenges rather than an outage.

An availability checklist for issuers

  • Run the ACS across more than one site, with failover tested on a schedule.
  • Size capacity for peak volumes with headroom, not for averages.
  • Monitor every dependency of the challenge path, not only the ACS itself.
  • Provide a fallback challenge method when the primary method is unavailable.
  • Watch the reason codes merchants receive, such as 14 and 22, by card range.
  • Track how often schemes answered on your behalf and review fraud on those transactions.
  • Plan maintenance in agreement with each scheme’s requirements and notify them as their programmes require.

Issuer processors hosting many issuers on one ACS need the same disciplines at a larger scale (ACS multi-tenancy architecture).

Frequently asked questions

Does an ACS outage stop online payments for that issuer’s cards?

Not necessarily. Schemes may provide attempts responses or stand-in authentication. Payments that fall outside stand-in, or schemes without it, receive no authentication result, and merchants decide whether to proceed.

Who carries liability for transactions authenticated by stand-in?

Acquirer and processor documentation of scheme rules shows the issuer as normally carrying fraud liability for stand-in and attempted authentications. Confirm the current rules with each scheme.

Can stand-in meet a challenge mandate?

For Mastercard, processor documentation shows that requests with the challenge indicator set to “challenge requested: mandate” are not eligible for Smart Authentication Stand-In.

How quickly must an ACS respond?

Each scheme sets timing requirements for ACS responses. Design to meet them under peak load with headroom, because a slow ACS is treated much like an unavailable one.

Is stand-in a substitute for a resilient ACS?

No. Stand-in keeps transactions moving without the issuer’s own risk decisions or challenge methods, while the issuer normally keeps the liability.

Designing for availability

GPayments’ ActiveAccess is an Access Control Server for issuers and issuer processors. To discuss availability and resilience for issuing-side authentication, speak with a GPayments 3DS specialist.

When an issuer’s Access Control Server (ACS) stops responding, online payments for its cardholders do not necessarily stop. The card scheme’s Directory Server (DS) may answer the authentication request on the issuer’s behalf. That keeps checkouts moving, but it also means transactions are being authenticated, or marked as attempted, without the issuer’s own risk engine, and the fraud liability for many of them normally stays with the issuer.

For issuers, ACS availability is therefore a fraud-cost question as well as a service question.

How schemes answer for an unavailable ACS

Visa’s Visa Secure programme documentation describes attempts responses that can be provided by the ACS or by the Directory Server, returned with an attempted-authentication ECI (06). Mastercard runs Smart Authentication Stand-In, which can perform risk-based authentication on the issuer’s behalf. Acquirer and processor documentation of Mastercard’s outcomes (one example) lists frictionless stand-in authentications and stand-in attempts with the issuer shown as carrying liability.

Stand-in has limits. Processor documentation of Mastercard reason codes (one example) shows the DS indicating when a request was not eligible for stand-in because the merchant set the challenge indicator to ‘challenge requested: mandate’, and when it was not routed to stand-in because it came through the 3DS Requestor Initiated channel. In those cases there is no fallback answer.

What merchants see during an outage

Situation

What the merchant typically receives

Liability position

ACS timing out or failing, no stand-in

Transaction status U with a reason such as 14 (timed out at the ACS) or 22 (ACS technical issue)

Not authenticated; merchant decides whether to proceed

Scheme attempts processing

Attempted authentication (Visa ECI 06; Mastercard ECI 01)

Normally issuer, subject to scheme rules

Scheme stand-in risk-based authentication

Frictionless authentication returned by the scheme

Normally issuer

Request not eligible for stand-in

No authentication result

Not authenticated

The merchant’s side of this is covered in preparing 3D Secure authentication for peak trading.

Partial outages are more common than total ones

An ACS that answers authentication requests can still fail at the part that matters to cardholders. Common dependencies include the SMS gateway that sends one-time passcodes, the push service behind banking-app approvals, the cardholder data the ACS reads, and the hardware security modules that generate authentication values. When one of these fails, challenges fail while frictionless authentications continue, which can look like a sudden rise in abandoned challenges rather than an outage.

An availability checklist for issuers

  • Run the ACS across more than one site, with failover tested on a schedule.
  • Size capacity for peak volumes with headroom, not for averages.
  • Monitor every dependency of the challenge path, not only the ACS itself.
  • Provide a fallback challenge method when the primary method is unavailable.
  • Watch the reason codes merchants receive, such as 14 and 22, by card range.
  • Track how often schemes answered on your behalf and review fraud on those transactions.
  • Plan maintenance in agreement with each scheme’s requirements and notify them as their programmes require.

Issuer processors hosting many issuers on one ACS need the same disciplines at a larger scale (ACS multi-tenancy architecture).

Frequently asked questions

Does an ACS outage stop online payments for that issuer’s cards?

Not necessarily. Schemes may provide attempts responses or stand-in authentication. Payments that fall outside stand-in, or schemes without it, receive no authentication result, and merchants decide whether to proceed.

Who carries liability for transactions authenticated by stand-in?

Acquirer and processor documentation of scheme rules shows the issuer as normally carrying fraud liability for stand-in and attempted authentications. Confirm the current rules with each scheme.

Can stand-in meet a challenge mandate?

For Mastercard, processor documentation shows that requests with the challenge indicator set to “challenge requested: mandate” are not eligible for Smart Authentication Stand-In.

How quickly must an ACS respond?

Each scheme sets timing requirements for ACS responses. Design to meet them under peak load with headroom, because a slow ACS is treated much like an unavailable one.

Is stand-in a substitute for a resilient ACS?

No. Stand-in keeps transactions moving without the issuer’s own risk decisions or challenge methods, while the issuer normally keeps the liability.

Designing for availability

GPayments’ ActiveAccess is an Access Control Server for issuers and issuer processors. To discuss availability and resilience for issuing-side authentication, speak with a GPayments 3DS specialist.