When an Issuer Lets the Merchant Authenticate the Cardholder
A cardholder unlocks a retailer’s app with their face, browses, and checks out. They are then asked to authenticate again, this time by their bank, using a code sent by text message. The second authentication is weaker than the first and considerably more annoying.
Delegated authentication exists to resolve that. The issuer accepts that the merchant has already authenticated the cardholder to an agreed standard, and the ACS takes that into account rather than starting from scratch.
It is one of the more commercially significant features in the protocol and one of the least accurately described. The most common misunderstanding is that it lets a merchant bypass the issuer. It does not.
What actually happens
In delegated authentication, the issuer transfers the responsibility for cardholder authentication to a third party, which may be the merchant or an authorised representative. That party handles the authentication process.
Having authenticated the cardholder, the merchant relays the confirmation to the ACS. The ACS then assesses those authentication details as part of its transaction risk analysis. It will confirm the authentication unless the risk is judged excessive or the information supplied is insufficient. In either of those cases, the ACS retains the option to challenge the cardholder.
So the sequence is delegation, then evidence, then issuer judgement. The issuer never gives up the final decision. What it gives up is the need to perform the authentication itself when somebody else has already done it properly.
How the evidence travels
Two data elements do the work.
The 3DS Requestor Authentication Method states how the cardholder was authenticated. The specification defines a set of values covering the realistic possibilities, which include no authentication at all where the cardholder checked out as a guest, login using the requestor’s own credentials, login using a federated identity, login using issuer credentials, login using third-party authentication, login using a FIDO authenticator, login using a FIDO authenticator with assertion or attestation data signed, Secure Remote Commerce assurance data, Secure Payment Confirmation authentication, and electronic identity authentication data.
The 3DS Requestor Authentication Data carries the supporting material for whichever method was declared. The specification does not define this field in detail, and deliberately so. The intention is that for each authentication method the field carries data the ACS can use to verify the process. For a federated identity method it might carry information about the identity provider. For the FIDO-based methods it carries FIDO assertion or attestation data, and EMVCo has published a dedicated white paper with the FIDO Alliance covering the content and format for those cases.
A timestamp element records when the cardholder authentication took place, converted to UTC. That matters more than it first appears, because an authentication from three weeks ago is not equivalent to one from three minutes ago, and the ACS needs to know which it is looking at.
There is also an element populated by the Directory Server representing the result of signature verification the DS performed on the mechanism the cardholder used, with values covering verified, failed and not performed. For FIDO-based delegation this is a meaningful trust signal, because it tells the ACS whether an independent party checked the cryptographic evidence.
The precondition most articles skip
Delegated authentication requires an agreement.
The merchant must have an agreement with the issuer or ACS for delegated authentication, and must operate an authentication process that meets the issuer’s requirements. Regulations such as PSD2 support delegated authentication by merchants or third parties, provided the merchant adheres to the applicable Strong Customer Authentication requirements.
Critically, how that agreement comes about sits outside the core specification. Merchants and issuers establish it either through bilateral contracts or through services offered by payment systems.
This is the reason delegated authentication is not simply switched on. A merchant cannot unilaterally decide to authenticate cardholders and expect issuers to honour it. The technical capability is the easy part. The commercial and contractual layer underneath is where the work actually is, and it is why delegated authentication in practice tends to involve either very large merchants with direct issuer relationships, or scheme-operated programmes that provide the framework at scale.
If you are a merchant evaluating this, the first question is not whether your 3DS Server supports the data elements. It is whether you have, or can obtain, the agreements.
What a compliant merchant-side process looks like
The shape is consistent. When the cardholder creates an account or makes a purchase, they go through a secure registration process that complies with the requirements agreed with the ACS, for instance a FIDO-based enrolment. At checkout, the cardholder is prompted to authenticate using the method established at registration. The merchant’s system verifies the authentication data and validates the cardholder, then communicates that through the authentication method and authentication data elements in the request.
Two design points follow from this that merchants regularly get wrong.
The enrolment standard is set by the issuer, not the merchant. An authentication process that feels strong but does not meet the agreed requirements will not be honoured, and you will discover that through challenge rates rather than error messages.
And the authentication must be tied to the transaction, not merely to the session. A cardholder who logged in this morning has not authenticated this purchase. The timestamp element exists because that distinction is real.
Why the ACS can still challenge, and why that is correct
Merchants sometimes treat a challenge after delegated authentication as a failure of the arrangement. It is not.
The issuer remains accountable for the authentication decision and for the fraud outcome. Delegated authentication gives the ACS a strong additional input. It does not remove the issuer’s own risk assessment, and it should not, because the merchant does not see what the issuer sees. The issuer knows about activity on that account at other merchants, about recent credential changes, about patterns the merchant has no visibility of.
A well-functioning delegated authentication relationship shows up as a high proportion of transactions passing frictionlessly, not as a guarantee of zero challenges. If your challenge rate on delegated traffic is close to your challenge rate on undelegated traffic, something in the arrangement is not working, and the useful next step is a conversation with the issuer about what evidence they need rather than an assumption that the feature is broken.
Where it fits against the alternatives
Delegated authentication is one of several routes to a frictionless outcome and it is the heaviest to set up. Before pursuing it, it is worth being honest about whether the simpler options have been exhausted.
Populating the authentication request properly, running the device data collection mechanisms available in your channel, and making accurate use of exemption signalling where the regulatory framework permits it are all considerably cheaper, and for many merchants they close most of the gap.
Delegated authentication earns its complexity where a merchant already operates strong, enrolled, cryptographic authentication that customers use routinely, and where the volume justifies the contractual effort. For those merchants it is the difference between authenticating a customer once and authenticating them twice.
Frequently Asked Questions
Can a merchant use delegated authentication without an agreement with the issuer?
No. The merchant must have an agreement with the issuer or ACS and must operate an authentication process meeting the issuer’s requirements. How that agreement is formed sits outside the Core Specification: it happens through bilateral contracts or through services offered by payment systems. The technical capability is the easy part.
Which authentication methods can a merchant declare?
The specification defines a set covering the realistic possibilities, including login using the requestor’s own credentials, federated identity, issuer credentials, third-party authentication, FIDO authenticator with and without signed assertion or attestation data, Secure Remote Commerce assurance data, Secure Payment Confirmation, and electronic identity authentication data. Guest checkout with no authentication has its own value.
Does the ACS have to honour the merchant’s authentication?
No. The ACS assesses the authentication details as part of its transaction risk analysis and will confirm the authentication unless the risk is deemed excessive or the information supplied is insufficient. In either case it retains the option to challenge the cardholder.
How does the ACS know the cryptographic evidence was checked?
A dedicated element supplied by the Directory Server reports the result of signature verification performed on the mechanism the cardholder used, with outcomes covering verified, failed and not performed. Worth noting for anyone reading older documentation: this element was renamed in version 2.3.1.1 because the Directory Server, rather than the requestor, is its source.
Designing 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 delegated authentication and requestor-side data.
