Who decides whether delegated authentication is accepted?

The issuer. A wallet, merchant or device can authenticate the cardholder, but the issuer chooses whether to rely on it. Delegation also fails when the acquirer is not configured to allow it or when a scheme program is not enabled for every party in the chain. NORBr does not make that decision. Operators configure the fallback, a retry with a 3DS challenge.

The issuer has the last word

Delegated authentication lets a wallet, a merchant or a device authenticate the cardholder instead of the issuer, under scheme programs with agreed security levels. The authentication result is passed to the issuer, which can rely on it or ignore it. If it ignores it, the payment proceeds as if no authentication had happened, and the liability shift does not apply.

Why delegation fails in practice

• The issuer has not enabled the program.
• The acquirer is not configured to pass delegated authentication data.
• A party in the chain uses an older version of the scheme specification.

What a platform can do

It cannot force acceptance, but it can configure the fallback: when the issuer rejects the delegated result, the payment is retried with a standard 3-D Secure challenge rather than failing. It can also record, per transaction, which authentication method was used and whether the issuer accepted it. Over time, that data shows which issuers accept delegation, so operators can decide where delegated flows are worth enabling and where a direct challenge is safer.