> ## Documentation Index > Fetch the complete documentation index at: https://docs.gr4vy.com/llms.txt > Use this file to discover all available pages before exploring further. # Authentication Insights > A data dashboard that allows deep dives into payments authentication data The **Authentication** tab provides insight into the Strong Customer Authentication (SCA) process, including 3-D Secure (3DS) and other mechanisms like redirect-based flows. It enables users to analyze where authentications occur, their outcomes, and issuer behaviors. Authentication (for example, 3-D Secure) typically occurs **after** the payment method is selected but **before** the payment service is invoked. Or for alternative forms of payment (for example PayPal) authentication typically happens by redirecting to the payment methods' environment to finalize authentication. The dashboard allows: * Understanding the impact of 3DS/SCA rules * Analyzing friction in the checkout process * Identifying issuer behaviors and liability shift implications * Keeping track of conversion across payment methods The **Authentications** dashboard filters transactions to shows all transactions including **failed** transactions. This filtering ensures that all transactions where authentication logic is relevant and observable are displayed. ## Modules The dashboard includes multiple modules to analyze different aspects of the authentication flow. | Module Name | Outcomes / Categories | Relevant data fields | | --------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Methods** | `Card`, `PayPal`, etc. | `transaction.method` | | **Authenticated** | `Succeeded`, `Authentication Failed`, `Abandoned` | This is obtained by combining the outcomes of the directory response: `three_d_secure.response_data.directory_response`, `three_d_secure.response_data.authentication_response`, as well as using error codes `canceled_buyer_approval`, `failed_buyer_approval`, `missing_redirect_url`, `incomplete_buyer_approval` | | **Response** | `Y`, `N`, `U`, `A`, `R` | `three_d_secure.response_data.authentication_response` | | **Authorized** | `Successful`, `Declined/Failed` | `status` | | **Liability shifted** | `Yes`, `No` | `three_d_secure.response_data.directory_response`, `three_d_secure.response_data.authentication_response`, `three_d_secure.status`, `three_d_secure.response_data.scheme` | | **Challenge** | `Challenged`, `Frictionless`, `No challenge` | `three_d_secure.method` | | **ECI** | `00`, `01`, `02`, `05`, `06`, `07` | `three_d_secure.response_data.eci` | | **Issuer name** | Name of the card issuer (for example, `Chase`, `Barclays`) | `payment_method_details.card_issuer_name` | | **Issuer country** | Country of the issuer | `payment_method.country` | | **Card type** | `Credit`, `Debit`, `Prepaid` | `payment_method_details.card_type` | | **Scheme** | `Visa`, `Mastercard`, `Amex`, etc. | `payment_method.scheme` | | **BIN** | Top 25 Bank Identification Numbers | `payment_method.bin` | | **Country** | Country of the transaction | `country` | | **Connector** | PSP used (for example, `Adyen`, `Stripe`) | `payment_service_display_name` | | **Flow rule applied** | 3-D Secure flow rules that were triggered | Authentication flow rules | | **Currency** | Currency used in the transaction | `currency` | | **Instrument** | `PAN`, `NT`, etc. (instrument types) | `instrument_type` | ## Module details ### Authenticated Indicates the outcome of the authentication process. * **Succeeded**:\ Transactions where `three_d_secure.response_data.authentication_response` is `Y` or `three_d_secure.response_data.directory_response` is `Y` (frictionless scenario) are included. Lastly, redirect transactions that were authorized (alternative forms of payment are included) are also considered. * **Authentication Failed**:\ Transactions with `three_d_secure.response_data.directory_response`: `N`, `R`, `U`, error code as `canceled_buyer_approval`, `failed_buyer_approval`, `missing_redirect_url`, or in case of failed challenge: `three_d_secure.response_data.directory_response`: `C`, AND `three_d_secure.response_data.authentication_response`: `N`, `R` or `U`. Additionally, redirect transactions that were not authorized are also considered. * **Abandoned**:\ Transactions containing `incomplete_buyer_approval` error code. * **Other fields**: Furthermore `method`, `authorized_at` and `status` and are used. > **Note on Abandoned Derivation:** > The "Abandoned" status is explicitly derived from transactions that return the **`incomplete_buyer_approval`** error code. This typically occurs when a user starts the authentication process (for example when the user is redirected to a 3DS page) but does not complete it. ### Response Raw 3DS authentication response values `three_d_secure.response_data.authentication_response` This is the EMVCo ARes `TransStatus`: Raw 3DS authentication response values (`three_d_secure.response_data.authentication_response`). This corresponds to the EMVCo ARes `TransStatus`. * **Y** -> Authentication / Account verification successful. * **N** -> Not authenticated / Account not verified; Transaction denied. * **U** -> Authentication / Account verification could not be performed; technical or other problem. * **R** -> Authentication / Account verification Rejected. Issuer is rejecting authentication/verification and requests that authorization not be attempted. * **A** -> Attempts processing performed; Not authenticated / verified, but a proof of attempt authentication / verification is provided. ### ECI (electronic commerce indicator) The ECI indicates the status of the authentication for specific card schemes. **Mastercard** * **02** -> Successful authentication. * **01** -> Authentication attempted but could not be completed. * **00** -> Failed authentication or authentication cannot be attempted because card is not enrolled or issuer is not participating. **Visa** * **05** -> Successful authentication. * **06** -> Authentication attempted but could not be completed. * **07** -> Failed authentication or authentication cannot be attempted because card is not enrolled or issuer is not participating. ### Liability shift The liability shift is obtained by checking whether a transaction `three_d_secure.status` is `complete`. `three_d_secure.eci` is one of `01`, `06`, `02` or `05`. `three_d_secure.response_data.directory_response` is one of the following when the liability shifts either: `Y` or `A`, `C` while `three_d_secure.response_data.authentication_response` is `Y` or `A`. Card schemes are compared: 3DS scheme should be equal to the payment method scheme. Because of co-badge routing, the following can happen: 3DS done with scheme A. Transaction attempt with scheme A fails. A rule indicates an additional scheme B should be used (assuming the card is co-badged). Transaction attempt with scheme B succeeds. On that second attempt, the 3DS information obtained before isn't sent, because a different card scheme is being used. Hence, the liability isn't shifted. ### Challenge Describes the nature of the 3DS interaction using the `three_d_secure.method` either `challenge` or `frictionless`. ## Notes * Gift-card-only transactions are included even if they have no `method`.