# States

Learn about the different states in the 3D Secure authentication lifecycle and how to handle each one.

## Overview

During a 3D Secure authentication process, the transaction will progress through various states. Understanding these states helps you handle the authentication flow correctly and provide the best user experience.

## States

The following table describes the possible states of a 3DS transaction.

| State | Description |
|  --- | --- |
| `PendingClientData` | You've successfully pre-initiated a 3DS authentication request. Our checks confirmed that 3DS is supported. You can now initiate a 3DS authentication request. |
| `AuthenticationSuccessful` | The 3DS authentication request was successful. |
| `AuthenticationFailed` | The 3DS authentication request failed. Usually, it's sent along with state code data to provide more information about the reason for failure. You can retry authentication. It's not advisable to proceed with authorisation as the liability for the transaction stays with you. If the transaction is in the scope of PSD2, we strongly advise you to use an exemption in authorisation if applicable. Otherwise, the transaction is considered as non-compliant under PSD2 and might be soft-declined.
Here are some example cases where you might receive this state:- Transaction status = `N`. It indicates that authentication was attempted but failed. The cardholder couldn't be verified.
  - Risk-based decision failures.
  - Data mismatch cases:
    - Billing address mismatch with issuer records (severe discrepancy).
    - Phone number not on file or doesn't match.
    - Email domain suspicious (disposable email addresses).
    - Account velocity patterns abnormal but not critical.
    - Merchant/transaction category issues.
- Transaction status = `U`. It indicates technical inability to authenticate. This isn't a pass or fail decision, it just means the process couldn't be completed.
  - Issuer system limitations:
    - Cardholder not enrolled in 3DS program.
    - Card type doesn't support authentication (some prepaid/corporate).
= BIN not configured for 3DS 2.x (only 3DS 1.0 available).
    - Issuer region doesn't support online authentication.
  - Data availability issues:
    - No cardholder data on file for comparison.
    - Account too new (insufficient history).
    - Data privacy regulations prevent authentication.
    - Cardholder opted out of data sharing.
  - Technical failures at issuer side (ACS server):
    - Database connection timeout.
    - Risk-scoring engine failure.
    - HSM (Hardware Security Module) unavailable.
    - Integration with core banking timeout.
    - Rate limiting triggered.

- Transaction status = `N`. It indicates that authentication was attempted but failed. The cardholder couldn't be verified.
  - Failed challenge authentication:
    - Incorrect OTP entered (all attempts exhausted).
    - Wrong answers to knowledge-based authentication.
    - Biometric authentication failed.
    - Push notification rejected by cardholder.
    - Cardholder explicitly selected "Not Me" in their banking app.
  - Behavioural analysis during challenge:
    - Copy/paste of OTP (potential fraud indicator).
    - Response time too fast/slow for human.
    - Multiple device changes during challenge.
    - VPN/Proxy detected during challenge.
    - Cardholder abandons challenge (but not timeout).
- Transaction status = `U`. It indicates technical inability to authenticate. This isn't a pass or fail decision, it just means the process couldn't be completed.
  - Challenge delivery failures:
    - SMS gateway failure (can't send OTP).
    - Email delivery bounced.
    - Push notification service unavailable.
    - Banking app not installed/outdated.
    - Phone number invalid/disconnected.
  - Infrastructure problems:
    - ACS system crash during challenge.
    - Database becomes unavailable.
    - Session data corrupted.
    - Load balancer failure.
    - Memory/cache system failure.
  - Authentication method unavailable:
    - Biometric service down.
    - Hardware token battery dead (reported by user).
    - Backup authentication method also fails.
    - Voice call system unavailable.
    - In-app authentication service disconnected.

 |
| `AuthenticationRejected` | The 3DS authentication request was rejected. Usually, it's sent along with state code data to provide more information about the reason for rejection. For example, if the cardholder entered the wrong one-time passcode (OTP). Don't retry authentication. You can't proceed with authorisation.
Here are some example cases where you might receive this state:- **Card/account issues:**
  - Card reported stolen or lost: The issuer has flagged the card in their system.
  - Account closed: The cardholder has closed the account but the card details still validate.
  - Card blocked for fraud: Previous fraudulent activity has triggered a hard block.
  - Card restricted for online transactions: The issuer has disabled e-commerce on this card.
  - Regulatory restrictions: The card can't be used for certain merchant categories or jurisdictions.
- **Risk-based rejections:**
  - Velocity limits exceeded: Too many authentication attempts in short timeframe.
  - Suspicious authentication pattern: Multiple failed attempts across different merchants.
  - Geolocation mismatch: Transaction originating from sanctioned/blocked country.
  - Device fingerprint on blocklist: Device associated with previous fraud.
- **Data validation failures:**
  - Invalid `threeDSRequestorAuthenticationInd`: For recurring/MIT transactions with incorrect indicators.
  - Merchant on issuer blocklist: Specific merchant has been blocked by issuer.
  - Invalid merchant category: Gambling merchants for cards with gambling blocks, for example.

- **Challenge flow rejections:**
  - Too many failed challenge attempts: The cardholder has exceeded OTP/password retry limits.
  - Challenge timeout with suspicious behaviour: Pattern suggests automated attempts.
  - Biometric authentication failure: Face/fingerprint repeatedly fails with fraud signals.
  - Knowledge-based authentication failed critically: Wrong answers to security questions that indicate potential fraud.
- **Post-challenge risk assessment:**For example:
  1. The authentication is stepped up to challenge.
  2. The cardholder completes the challenge.
  3. The ACS performs the final risk assessment.
  4. The issuer rejects authentication based on:
    - Behavioural biometrics during challenge.
    - Time taken to complete challenge.
    - Device changes during challenge flow.
    - Network/location changes mid-authentication.

 |
| `AuthenticationError` | An error occurred and authentication couldn't be completed. Liability for the transaction stays with you. If the transaction is in the scope of PSD2, we strongly advise you to use an exemption in authorisation if applicable. Otherwise, the transaction is considered as non-compliant under PSD2 and might be soft-declined.
Common error codes:| Type | Error code | Description |
|  --- | --- | --- |
| System | `301` | Transaction ID not recognised. |
| System | `302` | Data couldn't be decrypted. |
| System | `303` | Access denied (merchant not enrolled). |
| System | `304` | ISO code invalid. |
| System | `305` | Transaction data not valid. |
| Timeout | `402` | Transaction timed out. |
| Timeout | `403` | Transaction receiving queue full. |
| Format | `101` | Message format invalid. |
| Format | `102` | Message version not supported. |
| Format | `201` | Required field missing. |
| Format | `203` | Invalid format in field. |

 |
| `PendingCustomerChallenge` | The ACS Server decided that frictionless 3DS authentication (without cardholder interaction) wasn't enough. It has stepped the authentication up to challenge. You need to redirect the cardholder to their issuer's page for authentication. |


## State data codes and reasons

The `stateData.code` and `stateData.reason` provide additional context about why a particular state was reached, regardless of whether it's a success, challenge, failure, or error state. They're there to help you understand the specific circumstances of the authentication result.

The following table describes the possible state codes and reasons:

| State code  | State reason |
|  --- | --- |
| `01` | Card authentication failed. |
| `02` | Unknown device. |
| `03` | Unsupported device. |
| `04` | Exceeds authentication frequency limit. |
| `05` | Expired card. |
| `06` | Invalid card number. |
| `07` | Invalid transaction. |
| `08` | No card record. |
| `09` | Security failure. |
| `10` | Stolen card. |
| `11` | Suspected fraud. |
| `12` | Transaction not permitted to Cardholder. |
| `13` | Cardholder not enrolled in service. |
| `14` | Transaction timed out at the ACS. |
| `15` | Low confidence. |
| `16` | Medium confidence. |
| `17` | High confidence. |
| `18` | Very high confidence. |
| `19` | Exceeds ACS maximum challenges. |
| `20` | Non-Payment transaction not supported. |
| `21` | 3RI transaction not supported. |
| `22` | ACS technical issue. |
| `23` | Decoupled Authentication required by ACS but not requested by 3DS Requestor. |
| `24` | 3DS Requestor Decoupled Max Expiry Time exceeded. |
| `25` | Decoupled Authentication was provided insufficient time to authenticate Cardholder. ACS will not make attempt. |
| `26` | Authentication attempted but not performed by the Cardholder. |
| `27` | Preferred Authentication Method not supported. |
| `28` | Validation of content security policy failed. |
| `29` | Authentication attempted but not completed by the Cardholder. Fall back to Decoupled Authentication. |
| `30` | Authentication completed successfully but additional authentication of the Cardholder required. Reinitiate as Decoupled Authentication. |