Learn how to handle exceptional 3DS scenarios.
Most transactions using 3-D Secure (3DS) complete successfully with an approved authentication result. However, there are several cases where the authentication may fail, time out, or not be supported by the issuer. This page explains how to handle these cases to ensure a smooth checkout experience, maintain compliance, and correctly manage liability.
For more information about the different authentication states and reasons, see States.
The card issuer (or its network) doesn't support 3D Secure authentication, or the Directory Server indicates that 3DS is unavailable.
{
"authenticationId": null,
"state": null,
"scaMandated": false,
"threeDSecureVersion": null,
"threeDSecureFingerprintUrl": null,
"threeDSecureFingerprintData": null,
"threeDSecureSupported": false,
"recommendedChallengeIndicator": null
}- Proceed with non-3DS authorisation (standard authorisation request). Note that liability shift doesn't apply. You remain liable for fraud-related chargebacks.
- Log the response codes returned by the Directory Server or ACS.
- If you frequently encounter unsupported issuers, consider BIN-level reporting to identify patterns.
If Strong Customer Authentication (SCA) is required in your region (e.g., PSD2 in the EEA/UK), apply a relevant SCA exemption (e.g., Low Value, Transaction Risk Analysis, MOTO) before authorisation.
The cardholder starts but cancels or abandons the authentication. For example, by closing the browser window or pressing Cancel.
{
"authenticationState": "AuthenticationFailed",
"transactionStatus": "N",
"challengeCancel": "01" or "02
}- Don't authorise using 3DS data, as authentication wasn't completed. Note that liability shift doesn't apply. If you authorise the transaction anyway, you bear fraud liability.
- Offer the customer a retry option or allow them to choose another payment method.
- Clearly inform the cardholder that the authentication was cancelled. For example:
Your authentication was cancelled. Please try again to complete your purchase.
A technical problem prevents the authentication process from completing. For example, network errors, an ACS or Directory Server outage, or an unexpected timeout.
{
"authenticationState": "AuthenticationError",
}- Retry once, as transient network issues may resolve on retry.
- If retry fails, proceed with non-3DS authorisation. Note that liability shift doesn't apply.
- Monitor your technical error rate and report recurring issues to your acquirer or gateway.
- Implement timeouts and graceful fallback per EMVCo guidelines (e.g., 10-second 3DS Method completion window).
The cardholder didn't complete the challenge within the allowed time window.
{
"authenticationState": "AuthenticationFailed",
"challengeCancel": "03"
} or
{
"authenticationState": "AuthenticationFailed",
"transactionStatus": "U",
"transactionStatusReason: 14
}- Treat as an unsuccessful authentication. The session can't be resumed.
- Display a clear message prompting the user to retry. For example:
Your authentication session expired. Please try again. - Offer a retry or fallback payment method.
- Note that liability shift doesn't apply.
- High timeout rates may indicate UX or network performance issues. Review your challenge display integration and consider extending UI responsiveness (e.g., loading spinners, clear progress messages).
| Scenario | Proceed with authorisation? | Liability shift? | Recommended action |
|---|---|---|---|
| Issuer not 3DS-enabled | Proceed without 3DS. Apply exemption if needed. | ||
| Cardholder cancelled challenge | Optional. | Offer retry or alternative payment method | |
| Technical issue during 3DS | (non-3DS) | Retry once. Log and report errors. | |
| Challenge timed out | Optional. | Inform the customer. Allow retry or fallback. |