# 3D Secure liability shift

US only
3D Secure is currently supported for US-based merchants only. Canada support is coming soon.

3D Secure can shift liability for fraud chargebacks from you to the issuing bank under card network rules. It does not prevent cardholders from disputing a payment or guarantee that a dispute will resolve in your favor. Authenticated payments can still be disputed, and you may still need to respond to those disputes.

## Overview

3D Secure authentication creates a record of whether the cardholder was verified. Under card network rules, that record determines whether certain fraud chargebacks are assigned to the issuer or to you.

Liability shift is not dispute protection. Even on fully authenticated payments:

- Cardholders can still raise fraud disputes.
- Issuers can still process chargebacks, including under reason codes outside the fraud liability-shift rules.
- You may still receive dispute inquiries and chargebacks that you need to defend, and representment can still fail. Outcomes depend on the evidence, the reason code, and the issuer, not on the authentication record alone.


Treat 3DS as a reduction in your fraud exposure, not as immunity from fraud losses.

When authentication completes, one of three outcomes is recorded:

- **Fully authenticated**: The issuer authenticated the cardholder, either through frictionless authentication or a successful challenge. Fraud chargeback liability can shift to the issuing bank under card network rules.
- **Authentication attempted**: Authentication was attempted but the issuer or card does not support full 3DS verification. In some cases, the card network may be involved in the authentication. Fraud chargeback liability can shift to the issuing bank under card network rules.
- **Not authenticated**: The cardholder did not pass authentication. This can happen if they failed the challenge, abandoned the flow, or were flagged as suspicious by the issuer. Liability stays with you.


When authentication does not complete:

- If the authentication process fails entirely, for example because the card is not enrolled in 3DS or the issuer's server was unavailable, no authentication record is created and liability stays with you.
- If you process the payment without 3DS, the payment is handled without authentication and liability also stays with you.


Flowchart showing how 3D Secure authentication outcomes map to liability
## API details

### Session state vs. authentication outcome

The 3D Secure Session has two distinct concepts:

- **Session state** (`state`): Whether the 3DS flow ran to completion. `SUCCEEDED` means the process completed; `FAILED` means it did not.
- **Authentication outcome** (`electronic_commerce_indicator`): The result of authentication. This field is only present when `state` is `SUCCEEDED`.


To determine liability, read `electronic_commerce_indicator`, not `state`. A `SUCCEEDED` state does not mean the cardholder was authenticated.

### Electronic Commerce Indicator values

| Value | Meaning | Liability |
|  --- | --- | --- |
| `AUTHENTICATED` | Cardholder was fully authenticated | Can shift to issuing bank |
| `ATTEMPTED` | Authentication attempted; issuer or card does not support full 3DS | Can shift to issuing bank |
| `NON_AUTHENTICATED` | Cardholder was not authenticated | Stays with you |


### When state is FAILED

If `state` is `FAILED`, authentication did not run to completion. The `failure_code` and `failure_message` fields describe the reason. Common causes include:

- The card is not enrolled in 3DS
- The issuer's authentication server was unavailable
- The card network's directory server was unreachable