ECI value indicates the level of authentication performed on the transaction, which is forwarded to the authorization request and determines whether the transaction receives liability protection.
To get three_ds object with
eci
value, use
check order status
API
request, real-time
updated card order
Webhook
notification, or any card payment response.
Additionally, it is possible to retrieve the three_ds object in one of the processing operations responses under certain conditions.
Visa, American Express, JCB, Discover/Diners, Cartes Bancaires (VISA), UPI
| Value | Description |
|---|---|
| 05 | Cardholder authentication is successful. |
| 06 | Authentication was attempted but could not be completed. The ECI 06 value can only be used to indicate that authentication was attempted. |
| 07 | Non-authenticated e-commerce transaction. In practice, this usually indicates that full 3DS authentication was not completed for this authorization attempt. At the same time, payment can still be approved by the issuer. Approval status and 3DS authentication status are different outcomes, so a successful payment with ECI 07 is possible. |
Mastercard, Cartes Bancaires (Mastercard)
| Value | Description |
|---|---|
| 00 | 3DS authentication either failed or could not be attempted. Possible reasons include either the card or its issuing bank not yet participating in 3DS or the cardholder running out of time to authorize. |
| 01 | 3DS authentication was attempted but could not be completed. Possible reasons include either the card or its issuing bank having yet to participate in 3DS or the cardholder running out of time to authorize. |
| 02 | 3DS authentication is successful. Both card and issuing bank are secured by 3DS. |
| 04 | Data share only, non-authenticated e-commerce transaction, but merchants have chosen to share data via the 3DS flow with the issuer to improve authorization approval rates. |
| 06 | Acquirer exemption. |
| 07 | Recurring payments may apply to initial or subsequent transactions. If this value is received on initial recurring payments, the merchant has a liability shift. Subsequent transactions are considered as MIT and liability remains with the merchant. |
For risk and reconciliation decisions, always evaluate ECI together with the final payment status and the available 3DS flow value.
ECI for digital wallets
Apple Pay and Google Pay handle the ECI value to determine transaction authentication and liability in case of fraud.
Apple Pay
Merchants that decrypt Apple Pay tokens on their side must send the ECI code when initiating an Apple Pay transaction without it being altered or hardcoded.
Apple Pay supports liability shift globally for all major networks. However, for Visa, the liability shift applies globally only to devices running iOS 16.2+ or European-issued cards for earlier iOS versions.
Google Pay
Google Pay supports liability shift to issuers for qualified facilitated transactions that use Mastercard and Visa Android device tokens. For non-EU Visa cards, additional actions are required by merchants.
Liability shift moves fraud responsibility from the merchant to the issuing bank. Eligible Visa transactions carry ECI 05 after the token is decrypted.
You can opt into liability shift Reference through the Google Pay & Wallet console. European merchants are automatically covered by a Visa exception with liability protection for eligible transactions made with the cards issued by European issuers.
You should check with your PSP to verify if the liability shift applies.