.svg)
Understanding the Essential 3DS Data Fields for Authorization Success
Product Updates
/
November 19, 2025
/
10 min read
Most payment teams are familiar with the purpose of 3D Secure: adding a layer of protection through strong customer authentication (SCA). But when it comes to the technical data exchange that happens between authentication and authorization, confidence often fades.
This might seem like a niche concern, particularly for merchants who rely entirely on payment service providers (PSPs) to handle authentication and authorization at once. However, for those managing authentication flows themselves, or ones operating under a multi-agent or multi-processor scenario, understanding the underlying meaning of each 3DS response field is essential, as it can have a direct impact on approval rates and liability shift outcomes.
Each data point inside a 3DS authentication response carries meaningful information about the authentication status, how the authentication was processed, how liability was assigned, and whether authentication was approved or not. They are not just data elements; they shape user experience, affect conversion rates, and play a key role in optimizing subsequent payment authorizations.
This guide helps you make sense of it all. By unpacking how 3DS authentication results are structured, we’ll give you the clarity and confidence to interpret them effectively.
When it comes to processing an authorization after a successful 3D Secure (3DS) authentication, submitting the right authentication response fields is critical. Unfortunately, it's not always straightforward. Payment providers, whether it's Stripe, Checkout.com, Adyen, or others, have their own interpretation of what "the right data" means. Some require specific fields, others rename standard values, and a few expect additional context that isn't clearly documented. This lack of standardization adds complexity to merchants and developers trying to build robust, interoperable payment flows.
For simplicity, we’ll focus on the most relevant, mandatory fields that directly impact the subsequent payment authorization. These are the fields that help determine whether a transaction gets approved, declined, or flagged for further review.
The Electronic Commerce Indicator, in short ECI, is a value returned by card networks to indicate the security level of an online card transaction, specifically the outcome of a 3D Secure (3DS) authentication. This code helps financial institutions assess risk and determines liability for potential fraudulent chargebacks by indicating who is liable in case of fraud: either the merchant or the card issuer. The specific values vary by card network.
Visa, American Express, Diners, Discover and JCB:
These networks use the same ECI values for 3DS transactions:
• 05 – Full authentication was successful. The cardholder and issuer are enrolled in 3DS, and liability for fraud shifts to the issuer.
• 06 - Authentication was attempted but not fully completed. This may happen if the cardholder or issuer isn’t enrolled, or if a stand-in authentication was performed. Liability may still shift if a cryptogram is present, but it's weaker than ECI 05.
• 07 – Authentication failed or wasn’t attempted. This could be due to technical issues or lack of 3DS support. Liability remains with the merchant.
Mastercard uses a different set of ECI values for its Identity Check (formerly SecureCode) program:
• 02 – Authentication was successful and liability shifts to the issuer.
• 01 – Authentication was attempted but not completed, often due to stand-in processing.
• 00 – Authentication failed or couldn’t be performed.
• 06 – Indicates an exemption or use of network token without 3DS. Liability does not shift.
• 07 – Used for authenticated merchant-initiated or recurring transactions.
The Directory Server Transaction Identifier, in short dsTransId, is a unique identifier assigned by the Directory Server (DS) during a 3D Secure transaction. It’s a 36-character string, typically formatted as a UUID (Universally Unique Identifier) and serves as a reference point for the authentication process. It helps correlate the transaction across different systems involved in 3DS, such as the 3DS Server, the Access Control Server (ACS), and the issuer. The dsTransId becomes especially important in an authentication-only flow as it allows the merchant or integrator to:
• Track and correlate the authentication flow with the authorization request.
• Pass required data to the payment service provider (PSP), ensuring the PSP can validate the authentication attempt.
• Support troubleshooting by linking logs and responses across systems.
Although dsTransId is not always required in the authorization request, it is a recommended data point to forward when available and supported by the PSP. It adds transparency and traceability, especially in complex multi-agent and multi-processor setups.
A Cardholder Authentication Verification Value, in short CAVV, is a cryptographic code confirming the cardholder’s identity. It acts as digital proof that the cardholder was authenticated or that an authentication attempt was made during the transaction. This value is created by the issuer’s Access Control Server (ACS) and returned to the 3DS Server as part of the authentication response.
It enables the PSP and the card network to:
• Validate the authentication and determine whether liability shift applies.
• Confirm the integrity of the authentication flow.
• Support fraud protection by verifying that the transaction was processed through 3DS.
The Protocol Version Identifier, in short threeDSVersion, indicates which version of the 3D Secure protocol was used during the authentication process. This value is important because different versions of 3DS offer varying levels of security, user experience, and compliance with regulatory requirements like PSD2. Thus, it’s recommended to forward the threeDSVersion in the authorization request when available. This data point helps merchants and integrators:
• Understand the capabilities of the authentication flow (e.g., support for frictionless authentication, biometric challenges, etc.).
• Ensure compatibility with the payment service provider (PSP), which may expect specific version behavior.
• Troubleshoot issues related to authentication failures or unexpected challenge flows.
• 1.0.2: Legacy version (3DS1) now deprecated.
• 2.1.0: The first major release of 3DS2, supporting frictionless flows and mobile-friendly challenges.
• 2.2.0: Introduced enhancements like decoupled authentication and better support for exemptions under PSD2.
• 2.3.1 / 2.3.1.1: Further enhanced user experience and security, with smoother SCA processes and better device/channel integration.
In the 3D Secure 2 (3DS2) protocol, the Authentication Response (ARes) is a message sent by the Access Control Server (ACS) after the card issuer has evaluated the authentication request. This message is part of the initial phase of the 3DS2 flow and plays a crucial role in determining how the transaction proceeds.
The ARes contains a transaction status field, which indicates the outcome of the authentication attempt. This status helps the merchant or integrator understand whether the cardholder was successfully authenticated, whether a challenge is required, or whether the authentication failed or was not possible.
• Y (Yes) – Authentication was successful. The cardholder was verified, and liability shift may apply.
• N (No) – Authentication failed. The cardholder could not be verified, and liability remains with the merchant.
• U (Unavailable) – Authentication could not be performed due to technical issues or unsupported card/issuer.
• R (Rejected) – The authentication was rejected by the issuer, possibly due to risk assessment or policy.
• C (Challenge Required) – A challenge is required to complete authentication (e.g., OTP, biometric).
• The transaction status in ARes determines whether the merchant can proceed directly to authorization or must wait for further steps (like a challenge).
• It informs whether the transaction qualifies for liability shift, which protects the merchant from fraud-related chargebacks.
• It helps in logging and troubleshooting, especially when authentication fails or behaves unexpectedly.
• It supports user experience optimization, as merchants can tailor flows based on whether a challenge is expected or not.
The Results Request (RReq) is the final message in the 3D Secure 2 (3DS2) authentication flow. It is sent by the Access Control Server (ACS) to the 3DS Server after the cardholder has completed any required challenge, such as entering a one-time password (OTP), using biometric verification, or responding to a push notification.
This message contains the final transaction status, which confirms the outcome of the authentication process. It reflects whether the cardholder was successfully authenticated, whether an attempt was made, or whether the authentication failed or was rejected.
• Y (Yes) – Authentication was successful. The cardholder completed the challenge, and liability shift may apply.
• N (No) – Authentication failed. The cardholder did not complete the challenge successfully.
• U (Unavailable) – Authentication could not be completed due to technical issues or unsupported configurations.
• R (Rejected) – The issuer rejected the authentication, possibly due to risk scoring or policy enforcement.
• The RReq status is the final verdict on the authentication attempt and is used to determine whether the merchant can proceed with the authorization.
• It plays a key role in liability shift, helping to protect merchants from fraud-related chargebacks when authentication is successful.
• It informs transaction classification, helping merchants log and analyze outcomes for reporting, fraud detection, and user experience optimization.
• It supports compliance and auditability, especially in regulated environments like PSD2 in Europe.
The threeDSTransactionId is a globally unique identifier assigned by the 3DS Server to each 3D Secure transaction. It serves as the primary reference for the entire authentication flow, from the initial request to the final response.
• Tracking the transaction across all components involved in 3DS (Directory Server, Access Control Server, issuer).
• Correlating logs and responses for support, monitoring, and troubleshooting.
• Ensuring consistency when passing authentication data to the payment service provider (PSP).
• Links the authentication flow to the merchant’s payment flow.
• Can be used to audit or trace specific transactions.
• May be required by some PSPs for authorization validation, especially in advanced integrations.
While not all PSPs mandate this ID in the authorization request, it is considered best practice to store and forward it when possible, especially for reconciliation and support purposes.
The transStatusReason is a reason code included in the 3DS2 authentication flow that provides additional context about why a transaction received a particular status, especially when the result is not a straightforward success. This value is returned alongside the transaction status (e.g., N, U, R) in the ARes or RReq/RRes messages. It helps clarify why authentication failed, was unavailable, or was rejected, and is particularly useful for troubleshooting, analytics, and user experience optimization.
• Diagnose issues with authentication flows (e.g., technical errors, unsupported cards, user abandonment).
• Improve UX by identifying patterns in failed or challenged transactions.
• Support customer service with more precise error messaging.
• Inform retry logic or fallback strategies.
• 01 – Card authentication failed - The cardholder failed to complete the authentication successfully.
• 02 – Unknown device - The device used for the transaction could not be recognized or verified.
• 03 – Unsupported device - The device does not support the required authentication method.
• 04 – Exceeds authentication frequency limit - Too many authentication attempts have been made in a short period.
• 05 – Expired card - The card used is no longer valid.
• 06 – Invalid card number - The card number format or value is incorrect.
• 09 – Security failure - A general security issue occurred during the authentication process.
• 10 – Stolen card - The card has been reported as stolen.
• 11 – Suspected fraud - The issuer flagged the transaction as potentially fraudulent.
• 12 – Transaction not permitted to cardholder - The cardholder is not allowed to perform this type of transaction.
• 13 – Cardholder not enrolled in service - The cardholder is not enrolled in 3D Secure.
• 14 – Transaction timed out at the ACS - The cardholder did not respond in time during the challenge.
Even though transStatusReason is not required in the authorization request, it should be logged and monitored. It provides valuable insights for improving authentication success rates and reducing friction for end users.
To ensure successful 3DS2 authentication-only integration and benefit from liability shift, merchants and integrators should:
• Understand the key data fields returned during authentication (eci, cavv, xid, etc.).
• Forward the required fields to the payment service provider (PSP) during the authorization request.
• Store and monitor additional fields like threeDSTransactionId, transStatusReason, and authenticationResponse for analysis and troubleshooting.
• Display optional fields such as cardHolderInfo to improve user experience and reduce abandonment.
• Ensure consistent and accurate handling of 3DS2 data fields across systems by using this guide as a reference.
Our team at PCI Proxy specializes in secure, interoperable 3DS integrations tailored to your business needs. Contact us today to streamline your authentication process and maximize approval rates.
