Skip to main content
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 (e.g., 3-D Secure) typically occurs after the payment method is selected but before the payment service is invoked. Or for alternative forms of payment (e.g. PayPal) authentication typically happens by redirecting to the payment methods’ environment to finalize authentication. The dashboard allows you to:
  • Understand the impact of your 3DS/SCA rules
  • Analyze friction in the checkout process
  • Identify issuer behaviors and liability shift implications
  • Keep 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 NameOutcomes / CategoriesRelevant data field(s)
MethodsCard, PayPal, etc.transaction.method
AuthenticatedSucceeded, Authentication Failed, AbandonedThis 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
ResponseY, N, U, A, Rthree_d_secure.response_data.authentication_response
AuthorizedSuccessful, Declined/Failedstatus
Liability shiftedYes, Nothree_d_secure.response_data.directory_response, three_d_secure.response_data.authentication_response, three_d_secure.status, three_d_secure.response_data.scheme
ChallengeChallenged, Frictionless, No challengethree_d_secure.method
ECI00, 01, 02, 05, 06, 07three_d_secure.response_data.eci
Issuer nameName of the card issuer (e.g., “Chase”, “Barclays”)payment_method_details.card_issuer_name
Issuer countryCountry of the issuerpayment_method.country
Card typeCredit, Debit, Prepaidpayment_method_details.card_type
SchemeVisa, Mastercard, Amex, etc.payment_method.scheme
BINTop 25 Bank Identification Numberspayment_method.bin
CountryCountry of the transactioncountry
ConnectorPSP used (e.g., Adyen, Stripe)payment_service_display_name
Flow rule applied3-D Secure flow rules that were triggeredAuthentication flow rules
CurrencyCurrency used in the transactioncurrency
InstrumentPAN, NT, etc. (instrument types)instrument_type

​
Module Details

​
Authenticated

Indicates the outcome of the authentication process.
  • Succeeded:
    We include transactions where three_d_secure.response_data.authentication_response is Y or three_d_secure.response_data.directory_response is Y (frictionless scenario). Lastly, we also consider redirect transactions that were authorized (alternative forms of payment are included).
  • 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, we also consider redirect transactions that were not authorized.
  • Abandoned:
    Transactions containing incomplete_buyer_approval error code.
  • Other fields: Furthermore method, authorized_at and status and are used.

​
Response

Raw 3DS authentication response values three_d_secure.response_data.authentication_response This is the EMVCo ARes TransStatus:
  • Y – Fully authenticated
  • A – Attempted authentication
  • N – Failed authentication
  • U – Unable to authenticate
  • R – Rejected by issuer

​
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. We compare the card schemes: 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 we should use an additional scheme B (assuming the card is co-badged). Transaction attempt with scheme B succeeds. On that second attempt, we don’t send the 3DS information obtained before, because we’re using a different card scheme. 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.
⌘I